(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
