The "release plan" vote is not binding in any way. Nobody "lost" a vote, or risks having an outcome reversed, because there are no consequences to these exercises.
Konstantin, I've been trying to tell you for more than a week that you can go forward without anyone's blessing or consent. There are no precedents, because the "release plan" vote has been a formality until now, and I don't know of any other projects that even bother with it. Most of our committers and PMC members didn't even know who was eligible to vote on it, because we usually ignore it. What *does* matter is the majority vote of the PMC on the release artifact. While we under-defined what the release plan means, we have zero ambiguity on when a release artifact becomes real. In the discussion, you were offered a minor release series, help selecting patches from branch-2, and every administrative barrier was removed from your path. Instead of taking this and running with it, you continued to press for... I don't know what. Please decide how you're going to move a development branch- any of them- forward and start working on it. There is nothing to "win" in these threads. This has exposed a bug in our bylaws, which we can fix. Right now, these "votes" are confusing everybody and stalling the project. I don't care who comes up with 2.0.5-beta, whether it's part of 2.1, or if we create 3.0. Any committer who wants to offer an candidate needs to demonstrate that they have a non-trivial, non-sectarian proportion of the community behind it by (1) creating the artifact (2) passing a PMC vote to make that artifact a release. It's that simple. With respect to the board: they are not parents, and we are not children. Neither are they interested or equipped to tell us how to partition releases of Hadoop. This is routine development, we are failing at it, but we will recover by eliminating this pointless ritual and getting back to producing software. -C On Fri, May 17, 2013 at 1:10 PM, Konstantin Shvachko <shv.had...@gmail.com> wrote: > BCC: general@ > > Since we recognize now that this is a vote to overrule previous decision, > I am referring to Vinod's note on general > *http://s.apache.org/h7x* > should this be brought to the attention of the Board? > > I don't remember any precedents of this kind in Hadoop history. > But other projects may have had such experience. > A clarification on categorizing this action and on voting practices > from ASF may help. > > Thanks, > --Konstantin > > > > On Wed, May 15, 2013 at 3:36 PM, Konstantin Shvachko > <shv.had...@gmail.com>wrote: > >> Arun, >> >> I am glad I at least convinced you to finally announce your release plan >> and put it into vote. >> Even though it is to overrule the vote that just completed, which you were >> against and lost, well - Twice. >> >> I am glad you removed the NFS feature from the list proposed earlier. >> >> I think this vote is late. The lazy consensus on that issue has been just >> reached. >> I don't see the basis for the new vote, >> and it is not clear what action you seek to approve. >> >> Thanks, >> --Konstantin >> >> >> >> On Wed, May 15, 2013 at 10:57 AM, 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. >>> >>> thanks, >>> Arun >>> >>> PS: To keep this discussion grounded in technical details I've moved this >>> to dev@ (bcc general@). >>> >>> >>
