Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

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


Copy link to this message
-
RE: [DISCUSS] Apache Pig bylaws
Looks good to me; +1.

Olga

-----Original Message-----
From: Alan Gates [mailto:[EMAIL PROTECTED]]
Sent: Friday, October 01, 2010 5:00 PM
To: [EMAIL PROTECTED]
Subject: Re: [DISCUSS] Apache Pig bylaws

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:

"In general votes should not be called at times when it is known that  
interested members of the project will be unavailable."

This is weaker than what Ben suggested, but I'm not comfortable with  
having to pre-announce votes, as we want the project to be able to  
move as quickly as possible.  Is this strong enough for you Ben?

Alan.
On Sep 27, 2010, at 6:18 PM, Alan Gates wrote:

> As directed in our vote to become a TLP, we (Pig's PMC) need to set
> out bylaws for the project.  I have put up a first proposal for these
> by laws at http://wiki.apache.org/pig/ProposedByLaws.  Please take a
> look and give feedback.
>
> Alan.