Fedora Extras Development Build Report

[David Woodhouse]

On Sun, 2005-05-08 at 15:09 +0200, Michael Schwendt wrote:
> On Sun, 08 May 2005 12:13:38 +0100, David Woodhouse wrote:
> 
> > If the maintainer doesn't have time to fix the problem
> > immediately, a bug should be filed explaining the problem and _perhaps_
> > an ExcludeArch: could be added in the meantime.
> 
> It is also a matter of lack of interest, lack of motivation, 

Those are not traits which are expected of a maintainer.

> lack of hardware, and lack of knowledge/experience.

Access to hardware can be arranged, as can assistance from those with
more arch-specific knowledge or experience.

> A packager, who builds and tests on i386 only, bases his decisions on the
> test results on this platform. 

This is true. As it happens, I base my decisions almost exclusively on
the test results for PPC -- even for the packages I maintain in Core.
This is because most of the problems I'm likely to see are independent
of architecture.

There will _always_ be some bugs which don't happen to show up for the
maintainer, even with the most rigorous test regime.

Yes, the fact that maintainers often test on only one platform instead
of all seven is a part of that -- but even if maintainers have
sufficient hardware, time and inclination to repeat whatever testing
they do on all of the available platforms, there'd still be plenty of
bugs which slipped through.

> It is really bad if a package, which is believed to be ready, fails to
> build on an untested platform and blocks the release of an update.
> Rest assured, this is a turn-off criterion for many volunteers.

I can see _spurious_ build failures being a turn-off, and I'm a little
concerned by the ones I've seen in the last day or so. But build
failures which show _real_ problems are what the volunteer has
volunteered for, surely? Dealing with that is the rôle of the package
maintainer.

> It is bad enough already, that i386 is not built first, so packagers get
> told that a build failed on another platform, and they don't know whether
> i386 would succeed in the build system. This is a wrong decision IMO.

I'm not sure I see the logic. For any given version of a package, there
may be any number of bugs which prevent it from building. The package
maintainer needs to look at each one individually and fix it before
moving on to the next. 

Any given pass through the build system will only show up one such error
before it bails out -- why does the ordering really matter?

It's sort of expected that the package is observed to build locally on
at least _one_ platform before the maintainer even commits it and
requests a build. If the maintainer is working on i386, then presumably
she already knows that the i386 version builds?

> We do need the effort of an arch-specific community of developers and
> users, who help with making their special architecture as strong and
> supported as i386.

Agreed. Some stuff really is arch-specific and does need to be looked at
by someone with a little more experience. If a package maintainer needs
help fixing a bug which she has determined is PPC-specific, then I'm
more than happy to be added to the Cc list in bugzilla. I'm sure there
are people who will do the same for i386- and x86-64-specific problems;
not everyone speaks i386 assembly, for example.

> Publishing untested packages is really bad. But currently, we're forced
> to publish packages for three architectures, two of them being untested
> for the majority of packages.

That's just a special case of "you can't test _every_ situation". Most
bugs aren't arch-specific, and most of the bugs I've dealt with recently
which _have_ been arch-specific have shown up at build time, not at run
time. You really don't lose out on much by testing only on one platform.

> Once marked ExcludeArch, a packager won't ever give rebuilds for the
> excluded architectures a try, as long as testing and testbuilding in his
> own development environment is only done for the architectures he has
> access to and interest in.

This is why we should be requiring an open bugzilla bug for every such
exclusion. Otherwise the exclusion lasts for ever and people forget why
it was there. This is something I want to see in Core too.

> > If the problem is within the package itself, the maintainer is expected
> > to fix the problem as soon as possible -- that's what maintainers are
> > for, after all.
> 
> I'd like to suggest that such expectations towards volunteer packagers are
> documented somewhere soon.
> 
> It is a pretty crucial requirement, if you distinguish strongly between
> package maintainers and "package-monkeys" (quote).

I agree, and I don't want to discourage volunteers. It should be clear
that assistance is available for volunteers who _want_ to help but are
concerned that they may not currently be _capable_ of being anything
more than a 'package-monkey'. 

> Your messages in this thread [and earlier on] read very much like you are
> grumpy, initially when a packager suggested "ExcludeArch: ppc" to flag a
> package which fails to build on ppc.

I'm not grumpy; I'm not aware that anyone had done such a thing. I
happened to notice a build failure on PPC and tried to help debug it.
Then we digressed into a discussion of policy, after I realised that
gnupg2-1.9.15-2 was present on i386 but not on PPC due to a _spurious_
build failure. 

> I still feel really bad about this sudden change in Fedora Extras
> philosophy, where ExcludeArch would be criticised. 

I'm not saying that ExcludeArch should necessarily be criticised; I'm
saying that it should be used sparingly, and only with reference to a
bug report which explains what the actual problem was.

For example, I _would_ have been grumpy if gnupg2 had ended up with an
unexplained 'ExcludeArch: ppc' just because of the spurious build
failure which seems to happen on x86_64 now too.

> > If you mean the upstream developers of the code in question, then it
> > sounds like the package should never have been imported -- we should
> > require sane, portable code in packages built for Extras.
> 
> With all due respect, but here it's time for a quick reality check, I say,
> since what you want to require, requires the availability of test machines
> first _and_ contributors' interest in spending extra time on other
> architectures.

No, really. You don't need test machines in order to write sane,
portable code. You just need a modicum of clue, and a little bit of
attention to detail. You don't make assumptions about word size, you
don't make assumptions about endianness, etc. 

Yes, you do need to be interested in writing good code. That is an
interest which should be encouraged -- lazy people are going to write
bad code which breaks even on i386 at times, not just on other
platforms.

> > If you mean that the maintainer of the Extras package can't be bothered
> > to do their job properly, then a more suitable maintainer can be found
> > or the package dropped.
> 
> Have fun with that! FWIW, I value contributors, who don't want to publish
> untested packages, more than contributors who release what seems to build.
> If, however, you are successful in finding volunteers, who focus on three
> architectures and also take over the testing not done by upstream
> developers, that would be good news for Fedora Extras.

I think you overestimate the benefit you'd gain from repeating your
testing on multiple platforms. Those packages with automated tests can
already run those tests during the RPM build phase -- the gnupg2 failure
mentioned above was actually in _testing_ not actually during the
compilation stage, for example. Those packages with only ad-hoc testing
would benefit more from developing an automated test suite than they
would from repeating whatever tests the packager feels like doing, but
on multiple platforms.

-- 
dwmw2