I'm not going to cast a vote, but I'm concerned about this for the same reasons Eli brought up -- in particular, compatibility with 0.22. I'm an author of several patches that have gone into 0.21 and trunk, only to stay on hiatus for 2 years because the project hasn't made a stable release since 0.20. (Today, many of these patches are being used through CDH, which is great, but it would be nice to see them in an Apache release too.) This push of features into 0.20.203 makes a widely used 0.22 seem even more distant. Can we at least get a confirmation that these changes will be included in 0.22, as well as a timeline?
To support a vibrant developer community, Apache Hadoop should not just be a mechanism for Yahoo and Cloudera to publish patches. It should include a well-defined process for smaller third-party contributors to push changes that will make it into a stable release within a reasonable time horizon. The lack of such a process has been a major cause for the slowdown in the project in my perspective. Matei On May 4, 2011, at 10:47 PM, Eric Sammer wrote: > (non-binding) -1 for similar reasons to what Jeff and others have laid out, > and certainly if we're going to change the development process as a side > effect of a release vote. > > On Wed, May 4, 2011 at 9:54 PM, Jeff Hammerbacher <ham...@cloudera.com>wrote: > >> -1. >> >> As Roy says, "whatever gets released will define the new norm by which >> policies are assumed", and I certainly don't want this project to change >> its >> norms to accommodate bad practices. In particular, Eli presented three very >> reasonable technical objections to this release. To summarize: >> >> 1) Let's get the JIRAs that are going into this release into trunk first. >> 2) Let's create a JIRA for each issue in the release. >> 3) Let's stick to the release numbering conventions established for this >> project. >> >> I know the folks at Yahoo! are all professional engineers and done >> tremendous work to help get the project to this point. There's no doubt in >> my mind they understand the validity of the above three technical >> objections. In fact, many of them helped author our "How to Contribute" >> page, which established these conventions: >> wiki.apache.org/hadoop/HowToContribute. We develop new features against >> trunk, we create JIRAs for each issue, we review code before it goes into >> trunk, and we only update old releases with bug fixes. >> >> I couldn't be more excited to have Yahoo! once again doing development in >> Apache, and I hope that we can work together to get the work that you've >> done in this branch into one of our upcoming feature releases. >> >> I hope those who voted +1 before Roy clarified what a release vote will >> mean >> for future project norms will reconsider their votes. >> >> While there may be many competing agendas in this community, we all wish to >> see Apache Hadoop releases of the highest quality. Changing our norms to >> allow huge, unreviewed patch sets introducing new features into a past >> release is a step in the wrong direction. >> >> With a little bit of elbow grease, we can get the work done in this branch >> into trunk, get 0.22 out the door, and be ready for a great 0.23 release. >> >> Later, >> Jeff >> >> On Wed, May 4, 2011 at 9:17 PM, Nigel Daley <nda...@mac.com> wrote: >> >>> I'm really not sure yet how to vote here. I was going to vote +1 for >> what >>> I was told by a number of Yahoo! committers would be a one time release >> as >>> Yahoo! "comes back to Apache" after a hiatus last fall/winter and ended >>> their own distribution. Clearly this code was not all developed as a >>> community process, but I was going to support a one time release of what >>> they had developed in exclusion. >>> >>> Then I read Roy's email, which confused me. We would he or I or anyone >>> else support this release setting precedent or policy since it would walk >>> all over our bylaws, community process, and the consensus nature of our >>> foundation? This release vote is a lazy majority of the PMC, but other >>> decisions rolled up in this are supposed to be lazy majority of active >>> committers or, in the case of code changes, a lazy consensus. Setting >>> policy by this release means any sufficiently large group of committers >>> could go off and develop on their own and then commit it to a branch and >>> call a release. >>> >>> Furthermore, it now sounds like this is possibly the first in a line of >>> feature releases off this branch. Bug fixes releases, sure. But feature >>> releases? What's wrong with trunk? >>> >>> Nige >>> >>> On May 4, 2011, at 6:56 PM, Roy T. Fielding wrote: >>> >>>> On May 4, 2011, at 5:39 PM, Eli Collins wrote: >>>> >>>>> The point is that these discussion should be sorted out, ie you don't >>>>> change your development and release model on a release VOTE thread, >>>>> you change it on a DISCUSSION thread. >>>> >>>> That is no different than saying you have a right to veto a >>>> release until the issue is addressed, which you don't have. >>>> >>>> A release vote is a majority decision. If the majority >>>> decides to release, then whatever gets released will define >>>> the new norm by which policies are assumed. If not released, >>>> then I suggest collaborating more on the policies before >>>> trying to vote again. >>>> >>>> Either way, we don't hold up a vote for the sake of a >>>> policy discussion because voting is a more efficient >>>> means of discovering if the policy really matters. >>>> >>>> ....Roy >>>> >>> >>> >> > > > > -- > Eric Sammer > twitter: esammer > data: www.cloudera.com
