You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Bill Havanki <bh...@clouderagovt.com> on 2014/03/04 16:36:03 UTC
Re: [DISCUSS] Accumulo Bylaws
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 <bi...@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 <ma...@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 <bi...@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 <ma...@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
Re: [DISCUSS] Accumulo Bylaws
Posted by Mike Drob <ma...@cloudera.com>.
My apologies for these not making it into the document. I thought that you
had already made the changes yourself. Removed the business days thing,
that's makes sense.
I added the committer section almost verbatim. I made a few changes to your
proposed PMC section because it looked like a lot of that was covered by
the bullets we already have. Can you take another look?
On Wed, Mar 5, 2014 at 12:24 PM, Billie Rinaldi <bi...@gmail.com>wrote:
> I think my suggestions of clarifications for committer and PMC member
> responsibilities earlier in this thread might have been overlooked, so I'll
> repeat them. Also, I have a slight preference for not using business days
> for vote lengths since not all of our voters do this as their day job.
>
> 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.
>
>
>
> On Wed, Mar 5, 2014 at 9:14 AM, Bill Havanki <bhavanki@clouderagovt.com
> >wrote:
>
> > 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 <ma...@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
> >
>
Re: [DISCUSS] Accumulo Bylaws
Posted by Sean Busbey <bu...@cloudera.com>.
On Wed, Mar 5, 2014 at 11:24 AM, Billie Rinaldi <bi...@gmail.com>wrote:
>
> Also, I have a slight preference for not using business days
> for vote lengths since not all of our voters do this as their day job.
>
>
+1 I have a strong preference for not using business days.
Re: [DISCUSS] Accumulo Bylaws
Posted by Billie Rinaldi <bi...@gmail.com>.
I think my suggestions of clarifications for committer and PMC member
responsibilities earlier in this thread might have been overlooked, so I'll
repeat them. Also, I have a slight preference for not using business days
for vote lengths since not all of our voters do this as their day job.
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.
On Wed, Mar 5, 2014 at 9:14 AM, Bill Havanki <bh...@clouderagovt.com>wrote:
> 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 <ma...@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
>
Re: [DISCUSS] Accumulo Bylaws
Posted by Bill Havanki <bh...@clouderagovt.com>.
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 <ma...@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 <ma...@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
Re: [DISCUSS] Accumulo Bylaws
Posted by Sean Busbey <bu...@cloudera.com>.
To be consistent with what exists of related docs (namely releasing), I
think the location should be
http://accumulo.apache.org/governance/bylaws.html
I'd like the vote to also cover cleaning up related governance docs (like
voting and lazyConsensus) either incorporating references to them in the
bylaws or removing them as appropriate.
On Wed, Mar 5, 2014 at 10:50 AM, Mike Drob <ma...@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 <ma...@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
> >
>
Re: [DISCUSS] Accumulo Bylaws
Posted by Mike Drob <ma...@cloudera.com>.
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 <bh...@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 <ma...@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 <ma...@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
>