Debian Developers - 0-day NMUs [Was: Bug-Squashing Week, August 16th

Author

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

Steve Langasek

2004-08-12, 2:49 am

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
sarge.

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
transition.
- 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

Stephen Frost

2004-08-12, 7:52 am

* Steve Langasek (vorlon@debian.org) wrote:
> On Wed, Aug 11, 2004 at 11:35:31PM +0200, Frank Lichtenheld wrote:
>
> 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
NMU.

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
it.

> - 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
can.

> - 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.

Stephen

Steve Greenland

2004-08-12, 5:58 pm

On 12-Aug-04, 08:19 (CDT), Stephen Frost <sfrost@snowman.net> wrote:
>
> And give the maintainer an opportunity to respond to those bugs, at
> *least* a couple of hours..

A "couple of hours" is effectively "no time at all". Not every developer
can monitor their e-mail every hour, 24 hours a day. Some of us sleep,
ya know. :-)

I'd say either be prepared to wait a few days, or do it right away and
upload it to, say, the 3-day delayed queue (posting bug, patch, and NMU
status to BTS). That gives the maintainer a chance to look at it and
reject/correct, but allows you (the NMU-er) to move on.

Steve

--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Stephen Frost

2004-08-12, 5:58 pm

* Steve Greenland (steveg@moregruel.net) wrote:
> On 12-Aug-04, 08:19 (CDT), Stephen Frost <sfrost@snowman.net> wrote:
>
> A "couple of hours" is effectively "no time at all". Not every developer
> can monitor their e-mail every hour, 24 hours a day. Some of us sleep,
> ya know. :-)

Erm, it's at least something though. No, we don't all monitor it 24/7,
but I think it'd be better than nothing, as I mentioned, a day would be
better.

> I'd say either be prepared to wait a few days, or do it right away and
> upload it to, say, the 3-day delayed queue (posting bug, patch, and NMU
> status to BTS). That gives the maintainer a chance to look at it and
> reject/correct, but allows you (the NMU-er) to move on.

The complaint was that waiting 3 days was too long. I don't believe the
NMU'er should be concerned only with 'moving on'- once the NMU is done
they *have* to monitor the package afterwards too in order to make sure
their NMU didn't cause problems.

Stephen

Steve Langasek

2004-08-12, 5:58 pm

On Thu, Aug 12, 2004 at 09:19:57AM -0400, Stephen Frost wrote:
> * Steve Langasek (vorlon@debian.org) wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> 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
> NMU.

Well, while you've brought this up before, there seems to be a shortage
of data points for us to look at that would support an argument that
delayed NMUs result in an improvement in the quality of packages that
hit the archive. What we do see is that the overall *volume* of NMUs
increases when 0-day NMUs are instated, which would suggest an increase
in the absolute number of broken NMUs -- but not necessarily a relative
increase.

> 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.

Which, in fact, means that the sooner the NMU for one of these packages
reaches the archive, the better the chances that someone will notice the
problem before release, since there's more time for people to look.

--
Steve Langasek
postmodern programmer