Five build fixes a day

[Colin Watson]

On Tue, Sep 13, 2011 at 07:10:14AM +0200, Martin Pitt wrote:
> Fixing an FTBFS is not all that simple: I really doubt that all of the
> fixes that were uploaded in the past days were properly sent to
> Debian/upstream, have been tested with upstream trunk, and an upstream
> bug/patch has been sent against trunk (if applicable).

I've sent all mine to Debian where applicable.  I haven't tracked down
upstream and don't think that's necessary in many cases; the Debian
maintainer is free to forward it on upstream.

> But if you don't do this, you replace a queue of 600 FTBFS bugs with a
> queue of 600 merges for the next release, and the whole pile of work
> just keeps being pushed over several releases.

I'm seeing good progress with FTBFS fixes being applied by Debian, so I
expect many of these to turn into syncs.  Sure, some will turn into
merges, but it's *not* simply pushing the whole pile of work off for
later.

> > [1] If your primary focus is main, you may be tempted to say "oh, they're
> >  in universe, so they don't matter very much".
> 
> I'm actually in that camp. I am not convinced at all that fixing all
> FTBFS bugs in universe is time well spent. We don't even have enough
> manpower to fix even the worst bugs in main. We have only 1/10th or so
> of the required manpower to keep the whole universe in good shape, and
> every manday spent on random universe packages makes our actual
> products worse.

Please find me a real Ubuntu user who doesn't install some packages from
universe.  Now watch as they have upgrade problems, or as the packages
they chose to install stop working ...  We do ourselves a disservice by
pretending that it's unimportant.

> I do appreciate the license/security updates/etc. problems, but TBH
> I'd be much more inclined to apply the lp-remove-package.py axe very
> liberally towards the end of the release, at least for nontrivial
> FTBFS/NBS cases.

There are cases where removal is appropriate, but we have to be
cautious.  I think we are too insular a group to be able to evaluate
removals very well in general.  What seems obscure to us is likely to be
mission-critical for some of our users (see for example the medical
imaging software that was sitting on the NBS list for a while there, and
had real users evidenced by upset bug reports ...).  That's why I prefer
to process removals based on removals from Debian, as Debian's
maintenance model means that in many cases the developer requesting the
removal stands a better chance of being close to the user community or
the upstream development community than we do.

Honestly, though: most of the build failures are trivial, and while some
of them stem from poor maintenance in Debian, not as many of them
represent unmaintained packages as people seem to think.  In the case of
the 'ld --as-needed' bugs in particular, a lot of those have never been
filed in Debian, and since the packages in question are primarily
maintained in Debian, nobody with maintenance responsibility ever heard
about the problem.  We chose to introduce this linker change in advance
of Debian (for good reasons) and we, as a project, should take
responsibility for cleaning it up, rather than just giving up and
removing stuff in most cases.

I also maintain that the amount of build failure noise is a problem in
itself, and I really think it will take a lot less effort to keep that
list at or near zero than it does to get it there.  A significant
proportion of the current build failure list has been there for six
months.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]