[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

> 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.

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.


Bart Martens

Reply to: