Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge
+1. Tsz-Wo From: Stack To: general@hadoop.apache.org Sent: Tuesday, July 12, 2011 10:01 AM Subject: Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge +1 On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins wrote: > +1 Sounds good to me. > > Something like the following? > > Index: main/author/src/documentation/content/xdocs/bylaws.xml > == > Lazy consensus of active committers, but with a minimum of > - one +1. The code can be committed after the first +1. > + one +1. The code can be committed after the first +1, unless > + the code change represents a merge from a branch, in which case > + three +1s are required. > > > > > On Mon, 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 often created in order that developers can >> iterate quickly without the review then commit requirements of trunk. >> Branches' commit requirements are determined by the branch maintainer >> and in this situation are often set up as commit-then-review. As >> such, there is no way to guarantee that the entire changeset offered >> for trunk merge has had a second pair of eyes on it. Therefore, it is >> prudent to give that final merge heightened scrutiny, particularly >> since these branches often extensively affect critical parts of the >> system. Requiring three binding +1s does not slow down the branch >> development process, but does provide a better chance of catching bugs >> before they make their way to trunk. >> >> Specifically, under the Actions subsection, this vote would add a new >> bullet item: >> * Branch merge: A feature branch that does not require the same >> criteria for code to be committed to trunk will require three binding >> +1s before being merged into trunk. >> >> The last bylaw change required lazy majority of PMC and ran for 7 >> days, which I believe would apply to this one as well. That would >> have this vote ending 5pm PST July 18. >> -Jakob >> >
Re: Hadoop Java Versions
We could create an apache hadoop list of product selection discussions. I believe this list is intended to be focused on project governance and similar discussions. Maybe we should simply create a governance list and leave this one to be the free for all? On Jul 2, 2011, at 9:16 PM, Ian Holsman wrote: > > On Jul 2, 2011, at 7:38 AM, Ted Dunning wrote: > >> On Fri, Jul 1, 2011 at 11:53 AM, Abhishek Mehta wrote: >> >>> open and honest conversations on this thread/group, irrespective of >>> whether one represents a company or apache, should be encouraged. >>> >> >> Paradoxically, I partially agree with Ian on this. On the one hand, it is >> important to hear about alternatives in the same eco-system (and alternative >> approaches from other communities). That is a bit different from Ian's >> view. > > While I don't mind that technical alternatives get discussed, I do get PO'd > when > the conversation goes into why product X is better than Y, or when someone > makes claims that are incorrect because some 'customer' told them and stuff > like that. > > If we can keep it at architecture/approaches instead of why a certain product > is better than go right ahead. > >> >> Where I agree with him is that discussions should not be in the form of >> simple breast beating. Discussions should be driven by data and experience. >> All data and experience are of equal value if they represent quality >> thought. The only place that company names should figure in this is as a >> bookmark so you can tell which product/release has the characteristic under >> consideration. >> >> >>> ... And in that sense we all owe ASF and the hadoop community (and not any >>> one company) an equal amount of gratitude, humility and respect. >>> >> >> This doesn't get said nearly enough. >
Re: Hadoop Java Versions
On Wed, Jul 13, 2011 at 7:59 AM, Eric Baldeschwieler wrote: > We could create an apache hadoop list of product selection discussions. I > believe this list is intended to be focused on project governance and > similar discussions. Maybe we should simply create a governance list and > leave this one to be the free for all? > If you need to separate the discussions, then taking the discussion with smaller/more experienced set of participants to the new list is going to be easier than trying to sweep the tide. A list named "general" sounds a lot like "general discussions" to newcomers (and frankly, to old-timers like me). For that matter, is there a strong reason to segregate the discussions?
Re: Hoping to merge HDFS-1073 branch soon
On Tue, Jul 12, 2011 at 3:44 PM, Todd Lipcon wrote: > On Tue, Jul 12, 2011 at 10:38 AM, sanjay Radia wrote: > >> We can merge 1580 after 1073 is merged in. >> >> Looks like the biggest thing in your 1073 list is the Backup NN related >> changes. >> > > The BN-related changes are done and just awaiting code review. See > HDFS-1979. The current list of patches awaiting review are: HDFS-1979, > HDFS-2101, HDFS-2133, HDFS-1780, HDFS-2104, HDFS-2135. I'm reviewing these now. I started HDFS-1979 last week, it's a big change so taking me a little while. Thanks, Eli
Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge
+1 Cheers, Nige On Jul 12, 2011, at 10:01 AM, Stack wrote: > +1 > > On Mon, Jul 11, 2011 at 5:41 PM, Eli Collins wrote: >> +1 Sounds good to me. >> >> Something like the following? >> >> Index: main/author/src/documentation/content/xdocs/bylaws.xml >> == >> Lazy consensus of active committers, but with a minimum of >> -one +1. The code can be committed after the first +1. >> +one +1. The code can be committed after the first +1, unless >> +the code change represents a merge from a branch, in which case >> +three +1s are required. >> >> >> >> >> On Mon, 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 often created in order that developers can >>> iterate quickly without the review then commit requirements of trunk. >>> Branches' commit requirements are determined by the branch maintainer >>> and in this situation are often set up as commit-then-review. As >>> such, there is no way to guarantee that the entire changeset offered >>> for trunk merge has had a second pair of eyes on it. Therefore, it is >>> prudent to give that final merge heightened scrutiny, particularly >>> since these branches often extensively affect critical parts of the >>> system. Requiring three binding +1s does not slow down the branch >>> development process, but does provide a better chance of catching bugs >>> before they make their way to trunk. >>> >>> Specifically, under the Actions subsection, this vote would add a new >>> bullet item: >>> * Branch merge: A feature branch that does not require the same >>> criteria for code to be committed to trunk will require three binding >>> +1s before being merged into trunk. >>> >>> The last bylaw change required lazy majority of PMC and ran for 7 >>> days, which I believe would apply to this one as well. That would >>> have this vote ending 5pm PST July 18. >>> -Jakob >>> >>
Re: [VOTE] Change bylaws to require 3 binding +1s for branch merge
+1 Tom On Mon, 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 often created in order that developers can > iterate quickly without the review then commit requirements of trunk. > Branches' commit requirements are determined by the branch maintainer > and in this situation are often set up as commit-then-review. As > such, there is no way to guarantee that the entire changeset offered > for trunk merge has had a second pair of eyes on it. Therefore, it is > prudent to give that final merge heightened scrutiny, particularly > since these branches often extensively affect critical parts of the > system. Requiring three binding +1s does not slow down the branch > development process, but does provide a better chance of catching bugs > before they make their way to trunk. > > Specifically, under the Actions subsection, this vote would add a new > bullet item: > * Branch merge: A feature branch that does not require the same > criteria for code to be committed to trunk will require three binding > +1s before being merged into trunk. > > The last bylaw change required lazy majority of PMC and ran for 7 > days, which I believe would apply to this one as well. That would > have this vote ending 5pm PST July 18. > -Jakob >
hadoop-0.23
Hi All, It's looking like trunk is moving along rapidly - it's about time to start thinking of the next release to unlock all of the goodies there. As the RM, my current thinking is that after we merge NextGen MR (MR-279) and the HDFS-1073 branch into trunk we should be good to create the hadoop-0.23 branch. Thoughts? thanks, Arun
Re: HDFS-1623 branching strategy
On Jul 11, 2011, at 3:50 PM, Eli Collins wrote: > On Mon, Jul 11, 2011 at 3:05 PM, Jakob Homan wrote: >> Eli wrote: >>> > > This is the *branch* policy, which if I understand correctly, the > branch maintainer sets. > > Thanks, > Eli I do not understand the new role "branch maintainer". If this is to make decisions about the branch, content and direction, I am not in favor of that. I think it should be a collaborative process for folks working on the HA branch and not an individuals call. HA is a collaborative project based around the design that we published. Aaron has volunteered to help merge trunk into this branch; others working on the project can also help in merging. When it is finally merged into trunk we will go through the normal rules (as proposed by Jakob, 3+1s etc., assuming it passes).
Re: HDFS-1623 branching strategy
On Wed, Jul 13, 2011 at 5:40 PM, sanjay Radia wrote: > > On Jul 11, 2011, at 3:50 PM, Eli Collins wrote: > >> On Mon, Jul 11, 2011 at 3:05 PM, Jakob Homan wrote: >>> Eli wrote: >> >> This is the *branch* policy, which if I understand correctly, the >> branch maintainer sets. >> >> Thanks, >> Eli > > > I do not understand the new role "branch maintainer". If this is to make > decisions about the branch, content and direction, I am not in favor of that. > I think it should be a collaborative process for folks working on the HA > branch and not an individuals call. Completely agree - that should have read "branch maintainers" plural - didn't mean to suggest a new role. Any committer should be able to checking, help merge, etc a feature branch. This worked well for branch-0.20-append. Btw, we started [1] but never finished the adoption of the release manager (RM) role, we should do that. I've seen "release master" used in a couple of places, which I assume is synonymous. 1. http://www.mail-archive.com/general@hadoop.apache.org/msg01458.html > HA is a collaborative project based around the design that we published. > Aaron has volunteered to help merge trunk into this branch; others working on > the project can also > help in merging. When it is finally merged into trunk we will go through the > normal rules (as proposed by Jakob, 3+1s etc., assuming it passes). That's my understanding as well. Thanks, Eli
Re: hadoop-0.23
On Wed, Jul 13, 2011 at 3:39 PM, Arun C Murthy wrote: > Hi All, > > It's looking like trunk is moving along rapidly - it's about time to start > thinking of the next release to unlock all of the goodies there. > > As the RM, my current thinking is that after we merge NextGen MR (MR-279) > and the HDFS-1073 branch into trunk we should be good to create the > hadoop-0.23 branch. > > Thoughts? > Sounds great. In order to support HA in a dot release we'll need to merge in the branch for HDFS-1623, but that shouldn't hold up branching for 23. Sanjay mentioned this as the summit but I wanted to double check with you, you support a dot release of 23 with HA? The hope is that we support one of the multiple options HDFS-1623 allows for, and that we introduce an incompatible change only when absolutely necessary. If that doesn't work for you we could do a 0.24 release for HA but the hope is that we'll get more people contributing to this release. Thanks, Eli
Re: hadoop-0.23
On Wed, Jul 13, 2011 at 6:10 PM, Arun C Murthy wrote: > > On Jul 13, 2011, at 6:01 PM, Eli Collins wrote: > >> On Wed, Jul 13, 2011 at 3:39 PM, Arun C Murthy wrote: >>> Hi All, >>> >>> It's looking like trunk is moving along rapidly - it's about time to start >>> thinking of the next release to unlock all of the goodies there. >>> >>> As the RM, my current thinking is that after we merge NextGen MR (MR-279) >>> and the HDFS-1073 branch into trunk we should be good to create the >>> hadoop-0.23 branch. >>> >>> Thoughts? >>> >> >> Sounds great. >> >> In order to support HA in a dot release we'll need to merge in the >> branch for HDFS-1623, but that shouldn't hold up branching for 23. >> Sanjay mentioned this as the summit but I wanted to double check with >> you, you support a dot release of 23 with HA? The hope is that we >> support one of the multiple options HDFS-1623 allows for, and that we >> introduce an incompatible change only when absolutely necessary. >> > > +1 > > I'd strongly be in favour of a dot release of 0.23 with HA - this would be a > step forward for Hadoop. > > Let's discuss the specifics a little longer down the road once HA is further > along? Makes sense? > Excellent. Sounds good. Thanks, Eli
Re: hadoop-0.23
On Jul 13, 2011, at 6:01 PM, Eli Collins wrote: > On Wed, Jul 13, 2011 at 3:39 PM, Arun C Murthy wrote: >> Hi All, >> >> It's looking like trunk is moving along rapidly - it's about time to start >> thinking of the next release to unlock all of the goodies there. >> >> As the RM, my current thinking is that after we merge NextGen MR (MR-279) >> and the HDFS-1073 branch into trunk we should be good to create the >> hadoop-0.23 branch. >> >> Thoughts? >> > > Sounds great. > > In order to support HA in a dot release we'll need to merge in the > branch for HDFS-1623, but that shouldn't hold up branching for 23. > Sanjay mentioned this as the summit but I wanted to double check with > you, you support a dot release of 23 with HA? The hope is that we > support one of the multiple options HDFS-1623 allows for, and that we > introduce an incompatible change only when absolutely necessary. > +1 I'd strongly be in favour of a dot release of 0.23 with HA - this would be a step forward for Hadoop. Let's discuss the specifics a little longer down the road once HA is further along? Makes sense? thanks, Arun
Re: hadoop-0.23
On Jul 13, 2011, at 6:01 PM, Eli Collins wrote: > > In order to support HA in a dot release we'll need to merge in the > branch for HDFS-1623, but that shouldn't hold up branching for 23. > Sanjay mentioned this as the summit but I wanted to double check with > you, you support a dot release of 23 with HA? Please don't do this. 0.23 is a MASSIVE change. Introducing even more instability in the form of a new major feature in the middle of a release that is bound to be full of problems is not a good idea. Anyone who runs a production system will basically ignore 0.23 because it simply won't be stable enough. (It *always* takes a .1 or .2 or even a .3 before things are actually rock solid.) I'd much rather see 0.24 have HA than 0.23.
