...or, _How to NMU and Get Away With It_. A LaMontiana Jones adventure.
There's been some clamour recently for an explanation of how the release
process is meant to get us from here to a release. The simple answer is
that it's not.
There is absolutely no magic that can be done to make a bunch of buggy
useless software acceptable as a Debian release. To take the absolutely
simplest example, we can't release with a glibc with well known security
related bugs.
The testing scripts, the pool-ized archive software, adding, removing
and rearranging packages, none of it can do anything to help that.
But that's not to say that there's nothing at all that can be done to get
a release out when we currently have a bunch of buggy software. Indeed,
it's quite obvious what needs to be done: we need to fix it.
So, this is a call for help, primarily to existing Debian developers:
Please help fix bugs!
There are three ways you can do this, each of which requires various
different levels of skill and involvement in Debian:
* You can find bugs, and try to understand what causes them, so
that people can actually fix them. There are plenty of bugs
that've been seen but not investigated enough for anyone to be
able to work on fixing them, and they'll never get solved at
that rate. Pretty much anyone can do this, but it does require
some intelligence and some time.
* Work out a fix for the bug, test that the fix actually works,
and that it doesn't break anything else. This just involves
knowing how to program, and having a good diagnosis of the
problem, generally. Anyone can send patches to the bug tracking
system.
* Actually upload the fixed package to Debian, and ensure that it
really didn't introduce any new bugs when it gets rolled out
on the thousands of machines that run unstable. You need to
be a Debian developer to be able to do this.
Resolving a bug requires all three of these things; just doing the first
one or two isn't enough, but if you don't bother doing any of them
("There was some problem when I ran vi. Dunno why. Please fix it."),
there's absolutely no chance it'll ever get fixed.
This particular mail is focussed on the last of these. Right now, we're
doing an absolutely abhorrent job of actually getting fixes into
Debian. In our release-critical bug list (which, you'll recall, is
a list of packages that have security issues, like to rm -rf / when
you install them, don't work at all, don't build on our autobuilders,
and similar things) we have dozens of bugs with known fixes that we,
as a group, haven't managed to actually apply and upload.
The reason we've been so poor at this, is that for some reason it's become
taboo for anyone except the package's maintainer to make uploads. There
is no good reason for this, and there are many reasons against it.
As of now this is no longer the case. Non-maintainer uploads of packages
are *okay*. If you're not uploading new versions of your package when
improvements become available in a timely manner, don't act surprised
if someone else does.
This will continue until woody's release when it'll get re-evaluated,
or when chaos and darkness take over the universe by way of general
resolution.
That's not all there is to say about it though. Hit and run package
maintenance doesn't work, and it's very easy to fall into that frame of
mind when you're uploading packages that you don't maintain.
So, if you're going to NMU packages (and this applies to the porters
who've been doing NMUs already too) please be *very* careful of the
following things:
* A maintainer upload is better than a non-maintainer upload.
Merging stuff from an NMU takes time and care. If it's not
necessary, why the maintainer to waste time doing that instead
of fixing other bugs or adding new features? OTOH, an NMU is
better than nothing.
* If you understand a bug better than the maintainer, or if
you can provide a fix and the maintainer can't, then pass on
that information to the maintainer. Not everything needs an NMU.
* Generally (especially for normal or wishlist bugs) there's no
reason not to give the maintainer a little time to digest the
bug, or its fixed. Refer back to the first point. If the bug
hasn't been filed yet, or the patch hasn't been sent to the bug,
you almost certainly shouldn't be making an NMU... yet. One way
to make this a little easier on you as an NMUer, is to use the
incoming/DELAYED directory. Stuff uploaded to
incoming/DELAYED/5-day/
will be moved into incoming in five days, so you can email
xxx@bugs.debian.org with a note that says "This bug can be fixed
by applying this patch [...]. I've uploaded an NMU with version
number X-Y.Z into incoming/DELAYED, so it'll get processed in
five days, if you don't get around to it sooner."
* Once you've made an NMU it is your responsibility to make
absolutely sure you didn't break the package (in spite of
your copious testing of it), and, if you did, to fix it. Check
the package's bug page(s) regularly. Subscribe to the package
through the PTS to get copies of its bug reports.
The above are only guidelines as to *when* you might wish to do an NMU. You
still need to follow all the usual steps in making sure your NMU is good:
* Get it right. Test, test, test, and keep on testing.
* Set the version number to the approriate -X.Y
* Don't mess with the way the maintainer likes to maintain his
package. An NMU isn't an opportunity to debhelperize someone's
package, nor to override the maintainer's decision about which
bugs should be fixed, or how they should be fixed.
There are probably others too. Try to make sure your NMU is something
the package maintainer would be proud to have uploaded.
There may be more things than this that you can do to make Debian more
reliable and less buggy. In some cases, there may be no need to worry
about one or another of the above. Mostly: use your head, try not to
get in anyone else's way, and, if you make a mistake, fix it.
There are a lot more things to fix than "the package doesn't build on
one of hppa, ia64 or s390". There should be more people making high
quality NMUs than just LaMont and Gerhard.
Cheers,
aj (woody release manager)
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
GPG signed mail preferred.
The daffodils are coming. Are you?
linux.conf.au, February 2002, Brisbane, Australia
--- http://linux.conf.au/
Attachment:
pgpHHKJl2qFuj.pgp
Description: PGP signature