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. Teams is for me just a case where you can reasonably expect NMUers to seriously consider that option, a bit more so than with solo maintainers (generally speaking). IMO people who do NMUs are mostly also people who _are_ aware of who (individual and teams) is active/responsive and who is not, so I would be very surprised if this is not the actual practice with people who already are active doing more than just an occasional NMU. 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 am not against NMUs, and also not against the DEP, but I would like to have made clear that there are cases where NMUs are just not the appropriate way to fix a pet issue, especially not for anything below RC. Categories for which I _do_ believe NMUs are appropriate: - really urgent, or important and obviously safe issues (see example acked by Frank Küster in <87ej7ide0q.fsf@riesling.zuerich.kuesterei.ch>) - changes needed for larger transitions or release goals where maintainers are failing to respond to repeated signals to do something - RC issues that affect users (excluding e.g. licence issues); I have no problems with the current practice for those - and possibly a few more The DEP should not be a licence to avoid entering into a discussion with the maintainer of a package, or to pre-empt him. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.