Fedora Extras Development Build Report

Michael Schwendt bugs.michael at gmx.net
Sun May 8 13:09:35 UTC 2005


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, lack of
hardware, and lack of knowledge/experience.

A packager, who builds and tests on i386 only, bases his decisions on the
test results on this platform. 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.

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.

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.

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.

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.

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

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 still feel really bad about this sudden change in Fedora Extras
philosophy, where ExcludeArch would be criticised. In my point of view, we
have been good at fedora.us, where we only built for i386, in blocking
broken packages and broken software releases from entering the
repository. Well, except for a very few cases [e.g. "mach" -- Ralf might
argue about this ;)], but that was also due to giving new contributors the
opportunity to review and approve new packages from other new contributors
on their own, i.e. without their judgement being questioned too much. It
would have been a major hindrance, if one of the "trusted" contributors
had to verify a new contributor's review in detail (and e.g. verify
run-time stability, too). At some point in time, all packages were
attempted to be rebuilt for x86_64 by Justin Forbes, and where multilib
problems didn't hit us hard, segfaults did at run-time. Building for
x86_64 was discontinued due to lack of contributor time, but was
reintroduced with pre-Extras, and again, it broke packages, which were
prepared and tested on the packagers primary i386 platform.

> > In practice, developers will only have access to a limited set of
> > architectures, in some cases developers do not/do not want to support
> > some architectures, so ... there will always be "second class citizen
> > packages" on some architectures ... 
> 
> I'm not sure who you're referring to when you say 'developers'.
> 
> 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.

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




More information about the fedora-extras-list mailing list