On Fri, 30 May 2008, Charles Plessy wrote: > The difference between "using the BTS" and "asking the maintainer" is > that dropping a patch in the BTS is not asking the maintainer if the NMU > is welcome.
In http://wiki.debian.org/NmuDep I see things like "Did you give enough time to the maintainer? Being busy for a week or two isn't unusual. Is the bug so severe that it needs to be fixed right now, or can it wait a few more days?" in the section "When and how to do an NMU". For me, this clearly means that the time before the maintainer had a chance to look into the issue is an important factor in the decision of NMUing or not. > When we give obvious signs of activity, I and others prefer being > consulted before a NMU is performed. You shouldn't consider an upload to DELAYED as a real upload. You are consulted about the possible NMU, it's just that lack of answer in the delay means by default "yes please do" instead of the opposite. Please try to put yourself also in the situation of someone that does NMUs. Having to mail the maintainer to ask if the NMU is welcome is pointless when you have gone to the trouble of creating a full patch. Consider the two scenario where you start with a patch for a bugfix: Your scenario: - you send the patch to the BTS to let other people know that you wrote a patch (if there's no pre-existing patch) - you mail the maintainer proposing an NMU - you write something in your calendar so that in X days you can upload if you didn't get an answer - the delay is here - you prepare the NMU - if you get a positive response (or no response), you upload - if you get a negative response, you do nothing The DELAYED scenario: - you prepare the NMU - you send the NMU patch to the BTS with nmudiff - you upload to DELAYED - the delay is here - if you get a positive response (or no response), you do nothing - if you get a negative response, you cancel The second scenario is clearly optimized for the situation where NMUs are accepted/welcome, as you have nothing to do after the initial work if your NMU is fine. The first scenario is not because you have to remember to do the upload once the delay is elapsed. Given that we also clearly communicate the message to maintainers that they shouldn't see NMU as hostile and they should be glad someone is willing to help them (see 5.11.2 "NMUs, from the maintainer's point of view"), I think it makes much more sense to optimize the workflow for the case where the NMU is accepted and welcome. I'm sure you can understand this logic. I can also understand the desire of the maintainers to be involved in the whole process, and if you stick to the facts, he clearly is, since he's the recipient of all BTS mails and can review the work and ask for cancellation of the delayed upload (or upload another fix by himself). But, in your opinion, it doesn't seem to be enough. Why? Maybe the mail sent by nmudiff should make it even more clear that the maintainer can simply use the patch and upload by himself sooner, or ask him to cancel the upload if the fix doesn't satisfy him. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
