For your consideration: Secondary Architectures in Fedora

[David Woodhouse]

On Wed, 2007-05-30 at 19:28 -0400, Christopher Blizzard wrote:
> I think that this is the key question that we need to be asking here:
> For what is a package maintainer actually responsible?  Right now it's
> just primary arches. 

The balance we have at the moment is working very well, and we should be
very careful about messing with it -- especially if there isn't anything
_specific_ we're trying to achieve.

The package maintainer is responsible for bugs and stupidities in the
package which _aren't_ arch-specific. Things like forgetting to byteswap
where necessary, unconditional i386 inline asm without fallback to C,
etc.

The arch team pick it up when more arch-specific clue or porting work is
required, with assistance and pointers from the package maintainer.

More clueful maintainers can handle a little more; the less clueful fall
back to filing a bug and calling in the arch team a little sooner --
some may even call in the arch team just to help whittle down a test
case for a compiler bug report, But the balance works well.

I'm very concerned that if we allow partially-failed packages to make it
into the repo, even with an automatic bug filed, that will encourage the
less conscientious maintainers to not even bother to _look_ at a failure
which may also affect other architectures. And we get into a situation
where it's considered 'normal' for some packages to be missing on some
architectures without good reason.

Also, the automatic bugs will lack the information which the arch team
would want from the maintainer about what's going on, anyway.

Letting the package maintainer file the bug for herself retrospectively
would be OK -- at least they know they need to look into it. And the
packages would be available in koji _immediately_; it's just that they
don't get into the _repository_ until they're "committed" by being
either built or 'excused' on all the architectures they were built for. 

>  Do we want to add a lot of secondary arches right
> now and make lives harder for people?

What are those two questions doing in the same sentence? Do you think
that adding new architectures will make life harder for people? Why do
you think that?

Adding the arch in the first place should involve _no_ work for the
package maintainers -- the arch team would presumably do a full build of
all packages in advance, to 'seed' the build system. Any package which
doesn't work should already have an ExcludeArch: added before the new
architecture is added to the build system.

So it's only a potential issue for new packages, or old packages which
later develop a bug or start to trip over a compiler bug.

It's hardly difficult to get ExcludeArch: or ExclusiveArch: right when
introducing a new package -- that effort is _trivial_ in comparison to
the other hoops you need to jump through to make a review-worthy
package. And in fact is already listed as one of the things to be
checked in the review, is it not?

So that leaves just the bugs which affect updates to existing packages
that used to work... and a competent package maintainer should be
looking through the logs and diagnosing the failure there _anyway_,
because it might not be something arch-specific; it could be something
which just _happens_ to bite more often on a multi-way SMP system, for
example. The 'extra' effort of filing a retrospective 'ExcludeArch' bug
explaining the failure is minimal, and that's _all_ that would be
required to allow the affected package to proceed through into the
repository.

So where did this nonsense about 'mak[ing] lives harder for people' come
from? Do you really have such a low opinion of our package maintainers
that you think they'll be scared off by the requirement to file a bug
when they encounter a build failure which seems to be arch-specific and
is beyond their capabilities?

-- 
dwmw2