Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote:
> On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
>> 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
>
> In this scenario the contributor should have talked to the maintainer before
> requesting a sponsor.
This would be something that his potential DD sponsors would have
taken into consideration before agree to a sponsorship. So, yes, I've
taken a bit of liberty in terms of assuming that a DD could be
convinced that mlocate was in a state where this needs to happen when
clearly its not.
Since this is a hypothetical, I'm free to set constraints, so please
assume mlocate were in a worse state than it really is above.
Best wishes,
Mike
Reply to: