Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
- To: firstname.lastname@example.org
- Subject: Re: DEP1: Clarifying policies and workflows for Non Maintainer Uploads (NMUs)
- From: "Giacomo A. Catenazzi" <email@example.com>
- Date: Mon, 26 May 2008 13:44:04 +0200
- Message-id: <483AA284.firstname.lastname@example.org>
- In-reply-to: <20080525065045.GF8439@a82-93-13-222.adsl.xs4all.nl>
- References: <20080525065045.GF8439@a82-93-13-222.adsl.xs4all.nl>
Bas Wijnen wrote:
5.11.2 NMUs, from the maintainer's point of view
When a package has been NMUed, the maintainer should acknowledge it in
the next upload. This makes clear that the changes were accepted in the
maintainer's packaging, and that they aren't lost again. For this, you
must first incorporate the changes into your packaging, by applying the
patch that was sent. Make sure to include the NMU's changelog entry in
your own changelog. This is important to allow the BTS version tracking
Could you clarify the above paragraph?
What do "changelog entry" mean?
- Is it a entire version entry, so the maintainer will simply add
a new debian version to the nmu changelog?
- or a changlelog line, so that the new changelog (from maintainer)
will not mention the nmu version, but only the nmu lines.
What about a new fix? Sometime maintainer does a real/clean
fix, instead of the work-around of nmu maintainer, considering
that the maintainer know better the structure of the program.
In this case, what should a maintainer do, without seeming
rude against nmu?
An other small comment, last part of
"18.104.22.168 NMUs and debian/changelog":
you write twice "security", but IMHO the security scheme
should be handled outside NMU (and in principle could
be done by the real maintainer). And there are also some
non-security updates in stable, so I prefer that you remove
the word security on the examples.
BTW I like the DEP1, and way it is written.