Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Pig >> mail # user >> [DISCUSS] Apache Pig bylaws

Alan Gates 2010-09-28, 01:18
Alan Gates 2010-10-02, 00:00
Olga Natkovich 2010-10-04, 15:47
Copy link to this message
Re: [DISCUSS] Apache Pig bylaws
The bylaws look good, but I would like to raise two issues -

Shouldn¹t the majority requirement for changing the bylaws be more strict
than those required by the actions in bylaws ?
For example, the bylaw for removing a committer requires a consensus, but
for changing this by-law requires only 2/3rd majority. Ie, effectively,
2/3rd majority can remove a committer !
Should changing the bylaws should require consensus as well?

Should we consider another unlikely situation ? - What if two committers are
unable to communicate for long duration for some reason (stuck on some
lonely island without internet!)? Actions that require consensus approval
would not be possible. (you can't remove a inactive voter and then have
another consensus vote because two voters are missing).
Should we have a maximum duration for casting votes that require consensus ?
(2 months ?)


On 10/1/10 5:00 PM, "Alan Gates" <[EMAIL PROTECTED]> wrote:

> I have drafted a second version of this.  I made the following changes:
> 1. Based on Dmitriy's feedback on clarity for code change votes, I
> changed the approval column of the code change row of the voting table
> to say:
> "Lazy approval (not counting the vote of the contributor), moving to
> lazy majority if a -1 is received"
> I think this expresses what Dmitriy believed to be the case that every
> code change requires a +1 from a committer that is not the contributor
> of the code.  Note that this is stronger than what I indicated had
> been our practice in the past (to allow contributors to +1 committer's
> patches).  But it seems reasonable.  If a contributor knows the code
> well enough to give authoritative votes on contributions s/he should
> probably be a committer.  And as far as I know this was only done on
> Zebra because it had only one committer.
> 2. Based on Dmitriy's feedback on the horrors of rolling back checkins
> (done by responding with a -1 on a commit message), I added the
> following sentence:
> "Note that this should be a rare occurrence. All efforts should be
> made to discuss issues when they are still patches before the code is
> committed."
> 3. Based on Olga's feedback of the need for timetables for votes, I
> defined a minimum length for each type of vote.  All vote lengths are
> in business days.  I set code changes at 1 day; release plan, product
> release, new committer, and new PMC member at 3 days; and adoption of
> new code base, committer removal, and PMC member removal at 6 days.  I
> picked 1 day for code changes because we don't want to wait long
> periods of time to get patches in but we should wait at least a day so
> that developers all around the world can take a look.  I used 3 days
> for other common votes as that is the length currently used by
> Hadoop.  I picked 6 days for the others because these are momentous
> votes and 6 days guarantees one week for everyone to consider and
> respond.
> 4. As suggested by Olga I reviewed other Apache projects to find their
> requirements for consensus votes.  Most of the projects I reviewed had
> no bylaws that I could find.  httpd and Jakarta had bylaws that
> covered voting but none discussed votes such as removing committers or
> PMC members that we stipulate would require unanimous votes with no
> abstentions.  Both Ant and Xerces did have bylaws for this, and both
> require unanimous votes with no abstentions to remove a committer or
> PMC member.  See http://ant.apache.org/bylaws.html,
> http://jakarta.apache.org/site/decisions.html
> , http://httpd.apache.org/dev/guidelines.html,
> http://xerces.apache.org/charter.html
>   for details.
> Given that we had one speak in favor of lowering this bar (Olga) and 2
> speak in favor of the bar where it is (Alan and Santhosh), for the
> moment it stays where it is.  If others have thoughts on this, please
> contribute them.
> 5. In response to Ben's suggestion on pre-announcing votes, I added
> the following sentence to the guidelines on voting:
Olga Natkovich 2010-10-04, 18:47
Alan Gates 2010-10-05, 20:15
Olga Natkovich 2010-10-05, 20:24
Benjamin Reed 2010-10-05, 20:32
Daniel Dai 2010-10-05, 20:41
Thejas M Nair 2010-10-05, 20:55
Dmitriy Ryaboy 2010-10-05, 21:38
Santhosh Srinivasan 2010-09-28, 02:27
Olga Natkovich 2010-09-28, 23:39
Dmitriy Ryaboy 2010-09-29, 00:20
Alan Gates 2010-09-29, 00:47
Alan Gates 2010-09-29, 05:44
Santhosh Srinivasan 2010-09-29, 17:57
Benjamin Reed 2010-09-29, 21:32
Olga Natkovich 2010-09-30, 16:27
Benjamin Reed 2010-09-29, 21:55
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB