accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [DISCUSS] Define CTR in Bylaws
Date Fri, 04 Apr 2014 18:10:18 GMT
On Fri, Apr 4, 2014 at 1:10 PM, John Vines <vines@apache.org> wrote:

> Based on the actions table, consensus
>

oh yeah, its very clear there.  thanks


>
>
> On Fri, Apr 4, 2014 at 1:06 PM, Keith Turner <keith@deenlo.com> wrote:
>
> > On Fri, Apr 4, 2014 at 12:12 PM, Billie Rinaldi <
> billie.rinaldi@gmail.com
> > >wrote:
> >
> > > This is a proposal to adequately describe our Commit-Then-Review
> process
> > in
> > > the bylaws.  I have made an initial suggestion below.  If we can agree
> on
> > > how to make this clarification, presumably this change would be made
> > > instead of removing the Code Change action from the bylaws (or would
> > > involve adding Code Change back in, if it happens that that change has
> > > already taken place).
> > >
> > >
> > > Index: bylaws.mdtext
> > > ==============================
> > > =====================================
> > > --- bylaws.mdtext    (revision 1584734)
> > > +++ bylaws.mdtext    (working copy)
> > > @@ -125,8 +125,15 @@
> > >
> > >  All participants in the Accumulo project are encouraged to vote. For
> > > technical decisions, only the votes of active committers are binding.
> > > Non-binding votes are still useful for those with binding votes to
> > > understand the perception of an action across the wider Accumulo
> > community.
> > > For PMC decisions, only the votes of active PMC members are binding.
> > >
> > > -Voting can also be applied to changes to the Accumulo codebase. Please
> > > refer to the Accumulo commit and review standard for details.
> > > +See the [voting page](
> http://accumulo.apache.org/governance/voting.html
> > )
> > > for more details on the mechanics of voting.
> > >
> > > +<a name="CTR"></a>
> > > +## Commit Then Review (CTR)
> > > +
> > > +Voting can also be applied to changes to the Accumulo codebase. Under
> > the
> > > Commit Then Review policy, committers can make changes to the codebase
> > > without seeking approval beforehand, and the changes are assumed to be
> > > approved unless an objection is raised. Only if an objection is raised
> > must
> > > a vote must take place on the code change.
> > > +
> > > +For some code changes, committers may wish to get feedback from the
> > > community before making the change. It is acceptable for a committer to
> > > seek approval before making a change if they so desire.
> > > +
> > >  ## Approvals
> > >
> > >  These are the types of approvals that can be sought. Different actions
> > > require different types of approvals.
> > > @@ -139,7 +146,7 @@
> > >  <tr><td>Majority Approval</td>
> > >      <td>A majority approval vote passes with 3 binding +1 votes and
> more
> > > binding +1 votes than -1 votes.</td>
> > >  <tr><td>Lazy Approval (or Lazy Consensus)</td>
> > > -    <td>An action with lazy approval is implicitly allowed unless a
-1
> > > vote is received, at which time, depending on the type of action,
> either
> > > majority approval or consensus approval must be obtained.</td>
> > > +    <td>An action with lazy approval is implicitly allowed unless a
-1
> > > vote is received, at which time, depending on the type of action,
> either
> > > majority approval or consensus approval must be obtained.  Lazy
> Approval
> > > can be either <em>stated</em> or <em>assumed</em>,
as detailed on the
> > [lazy
> > > consensus page](
> http://accumulo.apache.org/governance/lazyConsensus.html
> > )
> > > .</td>
> > >
> >
> > If there is a commit and then a -1, is consensus or majority needed to
> > avert a revert?
> >
> >
> > >  </table>
> > >
> > >  ## Vetoes
> > > @@ -152,6 +159,8 @@
> > >
> > >  This section describes the various actions which are undertaken within
> > the
> > > project, the corresponding approval required for that action and those
> > who
> > > have binding votes over the action. It also specifies the minimum
> length
> > of
> > > time that a vote must remain open, measured in days. In general, votes
> > > should not be called at times when it is known that interested members
> of
> > > the project will be unavailable.
> > >
> > > +For Code Change actions, a committer may choose to employ assumed or
> > > stated Lazy Approval under the [CTR](#CTR) policy. Assumed Lazy
> Approval
> > > has no minimum length of time before the change can be made.
> > > +
> > >  <table>
> > >  <tr><th>Action</th>
> > >      <th>Description</th>
> > >
> >
>

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