Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # general >> Re: [vote] Incorrect definition of lazy consensus in by-laws?


Copy link to this message
-
RE: [vote] Incorrect definition of lazy consensus in by-laws?
I think current procedure is good in Hadoop community to have minimum some +1's approvals in votings.
In Hadoop we follow R-T-C policy. From the foundation voting policy "Lazy consensus cannot be applied to code changes when the review-then-commit policy is in effect."
In Hadoop we are following this with little modifications "Lazy consensus of active committers, but with a minimum of one +1. "

But for new committer addition
"◦New Committer
When a new committer is proposed for the project
Lazy consensus of active PMC members"

So, here it may be contradicting the policy from Foundations definition. So, is it make sense to change that as "Lazy consensus of active PMC members but with 3 min +1 binding votes" ?
Here lazy consensus does not allow vetos and other condition expects min 3 '+1'. With this we can change the definition of Lazy Consensus in hadoop bylaws also same as foundation.
Sorry if I misunderstand some bylaws here. Please clarify to me.

Regards,
Uma
________________________________________
From: Noah Slater [[EMAIL PROTECTED]]
Sent: Friday, March 22, 2013 3:23 AM
To: [EMAIL PROTECTED]
Cc: Matt Foley
Subject: Re: [vote] Incorrect definition of lazy consensus in by-laws?

Swapping out "lazy consensus" for "consensus approval" seems to make sense.
But might it also be a good idea to specify how lazy consensus (as defined
in the ASF glossary, and as used throughout the foundation) can be used? I
presume Hadoop makes heavy use of lazy consensus. (This is a drive-by
posting on my behalf. I am otherwise not involved in your community.)
Examples would be a C-T-R policy, changes to the wiki, or any time someone
says "I plan to do X. If nobody objects in 72 hours, I will assume lazy
consensus."
On 21 March 2013 21:44, Aaron T. Myers <[EMAIL PROTECTED]> wrote:

> On Thu, Mar 21, 2013 at 12:18 PM, Robert Evans <[EMAIL PROTECTED]>
> wrote:
>
> > So to make this official I propose that we change the term "lazy
> > consensus" to "consensus approval" (aka s/lazy\s+consensus/consensus
> > approval/gi) in the bylaws so that it matches the terms used in the
> apache
> > foundation glossary.
> >
> > As per the by-laws this would take a "lazy majority" of active PMC
> members.
> >
> > Lazy Majority - A lazy majority vote requires 3 binding +1 votes and more
> > binding +1 votes than -1 votes.
> >
> >
> > Voting lasts 7 days, so it closes Thursday March 28th.
> >
>
> All sounds good to me, though I recommend you start a new [VOTE] thread so
> that folks realize that this thread has moved on from a discussion into an
> actual vote.
>
> --
> Aaron T. Myers
> Software Engineer, Cloudera
>

--
NS
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB