[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How often is any package tested for FTBS on main arch ?



On Sat, 5 May 2012 11:34:45 +0200
Dominique Dumont <dod@debian.org> wrote:

> > i.e. not rebuild all 400 necessarily but to identify those which of
> > those 400 do not already build-depend on the packages you removed and at
> > least let the maintainers of the packages know that your change may
> > reveal an RC bug in their packages.
> 
> Sorry, no. SDL team was recenty reconstructed from scratch [1] and we have 
> only 2 active people. I don't count myself as active in sdl team as I mostly 
> do package reviews and upload. We just don't have the time to perform what you 
> suggest just to compensate for easy-to-fix packaging mistakes.

It really isn't that much work to scan through apt-cache rdepends and
then check that against Sources.gz to get a list of collated
Build-Depends.

If the new team don't have time to write and run a short script then
maybe the package would have been better off without the upload.
Maintenance is not about being an automaton with a GPG key and a
package review should include the implications of the changes on
other packages which use the package being reviewed. 

> > > Unfortunately, some package did rely on this "extra" dependencies and
> > > went ftbs [2].
> > 
> > ... which could, arguably, be jointly your fault as this could have
> > been handled cleanly if done so in advance.
> 
> Not my fault, nor current team's fault: this mistake was done years ago. We 
> are still cleaning up what we found.

The original mistake, yes, but then the package didn't FTBFS. Those
failures arise from the change you made. Albeit for sensible reasons but
not *compulsory* reasons - there is no requirement to drop unnecessary
build-dependencies, the requirement is not be lacking build
dependencies. IMHO it's perfectly acceptable to have redundant
build-dependencies *where removing them would cause breakage elsewhere*
as this gives an opportunity to get those issues fixed smoothly.

What has been achieved by removing those build-dependencies? Your
package is a bit cleaner and Debian is a bit more broken. Gee, thanks.
Less work for you, more work for the rest of us and without even a
heads-up or thought of the consequences. Sounds like you're taking more
than just Lucas for granted.

I don't seek to diminish the problems in the other packages - as Russ
points out, those packages are already ignoring Policy - but solving
those Policy issues without generating RC bugs en masse would have been
so much better.

In effect, the package upload has induced a mass bug filing without any
checks or attempts at detection let alone prevention, in the expectation
that someone else will not only pick up the pieces but identify where
things have been broken by *your* change.

To not even bother checking what might break until *AFTER* the upload
is beyond careless, it is presumptive. Maintainers of libraries have
responsibilities to the maintainers of packages which are reverse
dependencies - those include handling things like SONAME changes API
breakage cleanly and alerting them to upcoming changes with sufficient
time that packages can be adapted without breakage. If time is allowed
and nothing happens, so be it, but to upload and then confess to the
breakage only after packages have failed to build is poor.

> Actually, the whole point of my mail was to gather real data from work already 
> done. Thanks to Lucas, we know about failing packages. Too bad we don't know 
> about succeeding packages.

That would have been fine but the upload had been made without this
check being done. This could have been so much better if the discussion
had preceded the upload.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgponJbbVirch.pgp
Description: PGP signature


Reply to: