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

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

Hi all,

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.

I would therefore like you all to consider it open-season on RC bugs,
including 0-day NMUs if appropriate, from now until the release of

All the usual rules about NMUs still apply:

- If you upload a package, get it *right*!
- 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.
- 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
- Don't make cosmetic changes to packages.  The more you change, the
  greater the chances of breaking something -- or of disagreeing with
  the maintainer.
- Send your patches to the BTS *before* you upload your package.
- Focus on older bugs first.  Working on bugs less than 7 days old, or
  bugs that have just been upgraded to RC severity, is more likely to
  duplicate the efforts of the maintainer.
- Be respectful of the maintainer.
- Once you've NMUed, be sure to track the progress of the package, and
  clean up any messes you left behind.

If you follow these rules, you can reasonably expect your NMU to be
successful and to advance the goal of a quick sarge release.

Happy bug squashing,
Steve Langasek                                     [vorlon@debian.org]
on behalf of the release team

Attachment: signature.asc
Description: Digital signature

Reply to: