Re: NMU policies for etch
Henrique de Moraes Holschuh <email@example.com> wrote:
We should really document the result of this discussion in the
developers' reference, which currently says:
| NMUs which fix important, serious or higher severity bugs are
| encouraged and accepted.
This I always interpreted as "NMUs which fix normal, minor or wishlist
bugs (only?) are discouraged and widely not accepted".
> On Tue, 18 Oct 2005, Frank Küster wrote:
>> Shouldn't NMU's without the maintainers approval be restricted to RC and
>> maybe important bugs?
> No, unless you add some sort of timeframe. MIA or otherwise absent
> maintainers are the usual reason why one needs NMUs.
If a maintainer is "otherwise" absent, he usually sends a mail to
-private which says "NMU as needed", and it's up to you to balance the
impact of the fix with the time of vacation.
If a maintainer is MIA, the package should be orphaned and/or the
maintainer set to QA. Until this has happened, we might have to relax
the NMU policy on that package. However, as always this should be made
transparent: There should be notes to the most interesting bugs (or on
the bug or qa page of the package) that the people interested in the bug
suspect the maintainer to be MIA. This way, everybody can see how long
it has been noticed that the package is badly maintained, and know
better what timeframe is appropriate for an NMU.
Furthermore, please note that the developers' reference recommends to
| Follow what happens, you're responsible for any bug that you
| introduced with your NMU. You should probably use The Package Tracking
| System, Section 4.10 (PTS) to stay informed of the state of the
| package after your NMU.
Which means that you'll get more and more mails if you NMU many
packages, and that you should consider taking over a package that you
NMUed more than once...
Inst. f. Biochemie der Univ. Zürich