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, 26 Feb 2014 21:41:56 GMT
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
> > > > > | - - -
> > > > >
> > > >
> > >
> >
>

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