Re: HDFS-1623 branching strategy

2011-07-11 Thread sanjay Radia
Clearly we cannot get all the changes required for HA into 23. We would like to get some changes in that will allow one to build a HA solution before a 23.x release. What we want to discuss is what are the changes worth getting in into the current 0.23. Further many of the changes are

Emeritus

2011-07-11 Thread Allen Wittenauer
What is the policy for cleansing the PMC and marking them as emeritus? How much dead weight does there need to be before it gets pruned?

Re: Emeritus

2011-07-11 Thread Bernd Fondermann
On Mon, Jul 11, 2011 at 20:28, Allen Wittenauer a...@apache.org wrote:        What is the policy for cleansing the PMC and marking them as emeritus?  How much dead weight does there need to be before it gets pruned? Other PMCs I've been on, have dealt with this by contacting all PMC members

Re: HDFS-1623 branching strategy

2011-07-11 Thread Suresh Srinivas
Sorry for the late reply... My concern is not about creating a branch. Using a branch is some thing we have been doing for a long time for feature development and it is effective. Infact I am eager for branch for HA to be created, to start submitting the patches I am currently working on. Here

Re: HDFS-1623 branching strategy

2011-07-11 Thread Eli Collins
On Fri, Jul 8, 2011 at 3:40 PM, Jakob Homan jgho...@gmail.com wrote: I also have concerns.  While those working on the 1073 branch haven't abused the commit-then-review process, the fact remains that the final merge to trunk is equivalent to a 1.3MB patch that makes far-reaching changes to the

Re: HDFS-1623 branching strategy

2011-07-11 Thread Eli Collins
On Mon, Jul 11, 2011 at 1:28 PM, Suresh Srinivas sur...@hortonworks.com wrote: Sorry for the late reply... My concern is not about creating a branch. Using a branch is some thing we have been doing for a long time for feature development and it is effective. Infact I am eager for branch for

Re: HDFS-1623 branching strategy

2011-07-11 Thread Jakob Homan
Eli wrote: Each change was done individually with it's own jira, patch, and review. People can review the sub-tasks if they don't want to look at the entire patch. The majority of the changes were reviewed before they were committed, when that wasn't the case review feedback was incorporated

Commit then Review (was Re: HDFS-1623 branching strategy)

2011-07-11 Thread Arun C Murthy
On Jul 11, 2011, at 3:05 PM, Jakob Homan wrote: The question at hand is does the community want to go ahead with the 1073 model, or not? My preference is not, but since some in the community like it, I'd suggest making a small tweak to bring it closer in line with the intent of our bylaws,

Re: Commit then Review (was Re: HDFS-1623 branching strategy)

2011-07-11 Thread Arun C Murthy
On Jul 11, 2011, at 3:52 PM, Arun C Murthy wrote: However, blocking RTC en-masse is just counter-productive. We should let folks doing the work decide how best they want to do the work. To be clear: I support RTC for trunk and more stringent reviews for merge. Yet, all these need to be

Re: HDFS-1623 branching strategy

2011-07-11 Thread Jakob Homan
Deep sigh. I'm not blocking RTC on the branch. The branch maintainer gets to decide that. I'm not personally a big fan of it, but since it's not my branch, it's not my call. Either way the final patch to trunk goes by the normal rules that any patch to trunk follows. This is where I

Re: HDFS-1623 branching strategy

2011-07-11 Thread Eli Collins
On Mon, Jul 11, 2011 at 4:05 PM, Jakob Homan jgho...@gmail.com wrote: Deep sigh.  I'm not blocking RTC on the branch.  The branch maintainer gets to decide that.  I'm not personally a big fan of it, but since it's not my branch, it's not my call. Either way the final patch to trunk goes by

Re: HDFS-1623 branching strategy

2011-07-11 Thread Jakob Homan
s/RTC/CTR/g. oy. On Mon, Jul 11, 2011 at 4:05 PM, Jakob Homan jgho...@gmail.com wrote: Deep sigh.  I'm not blocking RTC on the branch.  The branch maintainer gets to decide that.  I'm not personally a big fan of it, but since it's not my branch, it's not my call. Either way the final patch to

Re: HDFS-1623 branching strategy

2011-07-11 Thread Eli Collins
On Mon, Jul 11, 2011 at 4:12 PM, Eli Collins e...@cloudera.com wrote: On Mon, Jul 11, 2011 at 4:05 PM, Jakob Homan jgho...@gmail.com wrote: Deep sigh.  I'm not blocking RTC on the branch.  The branch maintainer gets to decide that.  I'm not personally a big fan of it, but since it's not my

[VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Jakob Homan
As discussed in the recent thread on HDFS-1623 branching models, I'd like to amend the bylaws to provide that branches should get a minimum of three committer +1s before being merged to trunk. The rationale: Feature branches are often created in order that developers can iterate quickly without

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Todd Lipcon
To clarify, is there any restriction on who may give the +1s? For example, if a branch has a group of 5 committers primarily authoring the patches, can the three +1s be made by a subset of those committers? -Todd On Mon, Jul 11, 2011 at 5:11 PM, Jakob Homan jgho...@gmail.com wrote: As

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Jakob Homan
That's certainly not the intention, although I note that the current +1 requirement on code changes would apparently allow a committer to +1 h{is,er} own patch: A change made to a codebase of the project and committed by a committer. This includes source code, documentation, website content, etc.

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Eli Collins
+1 Sounds good to me. Something like the following? Index: main/author/src/documentation/content/xdocs/bylaws.xml == pLazy consensus of active committers, but with a minimum of -one +1. The code can be

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Jakob Homan
+1 to Eli's wording. On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins e...@cloudera.com wrote: +1   Sounds good to me. Something like the following? Index: main/author/src/documentation/content/xdocs/bylaws.xml ==            

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Aaron T. Myers
+1 from me as well. Thanks for running this vote, Jakob. Aaron On Jul 11, 2011, at 7:44 PM, Jakob Homan jgho...@gmail.com wrote: +1 to Eli's wording. On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins e...@cloudera.com wrote: +1 Sounds good to me. Something like the following? Index:

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Dhruba Borthakur
+1 On Tue, Jul 12, 2011 at 12:56 AM, Aaron T. Myers a...@cloudera.com wrote: +1 from me as well. Thanks for running this vote, Jakob. Aaron On Jul 11, 2011, at 7:44 PM, Jakob Homan jgho...@gmail.com wrote: +1 to Eli's wording. On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Arun C Murthy
+1 Arun On Jul 11, 2011, at 5:11 PM, Jakob Homan wrote: As discussed in the recent thread on HDFS-1623 branching models, I'd like to amend the bylaws to provide that branches should get a minimum of three committer +1s before being merged to trunk. The rationale: Feature branches are

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Mahadev Konar
+1 mahadev On Mon, Jul 11, 2011 at 9:26 PM, Arun C Murthy a...@hortonworks.com wrote: +1 Arun On Jul 11, 2011, at 5:11 PM, Jakob Homan wrote: As discussed in the recent thread on HDFS-1623 branching models, I'd like to amend the bylaws to provide that branches should get a minimum of

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Todd Lipcon
Sounds fine to me. +1 On Mon, Jul 11, 2011 at 9:30 PM, Mahadev Konar maha...@hortonworks.comwrote: +1 mahadev On Mon, Jul 11, 2011 at 9:26 PM, Arun C Murthy a...@hortonworks.com wrote: +1 Arun On Jul 11, 2011, at 5:11 PM, Jakob Homan wrote: As discussed in the recent thread

Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge

2011-07-11 Thread Suresh Srinivas
+1 from me.