http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures

[David Woodhouse]

On Wed, 2007-07-11 at 16:58 -0500, Tom "spot" Callaway wrote:
> I'm still not convinced this is necessary. I think this puts too much
> burden on the maintainer, when this should fall to the secondary
> architecture team.

I think you're mistaken on both counts -- on where the responsibility is
likely to lie, and on the amount of this 'burden'.

My experience is that _most_ such failures are going to turn out to be
generic bugs in the package; not really arch-specific problems at all.
They'll bite on more than one, if not all, architecture(s); if not
immediately then over time. It's just that some bugs don't show up 100%
of the time; they're dependent on subtle things like the number of CPUs,
the amount of memory available, how the compiler chooses to lay out
registers, etc.

Shipping the affected packages without even expecting the maintainer to
_look_ at the failure is a very bad idea, from a QA point of view. It's
also an unreasonable thing to do to the arch team for the affected
architecture(s) -- both because we're making them take on the initial
investigation of bugs in arbitrary packages which are likely not to be
arch-specific at all, and because we'd be making them deal with the
build system inconsistencies which arise from the unnecessary missing
packages; just as Jesse reminded us only worse.

And the 'burden' of which you speak is _trivial_ -- you spelled it out
yourself. We're talking, in the minimal case, about the amount of time
it takes to _glance_ at the build failure (for a package you _know_) and
make a decision about whether or not you care; whether your build is so
urgent that it has to be shipped now without waiting for a fix; whether
the secondary arch in question is going to be screwed by the absence of
the updated package because you're about to build a dozen other packages
against it, or whether it's a 'leaf' package which doesn't really
matter, etc.

Let the maintainer make that decision; really. It'll work out right --
the people who maintain the core packages are in general more
conscientious than those who maintain only leaf-node packages, and will
tend to do the job properly where it matters.

I know you're worried about the lowest common denominator; the people
who don't even understand the language which their package -- the
package which they're supposed to be supporting and fixing bugs in -- is
written in. But that's fine -- all they have to do is file an empty bug
saying "the build failed but I do not know anything about why", and push
the "ship it anyway" button. It sucks that we have such poorly supported
packages, but it doesn't really hurt the secondary architectures much
more than it hurts anywhere else. They'll generally not be packages we
depend upon for much.

It just isn't that much of a burden, for those who don't want it to be
or who aren't up to the task. It only helps to set expectations, and
stops us from _automatically_ shipping something which is actually quite
likely to be broken on the primary architectures too.

-- 
dwmw2