Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAFAMeYKbOX0TSCq2hauuKqwRYytu0aLfQuWpcqQ_Patvtjg=6Q@mail.gmail.com>
References: 
 <CAFAMeY+R5ubsMLQr5K7gsU9_KjMFMRfDvOM-GSshMTQyOfpAtw@mail.gmail.com>
 <52FE5F1E.6050007@gmail.com>
 <CAFAMeY+JmyZwz4bsH8R-EoPnV2T8aVdibZcR16f1KkqT+QwQhQ@mail.gmail.com>
 <CAL5zq9Yq89sTm9hDtG95L_6cove5Ve_xu7xGwLLdp18oG28n6w@mail.gmail.com>
 <CAFu4t2i9_LAm1aWEfuG2-yi7iRuvpcHWLSGZHY=0+mg-Sksicw@mail.gmail.com>
 <CAD-fFUL7hF1WA8XZQLnmp7HtGZuGKRL098Wn_2yg7FpMv3_Kkg@mail.gmail.com>
 <CAFu4t2i34FS3_5AzgjUztQny3mze1FYCEkLykPuMAGLg+Uyb-w@mail.gmail.com>
 <CAFAMeYL6hDoBzG0G8pT5jDBwNsBRfLfQV3xaVXY7bwYKTXVTBQ@mail.gmail.com>
 <CAF1jEfDZ=DS0Yc5gWJf_9GtN756vyGOESdcjqQ3x6JRCVOfeng@mail.gmail.com>
 <CAFAMeYKh_Gd5ipFig3VaH+AuQSp3v5_n2p-WO+n_mUbUq3zS5w@mail.gmail.com>
 <CAF1jEfDsHU_tG94TNs-=Mss65geDp2yvxEmpGR1KzQ5Gsb-+9A@mail.gmail.com>
 <CAD-fFULYvdNqeK_axaO8se0R2ji9FdWSOhm_Xy6w24H5PD+t7A@mail.gmail.com>
 <CAF1jEfAXeP_02EhBUgFUZAGGvg2hkLuOG7rLqVvOkBHxAnYLFA@mail.gmail.com>
 <CAD-fFU+SX7aE0cMu5AC9xVR0OxwGeMm-V0O0rNpeQCnxuvAr0Q@mail.gmail.com>
 <CAFAMeYKbOX0TSCq2hauuKqwRYytu0aLfQuWpcqQ_Patvtjg=6Q@mail.gmail.com>
From: Bill Havanki <bhavanki@clouderagovt.com>
Date: Wed, 5 Mar 2014 12:14:07 -0500
Message-ID: 
 <CAD-fFUKSGROmirYVmxU=USDpJ6aTRLLA=Bi1UZ0BACt8QMyZqA@mail.gmail.com>
Subject: Re: [DISCUSS] Accumulo Bylaws
To: dev@accumulo.apache.org
Content-Type: multipart/alternative; boundary=001a113a359c33806304f3df272f

--001a113a359c33806304f3df272f
Content-Type: text/plain; charset=ISO-8859-1

Nice! I fixed the bulleted list of PMC responsibilities, which had lost its
bullets in translation.

We should clarify the right number of days for the new codebase and bylaw
modification actions. They were 6, but in my last edit I made them 7
because we were considering a minimum of a week. However, the days are
stated as business days. So, they should instead be 5, unless anyone thinks
more business days are required.


On Wed, Mar 5, 2014 at 11:50 AM, Mike Drob <madrob@cloudera.com> wrote:

> I'm taking the current state of the document and uploading it to our CMS,
> and adding a caveat about how it is only a draft, has not been accepted,
> etc. It is available at http://accumulo.apache.org/bylaws.html
>
> This version should be mostly static, unlike the google doc which is easy
> to edit anonymously. Please review the document for content, typos, and
> other changes. I expect a vote to come soon!
>
> Mike
>
>
> On Tue, Mar 4, 2014 at 10:36 AM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > OK, made a bunch of changes:
> >
> > - changed code change approval to lazy, then consensus
> > - changed new codebase approval to consensus
> > - changed bylaw change approval to majority - this is my preference, but
> > I'm willing to yield and go with consensus at this point, anybody can
> > change it
> > - removed vote actions for kicking out committers and PMC members
> > - removed definitions for 2/3 majority and "full consensus", which
> weren't
> > defined by ASF
> > - added this sentence for C == PMC, feel free to strengthen but I like
> the
> > teeny bit of wiggle room:
> >
> > It is the custom of the Accumulo project to also invite each committer to
> > become a member of the Accumulo PMC.
> >
> > - added paragraph on commit access being disabled for routine security,
> > using "may" so that we never are required to do it:
> >
> > An emeritus committer's commit access may be disabled as part of routine
> > security. Access shall not be removed without notifying the committer,
> and
> > access shall be maintained if the committer wishes to leave it active. A
> > committer's commit access shall be reactivated upon the committer's
> request
> > to the PMC.
> >
> > From my POV, these changes might handle all our open issues. I'd like to
> > ask everyone to take another look at the doc and see if we can get to a
> > vote and close this effort out.
> >
> > Bill H
> >
> >
> > On Thu, Feb 27, 2014 at 1:17 PM, Billie Rinaldi <
> billie.rinaldi@gmail.com
> > >wrote:
> >
> > > On Thu, Feb 27, 2014 at 6:36 AM, Bill Havanki <
> bhavanki@clouderagovt.com
> > > >wrote:
> > >
> > > > I implemented the vote renames in the doc.
> > > >
> > > > +1 on code change moving to consensus approval after a veto. That is
> > more
> > > > consistent.
> > > > +1 to consensus approval for a new codebase, vs. 2/3 majority.
> > > > -1 to consensus approval, 7-day period for bylaw changes. I don't
> like
> > > the
> > > > veto possibility. I'd prefer majority approval, 7-day period.
> > > >
> > >
> > > I'm neutral on this one.
> > >
> > >
> > > >
> > > > If we remove the emeritus vote actions, what mechanism is there for
> > > kicking
> > > > out committers or PMC members?
> > > >
> > >
> > > We wouldn't have one, but if necessary we could add it later with a
> bylaw
> > > change.  Inactive PMC members / committers would still have the ability
> > to
> > > resign voluntarily.
> > >
> > >
> > > >
> > > > Re extending votes: something like this?
> > > >
> > > > - A vote action can be extended beyond its minimum length by the vote
> > > > caller if its outcome has not been determined.
> > > > - When it becomes clear that a vote will not reach a definitive
> > outcome,
> > > > the vote caller can close the vote, failing the vote action.
> > > >
> > > >
> > > >
> > > >
> > > > On Wed, Feb 26, 2014 at 4:41 PM, Billie Rinaldi <
> > > billie.rinaldi@gmail.com
> > > > >wrote:
> > > >
> > > > > On Wed, Feb 26, 2014 at 10:15 AM, Mike Drob <madrob@cloudera.com>
> > > wrote:
> > > > >
> > > > > > Great input, Billie! I had expected that you would be able to
> > provide
> > > > > more
> > > > > > ASF references than I had been able to find on my own. Responses
> > > > inline.
> > > > > >
> > > > > > Mike
> > > > > >
> > > > > > On Wed, Feb 26, 2014 at 12:29 PM, Billie Rinaldi <
> > billie@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > I have some issues with the proposed bylaws.  The main one is
> > that
> > > it
> > > > > > > chooses arbitrary names for approval types that do not match
> > > Apache's
> > > > > > > definitions [1][2].  I believe we should stick with Apache's
> > > > > definitions.
> > > > > > > I also see no reason to change the general guidelines provided
> > for
> > > > > which
> > > > > > > types of approval are needed in various scenarios.
> > > > > > >
> > > > > > > I hadn't seen the voting page before, thanks! I did an
> > unscientific
> > > > > > sampling of other Apache projects and it looks like ZK, Hadoop,
> > Pig,
> > > > and
> > > > > > Hive all use very similar bylaws, including the approval types
> and
> > > > action
> > > > > > types. This didn't surprise me, and I understand that we should
> > still
> > > > > > follow ASF examples over Hadoop examples. However, I was
> interested
> > > to
> > > > > see
> > > > > > Ant have similar bylaws as well. Then there is another group,
> > > including
> > > > > > HTTPD, HttpComponents, and Struts, that have very different
> looking
> > > > > bylaws.
> > > > > > Most groups with bylaws look like one of these two templates.
> > > > > >
> > > > > > I have no issue with dropping the "consensus" approval type to
> line
> > > up
> > > > > more
> > > > > > with ASF definitions. What do you propose the new threshold for
> > > > revoking
> > > > > > committer/PMC be? I also have no issue with dropping the "2/3
> > > majority"
> > > > > > (although Hadoop has an interesting spin on it; still lazy, but
> > twice
> > > > as
> > > > > > many +1 as -1) - what would be the new threshold for modifying
> > bylaws
> > > > and
> > > > > > accepting an existing code base. The code base situation came up
> > > > recently
> > > > > > with raccumulo and that was never properly resolved, I think, so
> > this
> > > > is
> > > > > a
> > > > > > good time to think about that.
> > > > > >
> > > > > > +1 on renaming to Consensus Approval and Majority Approval as per
> > the
> > > > ASF
> > > > > > glossary.
> > > > > > -0 on renaming Lazy Approval to Lazy Consensus. The glossary
> > > definition
> > > > > > calls them out as equivalent and like the parallelism from "X
> > > Approval"
> > > > > > naming. I think it is easier to remember.
> > > > > >
> > > > >
> > > > > I agree Lazy Approval is fine.  I wouldn't mind an extra sentence
> in
> > > the
> > > > > text saying that Lazy Approval is sometimes also called Lazy
> > Consensus
> > > > (so
> > > > > that it's clear that any approval mechanism starting with "Lazy"
> > means
> > > > the
> > > > > same thing).
> > > > >
> > > > > Regarding what types of approval are needed for what actions:
> > > > > - In ASF guidelines, code changes are vetoable (that is, everyone
> has
> > > to
> > > > > agree).  Thus I suggest making the approval Lazy Approval, falling
> > back
> > > > to
> > > > > Consensus Approval if a -1 is received.  (The current doc says it
> > falls
> > > > > back to Majority Approval.)
> > > > > - Majority approval is fine for release plan and product release.
> > > > > - Consensus approval is fine for new committers and PMC members.
> > > > > - The remaining actions are new codebase, modifying bylaws, and
> > > emeritus
> > > > > issues.  How about Consensus for new codebase and modifying bylaws
> > > > (perhaps
> > > > > with a 7-day minumum vote instead of 3-day), and drop the emeritus
> > > > issues?
> > > > >
> > > > > Do we want to add explicitly that any unfinished vote can be
> extended
> > > if
> > > > no
> > > > > -1s have been received?
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > > Another major departure in the proposed bylaws is that it gives
> > > > > > committers
> > > > > > > binding votes in some situations, while typically only PMC
> > members
> > > > have
> > > > > > > binding votes.  Since our policy is for all PMC members to be
> > > > > committers,
> > > > > > > we don't need to alter the standard responsibilities of
> > committers.
> > > > > > >
> > > > > > > I had been under the impression that committers should have
> > binding
> > > > say
> > > > > > on
> > > > > > code change but no procedural votes. Turns out that is backwards,
> > > > > according
> > > > > > to the ASF voting page. I think this document can be written in
> > such
> > > a
> > > > > way
> > > > > > to describe C and PMC roles as separate sets of responsibilities
> > > > without
> > > > > > conflicting with our current notion that C == PMC. I don't know
> if
> > we
> > > > > will
> > > > > > always have that be the case, but I can imagine a case where an
> > > > > individual
> > > > > > might accept the C invitation but not the PMC one.
> > > > > >
> > > > > > Also, the described responsibilities of committers and PMC
> members
> > > are
> > > > > > > misleading in that they leave out (or fail to clarify) some of
> > the
> > > > most
> > > > > > > important responsibilities of those roles.
> > > > > > >
> > > > > >
> > > > > > Just to make sure I understand: committers are stewards of the
> code
> > > and
> > > > > PMC
> > > > > > are stewards of the project?
> > > > > >
> > > > >
> > > > > The main responsibilities I want to call out are the following.
> > > > >
> > > > > Committers: Under the terms of the Contributor License Agreement
> that
> > > all
> > > > > committers must sign, a committer's primary responsibility is to
> > ensure
> > > > > that all code committed to Apache Accumulo is licensed
> appropriately
> > > and
> > > > > meets those criteria set forth in the CLA (including both original
> > > works
> > > > > and patches committed on behalf of other contributors).
> > > > >
> > > > > PMC members: The function of the PMC is to vote on
> community-related
> > > > > decisions, such as on new PMC members, committers and on releases.
> >  In
> > > > > particular, PMC members must understand both our project's criteria
> > and
> > > > ASF
> > > > > criteria for voting on a release (
> > > http://www.apache.org/dev/release.html
> > > > ,
> > > > > http://www.apache.org/dev/release.html#what,
> > > > >
> > http://www.apache.org/dev/release.html#what-must-every-release-contain
> > > ,
> > > > > http://www.apache.org/dev/release.html#approving-a-release).
> > > > >
> > > > > The following two paragraphs may also be useful (copied from
> > > > > http://apache.org/foundation/how-it-works.html#pmc):
> > > > >
> > > > > The role of the PMC from a Foundation perspective is oversight. The
> > > main
> > > > > role of the PMC is not code and not coding - but to ensure that all
> > > legal
> > > > > issues are addressed, that procedure is followed, and that each and
> > > every
> > > > > release is the product of the community as a whole. That is key to
> > our
> > > > > litigation protection mechanisms.
> > > > >
> > > > > Secondly the role of the PMC is to further the long term
> development
> > > and
> > > > > health of the community as a whole, and to ensure that balanced and
> > > wide
> > > > > scale peer review and collaboration does happen. Within the ASF we
> > > worry
> > > > > about any community which centers around a few individuals who are
> > > > working
> > > > > virtually uncontested. We believe that this is detrimental to
> > quality,
> > > > > stability, and robustness of both code and long term social
> > structures.
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > > I don't have any particular feeling on whether we should
> > introduce
> > > > the
> > > > > > > concept of emeritus committers or not.  It seems the major
> reason
> > > for
> > > > > > > wanting to do so is to keep 2/3 majority votes managable, but I
> > am
> > > > not
> > > > > > > actually sure we need to introduce the concept of a 2/3
> majority
> > > > vote.
> > > > > >  We
> > > > > > > could just use a standard veto-able vote (Apache Consensus
> > > Approval),
> > > > > > > perhaps with a longer time frame to ensure that everyone has a
> > > chance
> > > > > to
> > > > > > > weigh in.
> > > > > > >
> > > > > >
> > > > > > If we drop "consensus" and "2/3 majority" as defined in the
> > document
> > > > then
> > > > > > we should also drop emeritus. I agree with your interpretation of
> > > > intent.
> > > > > >
> > > > > > >
> > > > > > > [1]: https://www.apache.org/foundation/voting.html
> > > > > > > [2]: https://www.apache.org/foundation/glossary.html
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Feb 18, 2014 at 6:49 AM, Mike Drob <
> madrob@cloudera.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Thanks for putting it in a Google Doc, Arshak!
> > > > > > > >
> > > > > > > > What issues do y'all see with this document in it's current
> > > state?
> > > > > > > > Personally, I think it looks fine and would be willing to
> > start a
> > > > > vote
> > > > > > on
> > > > > > > > it, but I get the impression that east coast weather has
> > > prevented
> > > > > some
> > > > > > > > folk from looking at it, so maybe another couple of days is
> > fine.
> > > > > > > >
> > > > > > > > Mike
> > > > > > > >
> > > > > > > >
> > > > > > > > On Sun, Feb 16, 2014 at 7:18 AM, Arshak Navruzyan <
> > > > arshakn@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Oops, yes of course!  It's editable.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Sat, Feb 15, 2014 at 7:01 PM, Bill Havanki <
> > > > > > > bhavanki@clouderagovt.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Thanks Arshak! Can you either allow editing or
> commenting?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Feb 14, 2014 at 6:10 PM, Arshak Navruzyan <
> > > > > > arshakn@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Say no more ...
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://docs.google.com/document/d/1uR8vhIQcKGA6IEtbbF5D7UL_e6WGtfXMUQHp8Fwvg_E/edit?usp=sharing
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Feb 14, 2014 at 1:54 PM, Christopher <
> > > > > > ctubbsii@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Perhaps some ambitious volunteer could start a
> > > > collaborative
> > > > > > > draft
> > > > > > > > of
> > > > > > > > > > > > Accumulo's bylaws in Google Docs or something, using
> ZK
> > > as
> > > > a
> > > > > > > > starting
> > > > > > > > > > > > point. After it stabilizes a bit, we could push it to
> > the
> > > > > > project
> > > > > > > > > > > > webpage as a draft and vote on it?
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Christopher L Tubbs II
> > > > > > > > > > > > http://gravatar.com/ctubbsii
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Feb 14, 2014 at 2:11 PM, Mike Drob <
> > > > > > madrob@cloudera.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > > I didn't get that impression from reading their
> > > document.
> > > > > > > While C
> > > > > > > > > and
> > > > > > > > > > > PMC
> > > > > > > > > > > > > are two distinct roles, there is nothing stating
> that
> > > > there
> > > > > > > > cannot
> > > > > > > > > be
> > > > > > > > > > > > > overlap, and the fact that there is 100% overlap is
> > > > > entirely
> > > > > > > > > > > orthogonal.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Feb 14, 2014 at 10:23 AM, Josh Elser <
> > > > > > > > josh.elser@gmail.com
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> This would change the existing Committer == PMC,
> no?
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> That's the biggest thing I noticed scanning over
> the
> > > > > > document.
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> On 2/14/14, 1:19 PM, Mike Drob wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> I think we should have some Bylaws, as that gives
> > us
> > > > more
> > > > > > > > > structure
> > > > > > > > > > > to
> > > > > > > > > > > > >>> operate under.
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> I propose that we adopt the ZooKeeper bylaws,
> > > replacing
> > > > > all
> > > > > > > > > > > references
> > > > > > > > > > > > to
> > > > > > > > > > > > >>> ZK with Accumulo.
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> http://zookeeper.apache.org/bylaws.html
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> What say ye?
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> Mike
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > | - - -
> > > > > > > > > > | Bill Havanki
> > > > > > > > > > | Solutions Architect, Cloudera Government Solutions
> > > > > > > > > > | - - -
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > | - - -
> > > > | Bill Havanki
> > > > | Solutions Architect, Cloudera Government Solutions
> > > > | - - -
> > > >
> > >
> >
> >
> >
> > --
> > // Bill Havanki
> > // Solutions Architect, Cloudera Govt Solutions
> > // 443.686.9283
> >
>


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

--001a113a359c33806304f3df272f--