hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [vote] Incorrect definition of lazy consensus in by-laws?
Date Sat, 23 Mar 2013 17:17:54 GMT
It doesn't make sense to say "lazy consensus but [with extra conditions on
voting]" because lazy consensus is very specifically defined as consensus
through silence, i.e. something that requires no voting.

Some things Hadoop is probably already using lazy consensus for: wiki
changes, any time someone says "I'm gonna do X, and I'll give it 72 hours
for someone to object" but does not call a vote.

If there are instances where you are voting on things, then you are not
using lazy consensus. But that is fine of course! I am just suggesting we
use the correct terminology. So if committers are voted in with 3 +1 votes
and no -1 vote, then that is a consensus approval vote. So I think we
should just call it a consensus approval vote, and not mix up terminology.





On 22 March 2013 05:45, Uma Maheswara Rao G <maheswara@huawei.com> wrote:

> 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 [nslater@apache.org]
> Sent: Friday, March 22, 2013 3:23 AM
> To: general@hadoop.apache.org
> 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 <atm@cloudera.com> wrote:
>
> > On Thu, Mar 21, 2013 at 12:18 PM, Robert Evans <evans@yahoo-inc.com>
> > 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
>



-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message