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

Re: DEP1: how to do an NMU

On Monday 02 June 2008, Bas Wijnen wrote:
> > The fundamental thing we disagree on is that you think creating a
> > patch and doing an immediate upload to DELAYED is an acceptable
> > workflow for any kind of issue.
> Yes.  Not recommended, but certainly acceptable.  With a long delay, of
> course.

My basic point is that in some cases doing an NMUs at all is not the 
correct way to get a change into Debian.

> If I want to create a package, then I will do that.

If you want to create a package for local testing, fine. If you create a 
package for upload: no. In some cases packages should not be NMUed at 
all. Or certainly not before the maintainer has had a chance to review 
the patch *at a time when it suites the maintainer* instead of within a 
time limit imposed by whatever value the author of the patch chose for 

> What would you recommend me to do?  Tell you about the problem and hide
> the package for some time?

Submit the patch to the BTS and wait for a reaction from the maintainer, 
same as we've been doing for the past X years.

> What is so special about the DELAYED queue that makes a package in
> there different from a package on my local hard drive, waiting to be
> uploaded in case the maintainer doesn't reply (or accepts it)?  What if
> I schedule an at job to upload it?  Must I not tell you that the upload
> will (if needed) be done by atd, and suggest that I will personally
> come back to it?

You must not upload it AT ALL. Not directly, not to DELAYED, not scheduled 
in any way. Just leave the maintainer his responsibility for maintaining 
his packages. Do not try to preempt him; do not force him to deal with 
your NMU instead of following his own priorities.

The maintainer will see your patch, will mentally add it to his ToDo list 
and will deal with it at his own convenience. If he is a responsible 
maintainer (and let's assume most are), he will deal with important and 
even with trivial issues quickly. But he should be allowed to "batch up" 
less important or more complex issues to deal with when it suits him.

He should also be allowed to just commit the patch to his source 
repository and mark it "pending" without the need to either upload 
directly to cancel the DELAYED NMU upload, or to have to ask that the 
DELAYED upload be cancelled (and then have to check that this is actually 

And he should also not find that, because he was on holiday for 2 weeks, 
all kinds of incorrect fixes for minor issues have made it into the 
archive just because he missed the DELAYED window.

Again: I'm not proposing that the above be the standard procedure, but it 
should the the procedure that is followed for generally well-maintained 
packages by active maintainers/teams, especially for native packages and 
non-urgent issues.

Unless we completely abandon the concept of "maintainer of a package", 
using DELAYED for just any random change for any random package as you 
seem to want is just plain wrong.
I have listed the cases in which I think using DELAYED is no problem in an 
earlier mail.

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: