accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Havanki <bhava...@clouderagovt.com>
Subject Re: [DISCUSS] Accumulo Bylaws
Date Tue, 04 Mar 2014 15:36:03 GMT
OK, made a bunch of changes:

- changed code change approval to lazy, then consensus
- changed new codebase approval to consensus
- changed bylaw change approval to majority - this is my preference, but
I'm willing to yield and go with consensus at this point, anybody can
change it
- removed vote actions for kicking out committers and PMC members
- removed definitions for 2/3 majority and "full consensus", which weren't
defined by ASF
- added this sentence for C == PMC, feel free to strengthen but I like the
teeny bit of wiggle room:

It is the custom of the Accumulo project to also invite each committer to
become a member of the Accumulo PMC.

- added paragraph on commit access being disabled for routine security,
using "may" so that we never are required to do it:

An emeritus committer's commit access may be disabled as part of routine
security. Access shall not be removed without notifying the committer, and
access shall be maintained if the committer wishes to leave it active. A
committer's commit access shall be reactivated upon the committer's request
to the PMC.

>From my POV, these changes might handle all our open issues. I'd like to
ask everyone to take another look at the doc and see if we can get to a
vote and close this effort out.

Bill H


On Thu, Feb 27, 2014 at 1:17 PM, Billie Rinaldi <billie.rinaldi@gmail.com>wrote:

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



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

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