accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [VOTE] Accumulo Bylaws, vote 2
Date Tue, 01 Apr 2014 21:45:33 GMT
Then my interpretation on the voting period doesn't make sense, so never
mind it. Thanks for clarifying!


On Tue, Apr 1, 2014 at 5:20 PM, Billie Rinaldi <billie.rinaldi@gmail.com>wrote:

> On Tue, Apr 1, 2014 at 2:15 PM, Bill Havanki <bhavanki@clouderagovt.com>wrote:
>
>> First, +1 vote
>>
>> As part of getting us a (literally) passable first set of bylaws as a
>> foundation, at one point I "refactored" the commit and review details out
>> to an as-yet-to-be-written standard. So, what is in the bylaws should be
>> interpreted as permissive.
>>
>> My interpretations: A "code change" can certainly be a commit - "a change
>> made to a codebase of a project". Lazy approval is based on that commit.
>> The minimum voting period (here and for release plan) applies to both vote
>> phases separately, so *n* days for lazy approval, *n* days for consensus
>> if needed. (I imagine lazy approval has some period since getting a veto
>> one month later shouldn't be possible, for example; but if that doesn't
>> make sense, never mind. :) )
>>
>
> A change can be vetoed until the code is released. :)
>
>
>>
>> I have all sorts of ideas about the commit and review details, and I bet
>> others do too, which is why I like having that split off from getting some
>> version 1 bylaws in place. As the policies evolve, we still have the option
>> to modify the bylaws as needed.
>>
>> Bill
>>
>>
>>
>>
>>
>>
>> On Tue, Apr 1, 2014 at 4:40 PM, John Vines <vines@apache.org> wrote:
>>
>>> The only two places we have a lazy falling back to another type of vote
>>> is
>>> code change and release plan. For release plan, I interpret the minimum
>>> length to apply to either type of vote. However, you're stating that this
>>> is not the case for a code change. So there is ambiguity about minimum
>>> length applying to lazy approvals that needs to be cleared up here.
>>>
>>>
>>> On Tue, Apr 1, 2014 at 4:34 PM, Billie Rinaldi <billie.rinaldi@gmail.com
>>> >wrote:
>>>
>>> > The only time there is more than one type of approval (not vote)
>>> required
>>> > is when the first one is lazy consensus, which doesn't actually
>>> require a
>>> > vote.  Maybe we just need some elaboration on how to CTR which is
>>> > referenced from this doc ("Please refer to the Accumulo commit and
>>> review
>>> > standard for details")?
>>> >
>>> >
>>> > On Tue, Apr 1, 2014 at 1:17 PM, John Vines <vines@apache.org> wrote:
>>> >
>>> >> If that is the case, then I think we should provide distinction about
>>> the
>>> >> time lengths between the various types of votes, for the cases where
>>> there
>>> >> are multiple possible votes involved.
>>> >>
>>> >>
>>> >> On Tue, Apr 1, 2014 at 4:08 PM, Billie Rinaldi <
>>> billie.rinaldi@gmail.com>wrote:
>>> >>
>>> >>> On Tue, Apr 1, 2014 at 12:46 PM, John Vines <vines@apache.org>
>>> wrote:
>>> >>>
>>> >>>> The way I'm reading actions, all code changes must be presented
at
>>> least
>>> >>>> one day before they can be committed. Is that intended this
way?
>>> >>>>
>>> >>>
>>> >>> I wasn't reading it that way.  Code change is lazy approval, and
"An
>>> >>> action with lazy approval is implicitly allowed unless a -1 vote
is
>>> >>> received."  Not requiring a vote supersedes the minimum vote length.
>>>  In
>>> >>> the event of falling back to consensus approval for code change,
the
>>> >>> minimum vote length is 1 day.
>>> >>>
>>> >>>
>>> >>>
>>> >>>>
>>> >>>>
>>> >>>> On Tue, Apr 1, 2014 at 3:10 PM, Billie Rinaldi <billie@apache.org>
>>> >>>> wrote:
>>> >>>>
>>> >>>> > Hey everyone!  We only have 3 more days to vote on Accumulo's
>>> bylaws
>>> >>>> ...
>>> >>>> >
>>> >>>> >
>>> >>>> > On Fri, Mar 28, 2014 at 6:55 AM, Bill Havanki <
>>> >>>> bhavanki@clouderagovt.com
>>> >>>> > >wrote:
>>> >>>> >
>>> >>>> > > Please vote on the proposed bylaws, as available at
>>> >>>> > >
>>> >>>> > > *
>>> >>>> > >
>>> >>>> >
>>> >>>>
>>> https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup
>>> >>>> > > <
>>> >>>> > >
>>> >>>> >
>>> >>>>
>>> https://svn.apache.org/viewvc/accumulo/site/trunk/content/bylaws.mdtext?revision=1582476&view=markup
>>> >>>> > > >*
>>> >>>> > >
>>> >>>> > > A nicer-to-read version is available at
>>> >>>> > >
>>> >>>> > > http://accumulo.apache.org/bylaws.html
>>> >>>> > >
>>> >>>> > > This vote will be open for 7 days, until 4 April 2014
14:00 UTC.
>>> >>>> > >
>>> >>>> > > Upon successful completion of this vote, the first
line of the
>>> >>>> document
>>> >>>> > > body
>>> >>>> > > will be replaced with "This is version 1 of the bylaws,"
and the
>>> >>>> > statement
>>> >>>> > > defining the document as a draft will be stricken.
>>> Additionally, a
>>> >>>> link
>>> >>>> > to
>>> >>>> > > the document will be added to the navigation menu.
>>> >>>> > >
>>> >>>> > > This vote requires majority approval to pass: at least
3 +1
>>> votes
>>> >>>> and
>>> >>>> > more
>>> >>>> > > +1
>>> >>>> > > than -1's.
>>> >>>> > >
>>> >>>> > > [ ] +1 - "I approve of these proposed bylaws and accept
them
>>> for the
>>> >>>> > > Apache Accumulo
>>> >>>> > > project."
>>> >>>> > > [ ] +0 - "I neither approve nor disapprove of these
proposed
>>> >>>> bylaws, but
>>> >>>> > > accept them for the Apache Accumulo project."
>>> >>>> > > [ ] -1 - "I do not approve of these proposed bylaws
and do not
>>> >>>> accept
>>> >>>> > them
>>> >>>> > > for
>>> >>>> > > the Apache Accumulo project because..."
>>> >>>> > >
>>> >>>> > > Thank you.
>>> >>>> > >
>>> >>>> > > --
>>> >>>> > > // Bill Havanki
>>> >>>> > > // Solutions Architect, Cloudera Govt Solutions
>>> >>>> > > // 443.686.9283
>>> >>>> > >
>>> >>>> >
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>>
>> --
>> // Bill Havanki
>> // Solutions Architect, Cloudera Govt Solutions
>> // 443.686.9283
>>
>
>


-- 
// Bill Havanki
// Solutions Architect, Cloudera Govt Solutions
// 443.686.9283

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