Re: [PROPOSAL v2] Orphaning another maintainer's packages
- To: email@example.com
- Subject: Re: [PROPOSAL v2] Orphaning another maintainer's packages
- From: Bart Martens <firstname.lastname@example.org>
- Date: Fri, 2 Nov 2012 09:50:55 +0000
- Message-id: <20121102095055.GB515@master.debian.org>
- In-reply-to: <CANTw=MNiTUOyQk9YW27SMjyuE7Dd75MhG9FGRr+nZ8T0jBy82A@mail.gmail.com>
- References: <email@example.com> <20121030135212.GA10585@an3as.eu> <firstname.lastname@example.org> <20121031070545.GB32333@an3as.eu> <20121031080420.GB11941@client.brlink.eu> <email@example.com> <20121031183400.GA17521@master.debian.org> <CANTw=MNCgtiFWg9XC6ZJf9Pp+O67njyxf=xP7Uyv6GOdy0Z3jg@mail.gmail.com> <20121101084855.GB26040@master.debian.org> <CANTw=MNiTUOyQk9YW27SMjyuE7Dd75MhG9FGRr+nZ8T0jBy82A@mail.gmail.com>
On Thu, Nov 01, 2012 at 01:58:28PM -0400, Michael Gilbert wrote:
> On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote:
> >> wine: http://bugs.debian.org/585409 (new upstream pushed via nmu)
> > This is a good example where talking helped to gather all views on all aspects
> > from all involved people. My impression is that finally the maintainer allowed
> > new co-maintainers doing things differently. That does not really match Lucas'
> > proposal which is about marking packages as orphaned so that they can be taken
> > over by a new maintainer.
> It matches my proposal where interested contributors apply nmus as
> needed to improve the situation, then eventually become uploaders.
I didn't say that the series of NMUs should be used as a model for a new
procedure in dev-ref. I said that my impression is that finally the maintainer
allowed new co-maintainers doing things differently.
I understand that you meant to bring attention back to your proposal, so I
looked it up here:
I already briefly commented on it here:
Other than that, I cannot support your proposal, because I really think that
when a maintainer is not maintaining a package anymore that new contributors
should get full package (co-)maintainership from the start, with consent from
the (previous) maintainer or from the TC or after orphaning. Lucas' proposal
currently only addresses how the package could be orphaned. An NMU is meant as
an occasional help, not as a step in taking over maintenance. I agree however
that a series of NMUs is often one of the signs that the maintainer is not
maintaining the package anymore.
> >> python2.6: http://bugs.debian.org/679030 (new upstream pushed via nmu)
> > This does not seem to be an example of "the maintainer refuses to package any
> > newer upstream". This seems to be just an NMU, not related to Lucas' proposal.
> As we were getting close to the freeze, python2.6 was in a poor
> situation where it was going to ship with 2.6.7 in wheezy, and thus
> lack a whole bunch of security updates. Julien Cristau made the
> decision that this would be unacceptable, and prepared a new upstream
> nmu resolving the inactivity.
> This is certainly a case of a maintainer acting in an unproductive
> manner. The previous 2.6.7 upload was made almost an entire year
> prior to that.
I don't see "a maintainer acting in an unproductive manner" but rather "a
package that got temporarily less attention so occasional help from others via
NMU was helpful". Now that I look at this example again I see Julien Cristau's
upload as a one-time co-maintenance contribution with an NMU version.
According to the changelog the newer upstream release was already prepared by
So again, this does not seem to be an example of "the maintainer refuses to
package any newer upstream". This seems to be just an NMU, not related to
Lucas' proposal about orphaning packages.