On 2013-03-16 12:13, Lucas Nussbaum wrote:
The current NMU guidelines[1] discourage fixing cosmetic issues or changing the packaging style in an NMU. The reason for that is thatsuch changes are often a matter of taste (though there are exceptions,such as the standardization of debian/control fields - going from X-Vcs-* to Vcs-*).
I only intended to include distribution-wide changes that have already been agreed as goals. Even where everyone has agreed on a change, we are often quite slow to adapt all packages. The classic example is the /usr/doc transition, but I don't think we've really solved the problem since then, just made it less bad by more use of helpers.
My suggestion was only sometimes to accelerate further our existing methods. Pushing more "standardisation" could be worthwhile in some cases, but is a separate debate.
Could you give examples of specific distribution-wide changes that youthink we should authorize via NMUs?
I am not trying to push specific technical changes, only to suggest that we shouldn't assume that distribution-wide changes need to wait for the slowest maintainers. (And I don't think that people really assume this currently, in fact; already for each such change a few NMUs would be likely eventually.)
For example, would that apply to debhelper -> dh conversions? To 1.0 ->3.0 (quilt)?
Only if we had already reached agreement that these are goals we were moving towards. At that point, they would stop being merely matters of taste/cosmetic.
Specifically, how do you think we can decide to authorize NMUs for a specific distribution-wide changeover?
Changes should be decided in the same ways we already decide about transitions and policy.
The NMU-encouragement aspect itself I would expect to be linked to the release team.
-- Moray