accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <billie.rina...@gmail.com>
Subject Re: [DISCUSS] Accumulo Bylaws
Date Wed, 05 Mar 2014 17:24:35 GMT
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