I've now started a separate discussion thread in common-dev@, titled "[PROPOSAL] change in bylaws to remove Release Plan vote". If it achieves consensus, I'll put it to a vote to so change the bylaws.
Best, --Matt On Sat, May 18, 2013 at 4:22 PM, Chris Douglas <cdoug...@apache.org> wrote: > 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@). > >>> > >>> > >> >
