Hi,
In an effort to move the discussion forward, here is a new version of
the proposed section 5.11.1. (Bas Wijnen didn't have a chance to have a
look at this yet)
It tries to address the comments about communication with the maintainer
prior to the NMU, and about giving some time to the maintainer to react.
Steve, Manoj, Charles, Richard, does this address your concerns?
If not, can you propose some additional changes?
-------------
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
changing the packaging style in NMUs is discouraged, unless it
is required to fix bugs.
* Did you give enough time to the maintainer? When was the bug
reported to the BTS? 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?
* How confident are you about your changes? Please remember the
Hippocratic Oath: "Above all, do no harm." It is better to leave
a package with an open grave bug than applying a non-functional
patch, or one that hides the bug instead of resolving it. If you
are not 100% sure of what you did, it might be a good idea to
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)
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
time to the maintainer to react (for example, by uploading to the DELAYED
queue). Here are some delays that you could use as default values:
* Upload fixing only release-critical bugs older than 7 days: 2 days
* Upload fixing only release-critical and important bugs: 5 days
* Other NMUs: 10 days
Those delays are only examples. In some cases (uploads fixing security
issues, trivial bugfixes blocking a transition, ...), it is desirable
that the fixed package reaches unstable sooner.
Sometimes, release managers decide to allow NMUs with shorter delays for
a subset a bugs (e.g release critical bugs older than 7 days). Also, some
maintainers listed themselves in the Low Threshold NMU list, and accept
that NMUs are uploaded without delay. But even in those cases, it's still
a good idea to give the maintainer a few days to react before you upload,
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).
--
| Lucas Nussbaum
| [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
