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 <[email protected]>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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > 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 <[email protected] > > > > > > wrote: > > > > > > > > > Oops, yes of course! It's editable. > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Feb 15, 2014 at 7:01 PM, Bill Havanki < > > > [email protected] > > > > > >wrote: > > > > > > > > > > > Thanks Arshak! Can you either allow editing or commenting? > > > > > > > > > > > > > > > > > > On Fri, Feb 14, 2014 at 6:10 PM, Arshak Navruzyan < > > [email protected] > > > > > > > > > > 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 < > > [email protected]> > > > > > > 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 < > > [email protected]> > > > > > > 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 < > > > > [email protected] > > > > > > > > > > > > > > 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 > | - - - >
