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 -- 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/20121101084855.gb26...@master.debian.org
