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 Wed, 26 Feb 2014 20:56:34 GMT
I agree with Mike on renaming the various vote definitions.

Here's a list of committer responsibilities [1]. It's kind of thin. I guess
since C == PMC for us it doesn't matter much.

On kicking out PMC members [2]: It appears that we should not be voting on
it, but asking the Board to decide. Perhaps there can be a vote to submit
the request to the Board, in which case majority approval makes sense. Same
would go for kicking out committers, but not involving the Board, just
majority approval of PMC to remove.

Requiring a 2/3 majority for bylaw changes is similar to laws for proposing
and approving US federal and state constitutional amendments [3]. I don't
know if majority approval (minimum +3, more +1 than -1) is enough.

I like (non-lazy) consensus approval for adopting a new codebase, as an
alternative to 2/3 majority.

Aside: also in the committer FAQ, relevant to deactivating commit access
after inactivity, and kicking out committers:

No - committer status and merit never expires. If you become inactive for a
time (usually six months or more) your account may be deactivated for
security reasons. Most projects allow reactivation of committer status by
application to the pmc.


[1] http://www.apache.org/dev/committers.html#committer-responsibilities
[2] https://www.apache.org/dev/pmc.html#pmc-removal
[3] http://en.wikipedia.org/wiki/Supermajority#United_States



On Wed, Feb 26, 2014 at 1:15 PM, 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.
>
>
> > 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?
>
>
> > 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
| - - -

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