Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAJNb-9pb5JfDgxWP-O0QkrDNYsGE+7KvXoX5DJ+rQc3KPModMQ@mail.gmail.com>
References: 
 <CAJNb-9pRGw11-Ajo2Tu5COrdLsVEZUEDy9q5qPAMby_zx4WLsQ@mail.gmail.com>
	<CABvT1DHd0fGRJf-Ui75CQmOVuUVSC6hVAvXsePGhUwSVT3yeTA@mail.gmail.com>
	<CAJNb-9rhpRHvzYzGLabshA=RZ85LYf_9VXdNvX2QUi25KnZEyg@mail.gmail.com>
	<CAJNb-9pb5JfDgxWP-O0QkrDNYsGE+7KvXoX5DJ+rQc3KPModMQ@mail.gmail.com>
Date: Wed, 8 May 2013 11:36:40 +0100
Message-ID: 
 <CABvT1DHz60JBFT8JJ+VyRweV74T_VDbnFGS9hTyn0j_4T-pnXw@mail.gmail.com>
Subject: Re: [DISCUSS] dont't abuse of "lazy concensus" on mail tagged
 [DISCUSS]
From: Robert Newson <rnewson@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

" 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 <bchesneau@gmail.com> wrote:
> On Wed, May 8, 2013 at 6:19 AM, Benoit Chesneau <bchesneau@gmail.com> wrote:
>> On Tue, May 7, 2013 at 9:23 PM, Robert Newson <rnewson@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