Fedora Extras Development Build Report

[Thorsten Leemhuis]

Am Sonntag, den 08.05.2005, 15:09 +0200 schrieb Michael Schwendt:
> 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. [...]

Just a side node for this discussion: What do we want do to in case of a
security update? Block the updated package also if it failed on one of
the archs? IMHO a bad decision if the resulting delay might be longer
than one or two days.

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

IMO too. *Maybe* the build-systems also could (it has nothing other to
build) try to build a "failed on one arch" package on the others archs
to see if those are working (okay, often it's a general problem: so
maybe better: if it worked on i386 try on all the others).

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

Well, you propose this more then once here for some weeks now iirc. What
is needed to get this "official". Did you discuss it on the FESCO-
Meetings? I'm all for such a solution (as long as the burden lies on
more than one shoulder per arch).

I ask cause I tried to fix some of the x86_64 problems and often did it
myself in the cvs -- some of the maintainers might wonder what the heck
this stupid person (e.g. me) was doing there. I would feel better if
this work was "official" in some way.

With such a group of persons (or even maillinglists extras-ppc and
extras-x86_64 [yes, I know, we have enough list already so forget the
last sentence]) the maintainers would know who to contact in case of
problems they can't solve on their own.

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

As I said before: Testing them before publishing is IMHO a good idea.
But sometimes I don't think it's possible: In the longer run there might
be too many packages for this and sometimes it's hard to test if a
package works if you don't know it (e.g. Coin2, ocaml, ...). 

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

And the knowledge/experience in C, C++/"Whatever Language my Package is
in". I'm one of those who learned to package RPMS in the last two years
in fedora.us & co, but my programming experience (besides scripts in
bash) is near NULL. So if my package does not build on PPC I only can
fix it myself if is something trivial.

(BTW, Michael und Adrian, thanks for fixing GCC4 problems in some of my
extras packages)

And those who know "their" arch imho can fix problems a lot faster then
others. I think I've seen most of the x86_64 problems now and know how
to fix them -- for the maintainers it might be hard and very
disappointing. We should not burn their energy if they don't want to fix
it own their own.

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

Seems i must leave then ;-)

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

...but is unlikely afaics.  
-- 
Thorsten Leemhuis <fedora at leemhuis.info>