Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
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/
Reply to: