Re: [PROPOSAL v2] Orphaning another maintainer's packages
On Thu, 2012-11-01 at 08:48 +0000, Bart Martens wrote:
> 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" ?
Good that somebody else than me gave the examples, so it is "not only
me". Comments and more examples below.
>
> 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.
I think the proposal should include also case like this, since one
solution would be to open up for team maintenance of package. This would
exclude problems in opinion between the maintainer and the bug submitter
about which packages to keep updated with upstream releases.
> > 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",
I think it is.
> 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.)
Well the submitted files was not an NMU, I would need a sponsor for
that. It was a wish that the maintainer would complete the packaging,
but that did not happen. The changelog entry was for installation at
debian-ports. If the maintainer had adopted the changes, the changelog
would have been written accordingly by him, of course.
The package is built and installed at debian-ports for GNU/Hurd where a
sponsor was available. FYI, this package is currently the only locate
package available on GNU/Hurd, therefore its importance.
> > <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 ?
Below are examples in past time:
emacs24: http://bugs.debian.org/647213
If the pre-releases had been packaged, emacs24 would be the default
version for Wheezy, not emacs23. Unfortunately the packaging of emacs24
was made too late to be in time for the freeze. This is another example
where more hands could have resolved the situation, read "team
maintenance" again.
logrotate: http://bugs.debian.org/613342
http://bugs.debian.org/633529
The new upstream was finally packaged after half a year delay, two
releases later. In this case the update could have been much quicker,
again with team maintenance or support from users/other maintainers to
the maintainer.
file: http://bugs.debian.org/612742
http://bugs.debian.org/619225
http://bugs.debian.org/cgi-bin/626340
The package uploaded was made four upstream releases later after seven
months. With help from other people the upgrade could have happened much
earlier.
> 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.
One example (not about upstream issues however):
x86info: http://bugs.debian.org/468696
This is an example of maintainer attitude. This is also a package
available at debian-ports.
Not that the above bugs are somewhat GNU/Hurd related, but at the time
of bug submissions Hurd was a potential release architecture for Wheezy.
History shows that it is not, but it will (hopefully) be in Wheezy+1.
> 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.
Maybe the definition should be widened.
Reply to: