Fedora Extras Development Build Report

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

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

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

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.

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

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

> > > 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 to ask for assistance, and you're
willing to chase up reported bugs which don't affect you personally.
That's perfectly reasonable.

-- 
dwmw2