Michael Gilbert <michael.s.gilb...@gmail.com> writes: > On Thu, Nov 1, 2012 at 4:20 PM, Russ Allbery wrote: >> Michael Gilbert <mgilb...@debian.org> writes:
>>> Not if the nmu has a sufficient delay (DELAYED/10 or DELAYED/30 or >>> whatever would be agreed on). The maintainer can cancel things that >>> he doesn't like before they get uploaded. >> You're still making the maintainer take explicit action to stop >> something that he already said they didn't want to happen. I don't see >> why you think this is going to make anything better. I believe nearly >> everyone is going to react badly, and possibly strongly, to that sort >> of action. That's just how humans work. > For a time, this is how regular nmus were greeted, but as a project, > we've gotten over that unwarranted stigma and recongnized nmus as > valuable contributions that do a lot to help when the maintainer (for > whatever reason) isn't getting around to fixing his/her own problems. This is absolutely not true when it's not a matter of the maintainer not having time and is instead a matter of the maintainer saying "I do not want a new package uploaded with those changes at this time." > So, anyway, I don't see how support of more liberal nmu with longer > delays will cause "nearly everyone" to react badly. An NMU against the maintainer's explicit wishes will cause nearly everyone to react badly. > We've already done it for wine and python2.6 with 0/2 badness, and 0% > badness rate is not even close to some kind of percentage needed to > qualify as "nearly everyone." My understanding is that this was not the same situation. You weren't acting directly contrary to the maintainer's stated wishes; you were doing work that the maintainer wanted done, but didn't have time to do and wasn't sure on the quality when done by someone else. It's not the same sort of thing as having the maintainer respond to a patch with "not now" and someone else then uploading it anyway. >> If that's what we are going to do, we should do it openly and clearly >> and with the proper technical support (such as, for example, pushing >> the package into a shared VCS so that the person making the changes can >> incorporate them into the same packaging that the maintainer will be >> using for the next maintainer upload). > That doesn't help in the unproductive maintainer case. They reject > these kinds of collaborative efforts. Which is why we have governance procedures. I don't think we are going to get the social environment that we all want to have by replacing governance procedures with an invitation for any DD who cares about a problem to upload an NMU whether the maintainer likes it or not. I'm all in favor of people being less worried about doing NMUs when the maintainer is unresponsive for whatever reason, or for things that, as a project, we have a consensus around using NMUs for. (Long-delayed translation updates, for example, particularly when approaching a freeze.) But NMUs are not a mechanism to resolve disputes between the maintainer and someone else. Once the maintainer has responded and said "no," an NMU is no longer the first tool to be reaching for. It may still be appropriate in some situations, but it's now much more likely to be perceived as an openly hostile act. -- 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/878valkq38....@windlord.stanford.edu
