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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1351767608.29093.621.ca...@s1499.it.kth.se
