Chris, I find you are contradicting yourself within this message and with some other of yours.
But I want to address only one thing here > This has exposed a bug in our bylaws, which we can fix. This could be a bug, and we may need to fix it. But until then it is a bylaw, which is the only rule we have to come to an agreement if we disagree. If we both respect the rules we can come to an agreement. If not and people start forcing their way by saying the rule is wrong - let's ignore it today, or by conducting an infinite chain of counter votes - this creates chaos. Thanks, --Konstantin 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@). > >>> > >>> > >> >
