Hi, On 01.11.2012 00:16, Michael Gilbert wrote: > It's not that common to encounter maintainer's with this kind of > unproductive attitude, but when it does happen it seems to occur > rather often in important packages. Thus, we should really have a > documented guideline for these cases. The go ahead and fix it via nmu > is one solution that has been quite effective so far and seemingly > uncontroversial to the maintainers that had been getting in the way. Developer's Reference contains a guideline for this case. It is by no way forbidden to package new upstream versions or less important issues in NMUs. Point being is, NMUs should aim to make changes in spirit of the packager and in line with his packaging work. That's not measured by keeping the upstream version or by fixing RC bugs only, but by being gentle to the maintainer, keeping the design decisions made and only touch issues which you consider really beneficial and justify that you enter in someone else's domain. I keep repeating myself: People really shouldn't be afraid to NMU, we need more NMUs - genrally speaking - but it should be done in a nice and friendly way and by respecting design choices by others. A NMU is not about forcing someone else to obey your personal tastes and preferences. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D
Attachment:
signature.asc
Description: OpenPGP digital signature