Michael Gilbert <michael.s.gilb...@gmail.com> writes: > Is it reasonable to do an NMU that has a debdiff equivilent of around > 500 upstream git commits (the size of ever new upstream wine release)?
I don't think it's possible to answer that question with a firm yes or no. It depends heavily on the situation, what bugs such an NMU closes, and so forth. I could see it being appropriate for fixing some major outstanding bugs, particularly in lead-up to a release, where the person uploading the NMU isn't willing to take ongoing responsibility for the package but is willing to try to get it more functional for a release. My general feeling, though, is that NMUs are not a great fit for doing major improvements to the package, since they leave ambiguous who is going to be supporting the package going forward. Someone uploading an NMU is taking responsibility for fixing problems introduced by the NMU, but not (normally) taking responsibility for ongoing maintenance of the package going forward. But if the change is substantial, the existing maintainer may be in even less of a good position to take responsibility for maintaining the package than they were before. When we're talking about packaging significant new upstream releases, I think NMUs are dodging the problem in a somewhat unuseful way, and we really need to sort out the maintenance of the package going forward instead. Personally (and, for that matter, as a Technical Committee member), I'm going to generally lean towards letting the person with time do the package maintenance work rather than the person with no time, even if the standards and practices that the person with no time would like to work within are admirable and strong. It feels to me like a fairly fundamental rule of free software that, modulo cases where there's a serious technical disagreement that could lead to software not working or doing nasty things, that people who don't have time to do work don't get to block people who do have time to do work. I try to apply that to myself as well; if I don't have time to do it "right," then at some point I no longer really have a right to tell other people how to do it and require that they do it that way. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87pqb5dq44....@windlord.stanford.edu
