Re: DEP1: how to do an NMU
On Tuesday 03 June 2008, Don Armstrong wrote: > No matter what is done, there is a time limit for the review of > patches which fix RC bugs, whether stated or not. If a maintainer is > unable to respond to a patch for an RC bug in a reasonable timeframe, > they should expect an NMU. It matters little how the timeframe is > enforced; it's there regardless. Sure. I've never in this thread disagreed with that. signature.asc Description: This is a digitally signed message part.
Re: DEP1: how to do an NMU
On Tue, 03 Jun 2008, Frans Pop wrote: > 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. No matter what is done, there is a time limit for the review of patches which fix RC bugs, whether stated or not. If a maintainer is unable to respond to a patch for an RC bug in a reasonable timeframe, they should expect an NMU. It matters little how the timeframe is enforced; it's there regardless. Non-RC bug fixes are an entirely different beast, but NMUs for them are generally discouraged anyway. Don Armstrong -- Mozart tells us what it's like to be human, Beethoven tells us what it's like to be Beethoven, and Bach tells us what it's like to be the universe. -- Douglas Adams http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DEP1: how to do an NMU
On Tuesday 03 June 2008, Bas Wijnen wrote: > I would of course do that. But you do indeed ask me to hide the > package? And after, say, 3 weeks have passed and nothing happened > (which is unlikely, but possible), I can upload it to DELAYED/7? Then > why couldn't I upload to DELAYED/28 in the first place? Or must I wait > indefinitely? I'm not going to keep on repeating what I've already explained 5 times by now. I hope it is now clear that we do in fact have some fundamental differences of opinion (something I have absolutely no problems with). As I'm happy with the DEP with the lastest changes included by Lucas, I don't see much point in continuing this discussion, especially not as it's not going anywhere. The current text requires people preparing patches to actively consider whether an NMU is appropriate for each specific case, which is good. It also allows them to do the NMU and use DELAYED if they feel they can justify it, which is also good. Hopefully it will prevent people from behaving like mindless NMU machines, which would be very bad. Let's leave the rest up to how things evolve in practice. There are bound to be some interesting flame fests^W^Wdiscussions over interpretation and practice, but in most cases I expect things will work out fine. Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: DEP1: how to do an NMU
On Tue, Jun 03, 2008 at 11:51:02AM +0200, Frans Pop wrote: > 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. This can be the expectation. However, if there is (unexpectedly) no reply for a long time (whatever that means), then an NMU becomes the correct way. > > 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. I would of course do that. But you do indeed ask me to hide the package? And after, say, 3 weeks have passed and nothing happened (which is unlikely, but possible), I can upload it to DELAYED/7? Then why couldn't I upload to DELAYED/28 in the first place? Or must I wait indefinitely? > > 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. So you are saying that NMUs should be forbidden completely? Even after waiting for a month? And after waiting for a year? You must agree that at some point, NMUs are acceptable? What's wrong with making things clear in advance and using DELAYED? The fact that you don't expect the upload to unstable to actually happen doesn't make it wrong to schedule it, IMO. > 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. My suggestion doesn't change anything in this respect. All I want to see is that the suggestion that using DELAYED is not allowed in some cases should be removed[1]. If a maintainer is away for long enough, then his packages _can_ be NMUed without the DELAYED queue *anyway*. [1] Note that it's only a suggestion anyway; the text currently does say what I want, strictly speaking. > 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. For those cases, if the NMUer uses a long delay (and he should, also according to the DEP), it is irrelevant if there is a package in the DELAYED queue or not. I'm not suggesting that people should upload to DELAYED in those cases, I only want to make it explicit that it's no problem. > 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. Again, I don't want to suggest people to do it, only allow them. The only assumption behind this is that every package may be NMUd, if the maintainer is inactive long enough (however unlikely that may be). That is not "completely abandoning" the concept of maintainers, but it is putting limits on it. Which is exactly what NMUs are meant for. Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://pcbcn10.phys.rug.nl/e-mail.html signature.asc Description: Digital signature
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 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.
