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 DELAYED. > 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 done). 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.
signature.asc
Description: This is a digitally signed message part.
