On 31/05/08 at 21:02 +0200, Frans Pop wrote:
> On Saturday 31 May 2008, Luk Claes wrote:
> > Ok, though I'd rather have a (strong) recommendation to prod
> > maintainers (in a team or not), then to special case teams...
>
> Sure. For me it is not necessarily about "teams", but more about "active":
> likely to respond and take care of urgent issues him/her/themselves when
> prodded, thus making an NMU unnecessary.
>
> Basically I and several others have been asking to add something that
> effectively (and more explicitly than in the current proposal) says:
>
> Please consider before you NMU if just contacting the maintainer isn't
> likely to more effective than doing an NMU.
>
> In general it should be considered preferable that a maintainer
> takes care of an issue himself and that he is given the chance to
> review and correct your patch, because he can be expected to be more
> aware of corner cases and complex interactions, things that an NMUer
> might miss.
>
> Something like this could be added in the intro of 5.11. It is somewhat
> similar in intend to the text proposed by Philip Hands.
I'm not sure that it is so similar to Philip's proposal.
I have integrated your proposal in the questions at the beginning of
5.11.1, and added Philip's at the end of 5.11.1. (both are modified a
bit, but I think that the general meaning is not changed)
> NMUs should remain a fallback if maintainers really fail to respond to
> issues.
> Maintainers should also continue to be allowed to set priorities for their
> packages. NMUs force maintainers to change their priorities as they will
> *have* to deal with the NMU (either reject it or incorporate it) before
> they can resume work on other issues.
I also stressed that in the intro, and removed the second paragraph of the
intro, which didn't really add any value.
Here is the diff. Feel free to propose further improvements (I still
have to discuss those changes with Bas, too):
--- 5.11.1.orig 2008-05-31 22:48:35.000000000 +0200
+++ 5.11.1 2008-05-31 22:50:25.000000000 +0200
@@ -1,19 +1,14 @@
Proposed section 5.11: Non-Maintainer Uploads (NMUs)
Every package has one or more maintainers. Normally, these are the
people who work on and upload new versions of the package. In some
situations, it is useful that other developers can upload a new
version as well, for example if they want to fix a bug in a package
-they don't maintain. Such uploads are called Non-Maintainer Uploads
-(NMU).
-
-NMUs can happen for various reasons, the most usual one being to
-fix bugs. There are some rules to follow when doing an NMU. These
-are explained below. An NMU is allowed for any reason, as long as
-those rules are followed.
+they don't maintain, when the maintainer fails to respond to issues.
+Such uploads are called Non-Maintainer Uploads (NMU).
5.11.1 When and how to do an NMU
Before doing an NMU, consider the following questions:
* Do you really fix bugs in your NMU? Fixing cosmetic issues, or
@@ -31,12 +26,17 @@
seek advice from others. Remember that if you break something in
your NMU, many people will be very unhappy about it.
* Have you clearly expressed your intention to NMU, at least on the
BTS? Has the maintainer been notified of it? It is also a good
idea to try to contact the maintainer by other means (private
email, IRC)
+ * If the maintainer is usually active and responsive, have you
+ tried to contact him? In general it should be considered preferable
+ that a maintainer takes care of an issue himself and that he is
+ given the chance to review and correct your patch, because he can
+ be expected to be more aware of things that an NMUer might miss.
When doing an NMU, you must first make sure that your intention to NMU
is really clear. Then, you must send a patch with the differences
between the current package and your proposed NMU to the BTS.
Unless you have an excellent reason not to do so, you must then give some
@@ -59,6 +59,13 @@
especially if the patch wasn't available on the BTS before, or if you
know that the maintainer is generally active.
After you upload an NMU, you are responsible for the possible problems
that you might have introduced. You must keep an eye on the package
(subscribing to the package on the PTS is a good idea).
+
+This is not a license to perform NMUs thoughtlessly. If you NMU when
+it is clear that the maintainers are active and would have acknowledged
+a patch in a more timely manner, or if you ignore the recommendations of
+this document, be warned, there is no protection for you here. You should
+always be prepared to defend the wisdom of any NMU you perform on its
+own merits.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Attachment:
signature.asc
Description: Digital signature