Hi Folks, We are very interested in sharing what we are doing with the community. I think we can separate this into multiple stages.
1) To doug's point - Yes, absolutely, we want folks to review this. The patch is now available. Lets work together to get it formatted as folks like in subversion and reviewed. Where there are issues, let's work to resolve them. With luck folks will find this work consistent and useful. Backwards compatibility has been a goal, so with luck we will not ID regressions. As todd mentioned earlier point, a lot of this work has already been merged into CDH and all of it has been reviewed by several apache committers already. 2) This code works, it is the best hadoop we know of. If you run a business on hadoop, I think you would benefit from using it. Right now you don't have the choice of an Apache release if you are looking for a stabilized modern version of Hadoop. We would like to make apache releases based on it, source and binary, incorporating bugfixes from everyone. To do that we would of course need to follow the Apache Hadoop release process, which requires the release master to produce a release candidate and the PMC to vote on the release. Since that will require a formal future vote, no one will be surprised! 3) To nigel's point - I don't think this should distract anyone from working on 22 or other Hadoop contributions. The 22 team will have the option of incorporating this work. We think it will be a better release if they do, but that is their choice. The majority of out effort at yahoo is not going into 0.20 (this branch), we are working on future features for hadoop. This is branch is the stable code we use while we are waiting for a new release. Thanks, E14 On Jan 17, 2011, at 12:21 PM, Nigel Daley wrote: > > On Jan 17, 2011, at 12:11 PM, Doug Cutting wrote: > >> On 01/12/2011 11:07 PM, Arun C Murthy wrote: >>> Thus, I think a jumbo patch should suffice. It will also ensure this can >>> done quickly so that the community can then concentrate on 0.22 and beyond. >>> >>> However, I will (manually) ensure all relevant jiras are referenced in >>> the CHANGES.txt and Release Notes for folks to see the contents of the >>> release. This is the hardest part of the exercise. Also, this ensures >>> that we can track these jiras for 0.22 as Eli suggested. >>> >>> Does that seem like a reasonable way forward? I'm happy to brainstorm. >> >> We would not release this until each change in it has been reviewed by the >> community, right? Otherwise we may end up with changes in a 0.20 release >> that don't get approved when they're contributed to trunk and cause trunk to >> regress. So I don't yet see the point of committing the mega patch since >> the community needs to review each individual change anyway, so we might >> wait until each is reviewed to commit it. > > Unless this is a code-only drop into a branch w/ no formal Apache release. > If that's the case then I'm +1 on letting them commit in this way this one > time so we can all move on to 0.22. > > Nige >
