accumulo-dev mailing list archives

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

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