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

Re: 0-day NMUs [Was: Bug-Squashing Week, August 16th - 22th]

* Steve Langasek (vorlon@debian.org) wrote:
> On Wed, Aug 11, 2004 at 11:35:31PM +0200, Frank Lichtenheld wrote:
> > We need to make sure that we don't make things worse by introducing
> > wrong fixes or breaking packages. Therefor we should _not_ introduce
> > something like a 0-day NMU policy. DELAYED/3-Day should suffice for most
> > cases. As usual patches should be made minimal, especially so short
> > before release!
> I'm afraid I have to disagree with Frank.  Particularly so close to the
> release, 3 days can definitely make the difference between a package
> being ready in time for sarge, and not being ready in time.  Moreover,
> history shows us that 0-day NMUs have been very effective at bringing
> the RC bug count down rapidly.

There are easier ways to get the RC bug count down rapidly.  The
challenge is to actually improve packages to the point where they're
releasable.  Unfortunately, it's also hard to gauge if an NMU improved a
package or not.  wrt those packages which were 0-day NMU'd previously
which had non-MIA maintainers I've heard a number of complaints about
the NMU and where the maintainer has done another upload to correct the

Of course, there are quite a few packages w/ MIA maintainers and so you 
don't immediately hear about poorly done NMU's except to see the RC 
bugs get closed.

> - If you upload a package, get it *right*!

This is really a critical thing, you should go over your NMUs *very*
carefully, and test them a great deal.  If you can't test them, then you
shouldn't be NMU'ing them!  Find someone using it and get them to test

> - If it's not in the BTS, it's not justification for an NMU.  Don't try
>   to NMU for bugs you haven't filed yet.

And give the maintainer an opportunity to respond to those bugs, at
*least* a couple of hours..

> - Don't upload gratuitously.  The focus of this BSP is getting ready
>   for sarge; that means only NMUing packages with release-critical bugs.
>   Translation NMUs are not necessarily a priority here, since there's
>   time for those to be uploaded through testing-proposed-updates later,
>   but l10n folks, use your best judgement as always.  However, *please*
>   be mindful of the effect your NMUs could have on the ongoing libtiff
>   transition.

Yes, translators, understand that when you do an upload, even if it's
just for the translation update, you *do* change the build environment
and while this *shouldn't* hurt things, be *very* careful, because it

> - Send your patches to the BTS *before* you upload your package.

Again, give the maintainer at least the opportunity to respond, send
your patch and then wait a bit before uploading, a couple hours at a
minimum, though I'd rather you wait a day, personally, timezones not
being equal and all.

> - Once you've NMUed, be sure to track the progress of the package, and
>   clean up any messes you left behind.

Yes, please, realize that you *have* committed yourself to cleaning up
any mess that your NMU causes.  Certainly if your NMU causes other RC
bugs then you're not helping anyone.


Attachment: signature.asc
Description: Digital signature

Reply to: