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, 26 Feb 2014 21:24:38 GMT
An alternative path to importing a code base is to send it through
incubation[1]. Ugh, I feel like we're going to run into analysis paralysis
pretty soon.

[1]: https://www.apache.org/dev/pmc.html#import


On Wed, Feb 26, 2014 at 3:56 PM, Bill Havanki <bhavanki@clouderagovt.com>wrote:

> 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