For your consideration: Secondary Architectures in Fedora

[David Woodhouse]

On Thu, 2007-05-31 at 09:08 -0400, Jesse Keating wrote:
> 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!!?) 

No, the only time non-committed packages would be used for builds would
be in the chain-build case -- and you'd never let a later package in the
chain 'commit' before an earlier one. Please do apply some common sense,
even if the misinterpretation gives you fun rhetoric.

> 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.

<PARAPHRASE>
"Let's not do any more testing than we already do. Doing any more
testing might find real bugs and hold up the shipping of packages. That
would be throwing sand in the eyes of the maintainers."
</PARAPHRASE>

<SARCASM>
A great idea. Let's stop doing regression testing of corner cases in gcc
too -- if it builds 'Hello World' we should ship it anyway, right? We
mustn't hold up the development?
</SARCASM>

If a package fails on an architecture where it used to work, that's
something that any competent package maintainer should spend at least a
_moment_ looking in to, even if it's _only_ because it might affect
other architectures. Glancing at the build logs and filing a bug, then
pushing the 'ship it anyway' button is really not a lot of work. You
keep pretending it's some big problem, but it really isn't.

> > 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.

You're going back to your hyperbole again. We're talking about a few
moments' work to glance at the build logs and decide "Don't care; let it
go to the arch maintainer and push the build anyway", _if_ that is in
fact the appropriate action. That's hardly '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. 

Who knows how long it takes to glance at a build log and decide that
this time it _isn't_ a generic problem, so we can let the package
proceed anyway?  I'd guess a minute or so, in the general case? Most of
the time is spent in looking at the failure, which is something that a
competent package maintainer would want to do anyway.

> 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.

We're back to your 'if we didn't test it, it wouldn't fail' observation,
which makes me so ashamed that you're posting with your company email
address when you say it.

> > 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.

You don't have to 'care about another arch', you just need to act as any
competent package maintainer would and at least _glance_ at a build
failure and make sure it's not a generic problem. And you should be
doing that _before_ the partially-failed package lands in the public
repo.

-- 
dwmw2