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

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages



On Thu, Oct 25, 2012 at 9:50 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Scott Kitterman writes ("Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages"):
>> Why not start with a "without objection" standard and see how it
>> works?
>
> I absolutely agree with this.
>
> If we adopt a "without objection" standard then the whole process can
> be a lot simpler too.  There is no need for acks if any one nack is
> sufficient to stop the process.
>
> I'm also not that keen on the idea that the outcome is to orphan the
> package.  The salvager should surely be adding themselves as an
> Uploader.
>
> So I would have this process
>
>   1. Package is "in the salvager's opinion in need of substantial and
>      important attention; maintainer has been inactive on this
>      package, and in need of help with it, for some time".
>      It doesn't need to be an objective criterion.
>
>   2. Notify various places (-devel and the BTS, at least)
>
>   3. Wait for objections
>
>   4. If no objections, add salvager to Uploaders.
>

I would prefer to see even more autonomy for the salvager and less
bugging of various lists (ITPs on -devel are already distracting
enough).  With that, I would like to suggest rewriting steps 2-4 as:

    2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
         the package into a better maintained state.

    3.  After a period of 3 months of contributing as an nmuer or with
        maintainers approval prior to that, salvager is free to add
        himself/herself as a package uploader.

    4.  After 6 more months without contribution from the original
        maintainer, the salvager is free at his or her discretion to
        remove the original maintainer.

    5.  The salvager should do his/her best to address original mantainer's
        concerns in a manner that would please them, and any unresolvable
        conflicts should be deferred to the Technical Committee.

Note that this process was pretty much the one I followed to salvage
wine.  Also, the python maintainer Tech Committee decision would have
been much easier if the people complaining had been following this
kind of process where there would have been evidence that their nmus
were contributing to a better package.  It eliminates the complaints
without action issue.

Best wishes,
Mike


Reply to: