* 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 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
Attachment:
signature.asc
Description: Digital signature