Re: [PROPOSAL v2] Orphaning another maintainer's packages
Michael Gilbert <michael.s.gilbert@gmail.com> writes:
> On Thu, Nov 1, 2012 at 4:20 PM, Russ Allbery wrote:
>> Michael Gilbert <mgilbert@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: