Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 4:20 PM, Russ Allbery wrote:
> Michael Gilbert <email@example.com> 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.
It was also due to this time that there are certain members of the
project with a fear about doing an nmu and getting a violent reaction
from a maintainer, so they just don't do it; even though this kind of
reaction practically never happens anymore (unless the nmu work was
somehow horribly bad).
So, anyway, I don't see how support of more liberal nmu with longer
delays 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."
> 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.