Fedora Extras Development Build Report

Sun May 8 16:15:31 UTC 2005

Am Sonntag, den 08.05.2005, 16:38 +0100 schrieb David Woodhouse:
> On Sun, 2005-05-08 at 16:32 +0200, Thorsten Leemhuis wrote:
> > 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.
> 
> Security fixes are generally fairly minimal. The chances of them
> introducing build failures are somewhat unlikely.

I tend to think the same -- but sooner or later it will happen ;-)

> > > 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).
> 
> What's the point? If it doesn't build on all the platforms it claims to
> build on, it's broken. If it's _known_ not to build on a given
> architecture, then the maintainer needs to make sure an appropriate bug
> is filed, and then add an ExcludeArch: and resubmit the build. Why does
> it help to let it run to completion on other architectures?

With three archs currently I tend to agree. But let make this four or
five:

- request build
- build fails on x86_64
- fix + request build
- build fails on ppc
- fix + request build
- build fails on IA64
- fix + request build
- build fails on sparc
- fix + request build
- done

against:
- request build
- build fails on x86_64, PPC, IA64,sparc
- fix + request build
- done

A lot easier IMHO 

> > > 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).
> 
> It isn't really an arch-specific thing either. You pointed out that
> there were a bunch of people who helped with gcc4 build failures; why
> should that be considered different?

Yes, maybe there should be such a maintainer-group also when such big
changes are ahead. But those changes happen only about once a year (or
even rarer) with together with bigger Core updates.

Arch-Problems can happen each day. And then the maintainer needs to know
whom to ask.

> If you really want to treat arch-specific 'helpers' differently, then
> you probably don't need more than one per arch. The incidence of bugs
> which really are arch-specific just isn't that high.

At least two imho. 

> > 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, ...). 
> 
> You can run automated test suites as part of the RPM build process.

In some packages, not in all. But I don't have a strong opinion here.
Imho we simply should use extras/testing (or something like that) for
this. Put it there after building (before signing? Signed with an
automatic key?). If someone verifies push it after out after at least 2
days. If not, put it out after 14 days without verifying. 

> > 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.
> 
> That's fine -- assistance is always on hand. Nobody's suggesting that
> package maintainers should be all-capable. Just that it's unacceptable
> for them to declare that a problem is uninteresting just because it
> happens to be on an architecture which they don't personally use.
> 
> Along the same lines, it's unacceptable that a package maintainer should
> ignore bugs even on one of the architectures they _do_ use, just because
> the reporter of the bug is trying to do something which the maintainer
> himself doesn't need.
> 
> If you're maintaining a package which correctly does only what _you_
> want it for and nothing more, you might as well just maintain it
> privately, not in Extras.

We agree here.

> > > > 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 ;-)
> 
> Not at all. AFAICT you know when 

an whom ;-) That imho something that not every current extras-packages
knows for x86_64 and ppc

> to ask for assistance, and you're
> willing to chase up reported bugs which don't affect you personally.
> That's perfectly reasonable.

-- 
Thorsten Leemhuis <fedora at leemhuis.info>