On Thursday 31 May 2007 09:01:21 David Woodhouse wrote:
Until you know _why_ it failed on the secondary arch, you don't
know
that the build on the primary arch is good. We've _seen_ cases where a
generic failure just _happens_ to show up on one architecture due to the
phase of the moon or the number of CPUs in the build box. The
packagemonkey approach of just adding ExcludeArch and forgetting it (or
the QAmonkey approach of just letting the partially-failed builds out
unchecked) is just papering over a real problem.
It really doesn't matter. Before the secondary arch was added, the build
would happen just fine and go out. Adding the secondary arch and failing the
build or holding the build up from going to the public repo (but not from
hitting the buildsystem buildroot!!?) is a regression, for very little gain.
We're talking about enabling many more fringe arches to play in the same
sandbox, but we don't want to throw sand in the eyes of the maintainers
already playing here.
Letting partially-failed builds make it through into the repository
without _any_ intervention or investigation by the package maintainer is
completely insane and irresponsible. I am ashamed to see you advocate it
in public.
They aren't partially-failed. They completed just fine on the primary arches
that we most care about. End of story. If they _then_ fail on secondary
arches, that's a concern of the secondary arch team, whom we're allowing to
make use of some of our infrastructure to continue playing with their pet
arches. We're not suddenly beholden to every arch that wants to come to the
party.
> They can ask for the assistance of the
> package maintainer if they need it. I'm not about to prevent good builds
> that completed just fine on the primary arches from reaching the public
> repos of said primary arches.
Of course we wouldn't want to prevent good builds from getting out --
nobody's suggested that we would. Please stop being making things up.
You yourself are saying don't let the builds out until a bug is filed and
investigated, which could take who knows how long. Many builds _are_ fire
and forget, they shouldn't have to wait until the maintainer surfaces again
to file a bug, when the secondary arch build system could auto file a bug for
the arch team to look into.
The fact remains that any competent package maintainer, and any
competent QA person, would want failures to be investigated _before_ a
package hits the public repository -- to make sure it's not a generic
issue.
If it builds just fine on i386, x86_64, (ppc, ppc64), and _then_ fails on one
of the secondary arches, well then that's not really a concern of the
maintainer who is on the hook to care about the primary arches. If the
secondary arch didn't exist, the build wouldn't fail.
And if the maintainer _does_ conclude that it's arch-specific,
it's _trivial_ for her to file the bug and let the built packages out
into the wild. Of _course_ it isn't prevented.
Make the buildsystem auto file a bug. Reference build logs, even grep the
logs for error or whatever. Don't make it hinge on the maintainer to care
about another arch.
--
Jesse Keating
Release Engineer: Fedora