Re: DEP1: how to do an NMU
Frans Pop wrote:
> On Saturday 31 May 2008, Luk Claes wrote:
>>> "All members of a team becoming unresponsive" is possible, agreed.
>>> But it is a hell of a lot less likely than "at least one member of
>>> the team being able to respond to urgently needed changes if
>>> appropriately notified".
>> So, why should there be any special treatment as they are more likely
>> to respond early anyway? Or are you questioning normal NMU intents,
>> RC/RG bugs and d-d-a announcements as appropriate notifications?
> Because bugs may also have been (or seem to have been overlooked). The
> risk here is that the person doing the NMU thinks "oh, that's an old
> issue and the fix seems so simple" and goes ahead and NMUs it, while
> there may be very valid reasons for not fixing it (or at least not with
> _that_ fix).
> A follow-up to the bug report with just "hey, this issue seems to be
> forgotten, could someone please take another look as it seems important"
> would then be a lot more appropriate and take a lot less time all around
> then preparing the patch, uploading it to delayed and then getting to
> hear "sorry, this is not good, please remove your NMU from the queue".
> Large teams also often have large numbers of issues to deal with. Which
> does mean that (unfortunately) issues may be missed or forgotten about.
> Or maybe it is something that is normally taken care of by one particular
> team member and other team members ignored the issue for that reason but
> are capable of picking it up if prompted to do so.
> There is just no reason to bypass the maintainers if they are otherwise
> active. In such cases just talking to the maintainers (through the BTS or
> otherwise) is just a lot more appropriate and effective, at least as a
> first step, than going straight to an NMU - even with the safeguards
> incorporated in the DEP.
Ok, though I'd rather have a (strong) recommendation to prod maintainers
(in a team or not), then to special case teams...