Re: [PROPOSAL v2] Orphaning another maintainer's packages

[Bart Martens <bartm@debian.org>]

On Wed, Oct 31, 2012 at 07:16:56PM -0400, Michael Gilbert wrote:
> On Wed, Oct 31, 2012 at 2:34 PM, Bart Martens wrote:
> > On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote:
> >> How to solve the following problem: Assume a package with wishlist bugs
> >> filed lagging behind upstream and the maintainer refuses to package any
> >> newer upstream, not even into experimental. And in general there is an
> >> interest (from several people) in having the new upstream versions
> >> packaged. Can this package become salvaged in some way by the ITS/ITO
> >> procedure?  I think this is a rather common case, a cautious maintainer
> >> and some more adventurous salvagers.
> >
> > Can you give a few examples, if this is "a rather common case" ?
> 

I asked examples from Svante Signell and got examples from Michael Gilbert.
Let's have a look :

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

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

> mlocate: http://bugs.debian.org/669368 (new upstream could have been
> pushed via nmu before the freeze, but it was prepared too late)

Same here, this does not seem to be an example of "the maintainer refuses to
package any newer upstream", and the prepared NMU seems to be just that, not
related to Lucas' proposal.  (Also, the prepared NMU seems still not ready, in
my opinion.)

> <many others I'm sure>

Do we have examples of the "rather common case" Svante Signell described that
are not yet solved ? Cases where we can evaluate Lucas' proposal with ?

I doubt that we can find (many) such examples, because when "the maintainer
refuses to package any newer upstream" then there is obviously a disagreement,
and the proposed ITO procedure was meant to deal with obvious cases, not with
disagreements/disputes.

> 
> It's not that common to encounter maintainer's with this kind of
> unproductive attitude, but when it does happen it seems to occur
> rather often in important packages.  Thus, we should really have a
> documented guideline for these cases.  The go ahead and fix it via nmu
> is one solution that has been quite effective so far and seemingly
> uncontroversial to the maintainers that had been getting in the way.

I think that Lucas' proposal is not meant to address cases where the maintainer
has an "unproductive attitude" or is "getting in the way", but rather meant for
the obvious cases, where a consensus to mark the package as orphaned is reached
easily.

My thoughts on this debate at this point, not related Michael Gilbert's message
I'm now replying to, is that I read many opinions and not many examples.  I
think that using examples of real packages in Debian could help to find common
situations and to agree on recommended approaches to be documented in the
dev-ref.  This debate would make more sense to me when it is brought closer to
reality, with real examples of packages in Debian.  Real examples we can
evaluate Lucas' proposal on.

But I shouldn't tell other people to give examples without doing it myself. :-)
So I hereby disclose my whitelist that I meant earlier:
http://qa.debian.org/~bartm/wnpp-rfs-mentors/wnpp-whitelist.txt
http://lists.debian.org/debian-devel/2012/10/msg00625.html
I would like to allow current practice to be continued regardless of what is
added in dev-ref.  I also welcome additions to dev-ref that invite more people
to help with getting more packages needing a new maintainer identified sooner,
so that these packages can be salvaged by interested new contributors.

Regards,

Bart Martens