Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, Nov 01, 2012 at 07:10:06PM -0400, Michael Gilbert wrote:
> 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.
Well OK, then the contributor should have talked to the maintainer before
requesting a sponsor, and the sponsor should have verified that before
uploading.
> 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.
I commented on the the described scenario, not on mlocate. But also for
mlocate, I don't see any bug "NMU intent" in the bts, and Svante Signell has
confirmed that bug 669368 was not an NMU intent.
http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=mlocate
I'm not sure how all this would fit in the debate on Lucas' proposal about
orphaning. I guess that mlocate is not the perfect example to evaluate Lucas'
proposal with.
Regards,
Bart Martens
Reply to: