Re: GR: Orphaning another maintainer's packages
I don't think we need GRs to decide development procedures like this. -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6hbvkch7zjgzydqnvy43eys619gt9-e562juytajht...@mail.gmail.com
GR: Orphaning another maintainer's packages
Hi, while Lucas did his best to summarize the outcome from the last thread in a fairly constructive and consensual way, it turned out that too many people have too many opinions here on this matter. Having clearly in mind, that seeking consensus by way of a General Resolution for something ending up in Developer's Reference is like breaking a fly on the wheel, I believe this is the only way out of this impasse which yields to any working solution. As it looks to me, I observe: *) we have consensus that we are in need of such a rule set - which ever it may be *) we have three orthogonally different ideas: a) Bart's approach which was reformulated and proposed by Lucas in this thread [1] b) Mine - which was based on timeout arithmetics [2] c) Michael Gilbert's approach to merge the concept of NMUs with orphaning packages [3] Among these, alternative a) seems to attract most responses and opinions, most agreeing in spirit and procedures, but disagreeing about one detail ... *) ... within approach a) the most heat seems to deal with the necessity to seek ACKs/NACKs for an intent to orphan of a package by peers. If we would exclude the paragraph about DD seconding we are also roughly there, what Sune proposed in [4] and - in spirit - seems to be most attractive alternative to the original proposal. Therefore, I consider seeking resolution by means of a GR proposing Lucas alternative [with minor formulation tweaks and after discussion of the actual text] (that is, proposal a).) without the DD seconding part, because I do not like that much, personally. Moreover, if we decided to go this way, I endorse anyone liking the DD seconding to formulate an amendment adding this or another requirement to the resolution statement. What do you think? Does this sound like a fair compromise everyone could live with? [1] https://lists.debian.org/debian-devel/2012/10/msg00469.html [2] https://lists.debian.org/debian-devel/2012/09/msg00654.html [3] https://lists.debian.org/debian-devel/2012/10/msg00524.html [4] https://lists.debian.org/debian-devel/2012/10/msg00473.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 01:46:41PM +0200, Arno Töll wrote: What do you think? Does this sound like a fair compromise everyone could live with? Voting is almost never a way to reach consensus. Rather, it acknowledges that consensus has not been reached and side-steps further constructive attempts to reach it. I'm positive we can have consensus on this issue. In fact, I think we're pretty close to it. I'm traveling, so can't elaborate in more detail on this matter. But I urge you to reconsider proposing a GR. It is a heavy weight tool, that should be used as a last resort. I don't think we're nowhere near the need of it in this specific case. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 01:54:19PM +0200, Stefano Zacchiroli wrote: I don't think we're nowhere near the need of it in this specific case. s/don't// obviously :) -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » -- 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/20121026115516.ga10...@upsilon.cc
Re: GR: Orphaning another maintainer's packages
On 26.10.2012 13:54, Stefano Zacchiroli wrote: But I urge you to reconsider proposing a GR. It is a heavy weight tool, that should be used as a last resort. So far I agree. I didn't say I'll propose on - JFTR. I said I'll consider that and asked for opinions - like yours :) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: GR: Orphaning another maintainer's packages
On Fri, Oct 26, 2012 at 7:46 AM, Arno Töll wrote: *) we have consensus that we are in need of such a rule set - which ever it may be *) we have three orthogonally different ideas: a) Bart's approach which was reformulated and proposed by Lucas in this thread [1] b) Mine - which was based on timeout arithmetics [2] c) Michael Gilbert's approach to merge the concept of NMUs with orphaning packages [3] My proposal has nothing to say about orphaning itself, and explicitly leaves it untouched. Mine can be considered a more flexible co-maintainer process that importantly can be started far before orphaning becomes a package's last resort. It also seeks to handle the hard cases whereas a) and b) explicitly state that they're avoiding that problem altogether. Anyway, I and seemingly many others don't like the bureaucracy of a) and b), especially since there is already a common-law 4*7*24*3600 rule in existence that would probably get applied more often if it were actual devref-law. Finally, if a) and b) aren't meant to do something about the original issue, the hard maintainership questions, then what's the point? Why do we need more bureaucracy when we already have a common-law solution? Best wishes, Mike -- 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/CANTw=MNx1O0d0uQ9pLNgA=4z7ljslbssoqgcsolxjsg_4sr...@mail.gmail.com
