Hi Zack, On Tue, Oct 23, 2012 at 11:19:34PM +0200, Stefano Zacchiroli wrote: > On Tue, Oct 23, 2012 at 05:19:37PM +0000, Sune Vuorela wrote: > > 1) report a bug 'should this package be orphaned?' against the package > > with a more or less defalut templated text and a serious severity > > 2) sleep 4*7*24*3600 > > 3) if bug silent, orphan it (and maybe adopt it) > According to the interpretation I suggested in [1], this is actually the > degenerate case of the proposal that is being discusses. If no-one ACKs > --- which IMHO is what would happen by default anyhow in quite a number > of cases --- and if the interested person chooses to sleep 4*7*24*3600, > your point (3) will be the natural conclusion. > [1]: https://lists.debian.org/debian-devel/2012/10/msg00471.html > Otherwise stated, the proposal is *exactly* what you're proposing, plus > some consensus-based best practice to deal with the missing "else" > branch of your point (3). > I'm convinced that "else" branch will be quite uncommon (unless > mandated, see below), and that ACKs/NACKs are just a different way of > putting what already happens when we discuss on a mailing list the > salvation of a package. > But you could either have the unsupervised "if" branch, or what Steve > suggests in https://lists.debian.org/debian-devel/2012/10/msg00475.html > i.e. maintainers explicitly looking for ACKs to support their action as > a requirement to complete the procedure. It has its merits (e.g. a > surefire extra review layer). But if you consider ACKs as "votes", as > Scott put it, and you see that as bad, you won't accept this. > So, can people comment on Steve's proposal? > Similarly, Steve: can you comment on the criticism of "voting" on > packages, why don't you see it as a problem? "Voting" implies that the majority rules. I am certainly not in favor of any sort of voting mechanism where we tally those in favor and those against orphaning the package. The standard I expect to see applied here is *consensus*, not voting. A lone voice in the wilderness, with no one saying either yay or nay, is not a consensus. 20 DDs saying the package should be orphaned, and the maintainer saying it shouldn't (or some other DD saying it shouldn't), is not a consensus. We should not need a heavyweight process here at all. It seems that some of the participants in this discussion are unaware that some of us are subscribed to debian-qa specifically *for* dealing with questions of unmaintained packages (MIA, salvaging, or coordination of QA uploads). The only real requirements for such a process are: - Make an appropriate effort to notify the maintainer of your concern - Make the rest of Debian aware of your plans in the designated public forum - Get some (small) number of your peers to agree via public review that this is the correct course of action for the package in question - Wait a reasonable amount of time for objections - If consensus is not reached, refer to the TC And if my frustration is showing through in this thread, it's because *I am not proposing a new process*. This was the process that was used for *years* via debian-qa. But, evidently because this process was never adequately codified in the developer's reference, here we are now having a long, drawn-out discussion not only about reinventing the wheel but also about what we should define a wheel to be, and entertaining solutions in search of a problem from people who have never used that existing and proven process. It is not going to be hard to get the necessary handful of acks when following an appropriate process, nor is it hard to wait a fixed period to give time for any nacks to arrive before taking action on a package to be salvaged. A package salvage is NOT an urgent matter, ever. Urgent matters should be dealt with by NMU. Salvaging is for longer-term questions of maintainership, and where maintainership is concerned we should be duly respectful of the existing maintainer's committment to Debian instead of enacting a buggy process that allows for a maintainer to come back from a vacation/hospital stay/computer outage to find her package has been rewritten without so much as a thank you. If you really intend to commit to maintaining the package for the foreseeable future, you can bloody well sit on your hands for a month and wait for the maintainer to react first. So in sum, I'm broadly in favor of Lucas's patch, except: - A single nack is evidence of a lack of consensus. If consensus can't be achieved, it should be referred to the TC instead of making a political mess of things for the rest of the project. - There does need to be a mandatory minimum waiting period. This process is going to be seen as "blessed" via the devref; we should not be blessing a process with an obvious bug that permits abuse by a DD and three of her friends pulling off a hostile takeover of a package before anybody has a chance to say no. Even though such an act *can* be appealed to the TC, we shouldn't put ourselves in the situation that it has to be. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature