On May 15, 2013, at 3:27 PM, Chris Douglas wrote: > +1 (binding) on the proposal. > > However, the value we get from these "release plan" votes is dubious, > to put it mildly. The surrounding discussion has cost more than it is > worth, and votes on executive summaries of releases discourage the > sort of detailed collaboration we're trying to create. It replaces > development with zero-sum struggles over abstractions.
Agree, I propose we edit bylaws to do away with them for the future. > > This is, in effect, another poll about the direction we're taking 2.x. > If we can't reach consensus on development directions without voting, > that's more evidence that the project should be split, IMO. -C +1e100 Arun > > On Wed, May 15, 2013 at 2:21 PM, Steve Loughran <ste...@hortonworks.com> > wrote: >> On 15 May 2013 10:57, Arun C Murthy <a...@hortonworks.com> wrote: >> >>> Folks, >>> >>> A considerable number of people have expressed confusion regarding the >>> recent vote on 2.0.5, beta status etc. given lack of specifics, the voting >>> itself (validity of the vote itself, whose votes are binding) etc. >>> >>> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability >>> of 3 features under debate etc.) have been lost in the discussion in favor >>> of non-technical (almost dramatic) nuances such as "seizing the moment". >>> There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) >>> - this is a red flag for me; particularly when there are just 3 features >>> being debated and active committers and contributors are confident of and >>> ready to stand by their work. All patches, I believe, are ready to be >>> merged in the the next few days per discussions on jira. This will, >>> clearly, not delay the other API work which everyone agrees is crucial. As >>> a result, I feel no recourse but to restart a new vote - all attempts at >>> calm, reasoned, civil discussion based on technical arguments have come to >>> naught - I apologize for the thrash caused to everyone's attention. >>> >>> To get past all of this confusion, I'd like to present an alternate, >>> specific proposal for consideration. >>> >>> I propose we continue the original plan and make a 2.0.5-beta release by >>> May end with the following content: >>> # HDFS-347 >>> # HDFS Snapshots >>> # Windows support >>> # Necessary & final API/protocol changes such as: >>> * Final YARN API changes: YARN-386 >>> * MR Binary Compatibility: MAPREDUCE-5108 >>> * Final RPC cleanup: HADOOP-8990 >>> >>> People working on the above features have all expressed considerable >>> comfort with them and are ready to stand-by to help expedite any necessary >>> bug-fixes etc. to get to stabilization quickly. I'm confident we can get >>> this release out by end of May. This sets stage for a hadoop-2.x GA release >>> right after with some more testing - this means I think I can quickly turn >>> around and make bug-fix releases as necessary right after 2.0.5-beta. >>> >>> I request that people consider helping out with this plan and sign up to >>> help push hadoop-2.x to stability as outlined above. I believe this will >>> help achieve our shared goals of quickly stabilizing hadoop-2 and help >>> ensure we can support it for forseeable future in a compatible manner for >>> the benefit of our users and downstream projects. >>> >>> Please vote, the vote will run the normal 7 days. Obviously, I'm +1. >>> >> >> +1 (binding) -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/