About 0-day NMUs and NMU policies (Re: package ownership in Debian)
* Joerg Jaspert [Fri, 28 Jul 2006 22:23:34 +0200]:
Hi. I'm replying here because it seems it's where it started the 0-day
idea that has been later repeated all over the thread.
> Simply change the NMUs to be always 0-day, for all bugs >=normal. Which
> means - upload and mail to BTS at the same time.
A NMU policy is defined by three variables: (days_until_uploadable,
days_for_review, min_severity). This way, our current policy for RC bugs
is (7, 0, serious), and the one you propose for this "package ownership
problem" (X != 0, 0, normal).
Personally, I think that if we want the experiment to be successful, you
can't start with such a relaxed policy. For non-RC bugs, I think the set
(21, 7, normal)+(14, 7, important) is a pretty healthy one.
Lowering days_for_review
------------------------
I really believe (as Simon pointed out) having the NMU diff live a few
days in the BTS before entering the archive does help QA, because
there's room for peer review (from the maintainer, or PTS subscribers,
or even person interested in that particular bug, and subscribed to it).
Because of this, I don't think "days_for_review" should be lowered at
all except if it's clear that doing so will really pay off. And for
non-RC bugs, I think a week works just fine.
Thoughts on our current RC NMU policy
-------------------------------------
When you do a delayed upload, there's always the possibility that the
maintainer will upload themself, making you feel your effort, if not
worthless, somehow dismissed. So with days_for_review != 0, you end up
NMUing only for those bugs that you really care about, that you want
fixed so badly that it doesn't matter where the fix finally comes from.
IMHO this is good, because it means they'll be prepared with more care.
But, OTOH, most RC bugs don't matter much to each of us individually,
but only in the sense that they can delay the release. If it's going to
be a big PITA to provide a fix for one of them, though, plenty of times
it won't be enough.
I don't know if it was its original intent or not, but if you ask me,
it's precisely this what having days_for_review = 0 for RC bugs buys us,
i.e., not so much having the fixes appear earlier in unstable and hence
in testing, but acting as an incentive, since the uploader gets an
immediate reward, which results in a bigger amount of uploads.
Hopefully, when Etch gets released, we'll look back and confirm that
giving up that bit of peer review was worth it, and that having that
tool named 0-day NMUs available did really help our release process.
It is important, though, to never forget that doing a 0-day NMU is a bit
like driving an ambulance: you have the right to go fast when/if it's
crucial for the person inside to arrive the hospital ASAP... alive. If
you're carrying a minor injured, or you're a novel driver, or it's
raining like hell, you still have the right to go fast, but it's maybe
not the best thing to do. (a.k.a. "nobody prevents you from uploading
NMUs to DELAYED.) :)
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
A lie can go round the world before the truth has got its boots on.
-- Terry Pratchett
Reply to: