Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 5:00 PM, Stefano Zacchiroli wrote:
> On Thu, Nov 01, 2012 at 04:30:51PM -0400, Michael Gilbert wrote:
>> > You're still making the maintainer take explicit action to stop
>> > something that he already said they didn't want to happen.
>>
>> 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 seems to me that you and Russ are talking about different NMU
> contexts. Russ seems to be referring to a context where the maintainer
> is against some specific changes and had made that clear. In that case,
> NMU won't help going around the maintainer objection. An NMU in such a
> situation will very likely be badly received.
>
> You, on the other hand, seem to be referring to a context where the
> maintainer is not against some changes and, in fact, might even welcome
> them, but simply hadn't had time to deliver. In that case NMUs would in
> most case be welcome, and they *should* be welcome as long as they're
> done properly.
Maybe an example will help get us on the same page. Russ seems to
have the impression that my proposal is somehow a license to push
unwanted changes at a maintainer. That is not true.
Let's consider mlocate as a hypothetical:
- The contributor wants a new upstream for better hurd support
- He prepares an nmu of that new upstream (making sure to not modify
the maintainer's build setup and packaging style)
- He convinces a DD that this is worthwhile to sponsor, and that DD
decides that he is willing to take the social risk involved if
something goes wrong
- The DD uploads the package to DELAYED/<whatever we agree is long
enough> and sends an nmudiff to the mlocate bts
- The maintainer gets the mail, cancels the upload, and says to the
contributor "for me hurd support is not enough to take the risk of a
new upstream upload"
- In this case, the contributor would probably say ok that's fine, and
not push it further
- But if he really thought it was that important, he would take it to
the Tech Committee, and in this case, the committee would most likely
side with the maintainer's opinion
So, overall everyone had a chance to get their say. The maintainer
had the most power (as long as they're checking their mail more often
than <whatever delay we agree is long enough>). If the maintainer
didn't have strong opinions on the upload, then there would have been
no procedural ACK/NACK roadblocks, and the Tech Committee only got
pulled if there were really strong feelings.
Best wishes,
Mike
Reply to: