accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: [DISCUSS] Accumulo Bylaws
Date Wed, 05 Mar 2014 16:50:48 GMT
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
>

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