" merge of bigcouch should be done on lazy consensus, it should be a full vote."
The merge of bigcouch in my [VOTE] thread is to get the work out of github and onto a branch in our couchdb repository for further work. Had I been asking to merge directly to master, or to release it, then I absolutely agree that lazy consensus is not appropriate. I don't expect anyone to veto the bringing in of this work into a non-release branch inside the ASF official repository and 3 days seems long enough for folks to object to that very modest step. Getting that work into our repo is the first step of releasing a clustered couchdb, not the last step (and not by a long way). I agree that 72 hours is not always enough, and that lazy consensus is not always the right thing as long as we can agree that obstructionism can also be a problem. As for the notion that we can ignore vetos (-1's) in lazy consensus, all I can say is that it's news to me, but happy to corrected on that. B. On 8 May 2013 05:27, Benoit Chesneau <bchesn...@gmail.com> wrote: > On Wed, May 8, 2013 at 6:19 AM, Benoit Chesneau <bchesn...@gmail.com> wrote: >> On Tue, May 7, 2013 at 9:23 PM, Robert Newson <rnew...@apache.org> wrote: >>> I'm not sure I fully agree. All the lazy consensus's of late have had >>> a 72 hour window on them which is the same duration we use for couchdb >>> releases. >> >> This si another topic. Also votes on release need a majority of >> approval, and are done on something that *should* have been tested >> before the vote. But this is another topic. >> >> >>> >>> However, we can discuss what the minimum lazy consensus period can be >>> based on what the minimum time that community members feel they can >>> respond. >>> >>> I don't mean this as horribly as it will sound, but, to a degree, if >>> someone can't take the time, in 3 days, to reply with '-1' to a >>> thread, perhaps that's a problem too? >> >> Not really. People are not expected to be on their computer all the >> time. Some are disconnecting when they go in vacations for real. Some >> can't connect at all to a public network because of their customer or >> else for some time. The fact is that you can't expect that people >> distributed in the world and work synchronously with you most of the >> time. Dropping a mail on the mailing-;list on big topics an expecting >> an answer in 72h is not really fear. Until you expect that people >> works in sync on that topic. >> >> The whole point of lazy >>> consensus is to move forward quickly. We don't always need to wait for >>> a large number of +1's to get work done. >> >> >> Lazy consensus is simply an announcement of 'silence gives assent.' When >> someone wants to determine the sense of the community this way," >> >> http://www.apache.org/foundation/voting.htm >> >> >> This is what I mean. And -1 can be properly ignored in lazy >> concenssus. Lazy consensus are not about looking for a consensus at >> all. A way to confirm an idea without any real discussion. A way to >> make sure you're not the only one to think that way. I do think that >> lazy consensus shouldn't be use for important topics that engage all >> the community. >> >> And I do think that asking for a short time in recent topics was used >> as a convenience. They didn't require so much urgency. They could have >> been handled in the week. Lot of projects outside couchdb do this way. >> Even in companies. >> >>> >>> Finally, I'll agree that lazy consensus can be used inappropriately, I >>> just don't think I agree that it's happened yet. >> >> Some were borderline imo. >> >> To take an example I don't think that the merge of bigcouch should be >> done on lazy consensus, it should be a full vote. Because ii is more >> than a technical changes. It can also be considered as a switch in the >> philosophy of the project so giving more time to people to think about >> it would be interesting. Giving the possibility to veto it or to >> express their opinion too. It may not change the result at all and >> probably won't , but that not a reason. >> >> - benoit > > As a final note I would like to quote the apache page above again: > > Reasons for Votes > > People tend to avoid conflict and thrash around looking for > something to substitute somebody in charge, a rule, a process, > stagnation. None of these tend to be very good substitutes for doing > the hard work of resolving the conflict. > > > - benoit
