Re: DEP1: how to do an NMU
On 01/06/08 at 00:22 +0900, Charles Plessy wrote:
> Le Sat, May 31, 2008 at 12:20:55PM +0200, Lucas Nussbaum a écrit :
> > Unless you have an excellent reason not to do so, you must then give some
> > time to the maintainer to react
> Hi Lucas,
> excellence is definitely what we should aim for :)
> Thank you for your efforts. Here are my last comments on the DEP:
> 5.11.1 When and how to do an NMU
> I propose to add "NMUs are usually not appropriate for team-maintained
> packages. Consider sending a patch to the BTS instead." to the bullet
It really depends on the team. There are small teams where all members
might become unresponsive at the same time. I don't think that we should
> 18.104.22.168 Using the DELAYED/ queue
> I propose to ask a paragraph saying:
> "If you do not make your NMU to DELAYED/, you must document your reasons
> in the BTS."
> I and others had NMUs on non-RC bugs on team-maintained packages while
> being active and we are still left to wonder what in our packaging
> practice was so wrong that it had to be fixed in emergency. Having the
> reason written in the BTS would help us to improve ourselves.
Can you give a specific example where this happened? Did you raise the
subject on -devel@? Have you asked the NMUer why he did that?
I think that the DEP should reduce this risk. Actually, with the 0-day
NMU policy on RC and RG > 7 days old, it's currently perfectly allowed
to NMU a team-maintained package for an RG bug without prior contact
with the maintainer. I don't think that it's a good policy in many cases
(like the one you describe), and it's one of my motivations for this
Even if this DEP is accepted, it doesn't mean that we can't come back to
this discussion in a few months, and reconsider some things. I would
prefer to keep the current wording for now, and re-discuss this later,
if this proves to be an issue with the current wording.
> 5.11.2 NMUs, from the maintainer's point of view
> The last two sentences, "Make sure to include the NMU's changelog entry (not
> just the line describing the changes) in your own changelog. This is
> important to allow the ¥BTS version tracking to work.", are misleading
> on how the BTS work, as they suggest that the version tracking depends
> on the changelog. Maybe they could be changed to:
Well, that's the case, see
> "Make sure to include the NMU's changelog entry (not
> just the line describing the changes) in your own changelog if you want
> to take advantage of the automatic BTS version tracking."
I'll change that to:
Make sure to include the NMU's changelog entry (not just the line
describing the changes) in your own changelog, to allow the automatic
BTS version tracking to work.
> I think that both sides made enough efforts, so please do not take this
> mail as a list of requirements, alhtough of course I would prefer my
> points being taken into account.
> I am moving into a place where internet is not yet set up, so do not
> expect timely answers. Please go ahead :)
Have fun :)
| Lucas Nussbaum
| firstname.lastname@example.org http://www.lucas-nussbaum.net/ |
| jabber: email@example.com GPG: 1024D/023B3F4F |