Pipes Output http://pipes.yahoo.com/pipes/pipe.info?_id=qtPlGpw33hGuPsNH6ycw5g Wed, 22 May 2013 15:56:35 +0000 http://pipes.yahoo.com/pipes/ http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAGQgZQQZCYJgpPxrqf_DEHchm1Y10=v9vLM7V0Rr2f4TUAfHvQ@mail.gmail.com%3e Sorry, there were some fails (with unescaped query string). If you had already submitted a application, please check whether your application is complete. http://dev.hadoop.co.kr/ On Tue, May 21, 2013 at 5:29 PM, Edward J. Yoon wrote: > Hi, > > I'm planning the Hadoop In Seoul 2013 Open Conference with some > organizations, such as the Korea government IT agency and OSS > Association. We're looking for people who have interested in sharing > about Hadoop Internals or their experience of developing applications > with Hadoop ecosystem. > > This is your great opportunity to share your insights, advanced > technical knowledge and experience of Apache Hadoop with the Korean > dev group. If you have an interesting presentation idea, we want to > hear from you! > > Conference topics: > > * Internals > * Ecosystem > * Practical know-how and Case studies > > We have created a Call for Speakers form to invite potential speakers > to participate: http://dev.hadoop.co.kr/ > > The call for speakers will be closed on July 15th, and conference will > be held on Saturday Aug 01-02 or Sep 05-06, 2013 (tentative schedule) > in Seoul. > > If you have any questions about this or need help about schedule and > expenses for flights, Please feel free to contact: > edwardyoon@apache.org. If possible, we'd like to invite one+ active > OSS committers in Apache Hadoop ecosystem. > > Thanks ;) > -- > Best Regards, Edward J. Yoon > @eddieyoon -- Best Regards, Edward J. Yoon @eddieyoon "Edward J. Yoon" urn:uuid:%3cCAGQgZQQZCYJgpPxrqf_DEHchm1Y10=v9vLM7V0Rr2f4TUAfHvQ@mail-gmail-com%3e Wed, 22 May 2013 07:16:46 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCDC1316A.D0ADC%25chris.a.mattmann@jpl.nasa.gov%3e +1million I completely agree with Chris D's separate email too about not vote'ing about intentions, and voting on actual artifacts. The fact of the matter at the ASF is that any PMC member; heck any contributor can roll a release candidate. If that candidate receives at least 3 PMC member +1s (to make it binding as backed by the Foundation and its distributed committees and structure), and more +1s than -1s, you've got yourself a release. It's up to someone on the PMC/committee at that point to publish the bits on ASF infrastructure and ultimately to make sure that whoever made the RC has a key that's present in a KEYS file or on id.apache.org, but beyond that, that's it.* Cheers, Chris * - if Joe Schmoe comes along and makes a release candidate that passes muster with the Hadoop PMC, then I would expect Joe Schmoe should be added to the PMC :) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Chris Mattmann, Ph.D. Senior Computer Scientist NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA Office: 171-266B, Mailstop: 171-246 Email: chris.a.mattmann@nasa.gov WWW: http://sunset.usc.edu/~mattmann/ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Adjunct Assistant Professor, Computer Science Department University of Southern California, Los Angeles, CA 90089 USA ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -----Original Message----- From: Matt Foley Reply-To: "common-dev@hadoop.apache.org" , "mattf@apache.org" Date: Tuesday, May 21, 2013 2:10 PM To: "common-dev@hadoop.apache.org" Subject: [PROPOSAL] change in bylaws to remove Release Plan vote >Hi all, >This has been a side topic in several email threads recently. Currently >we >have an ambiguity. We have a tradition in the dev community that any >committer can create a branch, and propose release candidates from it. >Yet >the Hadoop bylaws say that releases have to be planned in advance, the >plan >needs to be voted on, and presumably can be denied. > >Apache policies (primarily here > and here , with >non-normative commentary >here ce>) >are very clear on how Releases have to be approved, and our bylaws are >consistent with those policies. But Apache policies don't say anything >I've found about Release Plans, nor about voting on Release Plans. > >I propose the following change, to remove Release Plan votes, and give a >simple definition of Release Manager role. I'm opening discussion with >this proposal, and will put it to a vote if we seem to be getting >consensus. Here's the changes I suggest in the >Bylaws > document: > >=== > >1. In the "Decision Making" : "Actions" section of the Bylaws, the >following text is removed: > >** Release Plan* > >Defines the timetable and actions for a release. The plan also nominates a >Release Manager. > >Lazy majority of active committers > > >2. In the "Roles and Responsibilities" section of the Bylaws, an >additional >role is defined: > >** Release Manager* > >A Release Manager (RM) is a committer who volunteers to produce a Release >Candidate according to >HowToRelease . > The RM shall publish a Release Plan on the *common-dev@* list stating the >branch from which they intend to make a Release Candidate, at least one >week before they do so. The RM is responsible for building consensus >around >the content of the Release Candidate, in order to achieve a successful >Product Release vote. > >=== > >Please share your views. >Best regards, >--Matt (long-time release manager) "Mattmann, Chris A (398J)" urn:uuid:%3cCDC1316A-D0ADC%25chris-a-mattmann@jpl-nasa-gov%3e Tue, 21 May 2013 21:17:01 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCA+z3+9EH+fAvtNQpZn-8ARve1eSrrMwLzfo2ey=J6DGgAEfQoQ@mail.gmail.com%3e 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 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 > 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 > > 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 >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@). > >>> > >>> > >> > Matt Foley urn:uuid:%3cCA+z3+9EH+fAvtNQpZn-8ARve1eSrrMwLzfo2ey=J6DGgAEfQoQ@mail-gmail-com%3e Tue, 21 May 2013 21:13:47 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutEQf9a6=DnsF1Jica1aVA+S3D9bGq=kZqG=SAZZfsmxyw@mail.gmail.com%3e 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 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 > 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 > > 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 >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@). > >>> > >>> > >> > Konstantin Shvachko urn:uuid:%3cCAKtuutEQf9a6=DnsF1Jica1aVA+S3D9bGq=kZqG=SAZZfsmxyw@mail-gmail-com%3e Tue, 21 May 2013 08:51:47 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAGQgZQR9jqGsLXW6YORp3QxMkcoY_e5XgjUuOwEPeA5c6PNXEw@mail.gmail.com%3e Hi, I'm planning the Hadoop In Seoul 2013 Open Conference with some organizations, such as the Korea government IT agency and OSS Association. We're looking for people who have interested in sharing about Hadoop Internals or their experience of developing applications with Hadoop ecosystem. This is your great opportunity to share your insights, advanced technical knowledge and experience of Apache Hadoop with the Korean dev group. If you have an interesting presentation idea, we want to hear from you! Conference topics: * Internals * Ecosystem * Practical know-how and Case studies We have created a Call for Speakers form to invite potential speakers to participate: http://dev.hadoop.co.kr/ The call for speakers will be closed on July 15th, and conference will be held on Saturday Aug 01-02 or Sep 05-06, 2013 (tentative schedule) in Seoul. If you have any questions about this or need help about schedule and expenses for flights, Please feel free to contact: edwardyoon@apache.org. If possible, we'd like to invite one+ active OSS committers in Apache Hadoop ecosystem. Thanks ;) -- Best Regards, Edward J. Yoon @eddieyoon "Edward J. Yoon" urn:uuid:%3cCAGQgZQR9jqGsLXW6YORp3QxMkcoY_e5XgjUuOwEPeA5c6PNXEw@mail-gmail-com%3e Tue, 21 May 2013 08:29:06 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCACO5Y4zX1sxvWoMN1_RxQ2OJTrwxZwKypSD4rCE7rVg52RwWpw@mail.gmail.com%3e 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 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 > 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 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@). >>> >>> >> Chris Douglas urn:uuid:%3cCACO5Y4zX1sxvWoMN1_RxQ2OJTrwxZwKypSD4rCE7rVg52RwWpw@mail-gmail-com%3e Sat, 18 May 2013 23:22:47 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutFnb=k7A0kSenyhqpJp0M5XCFyUUbjPMnCT9jeofgOU_w@mail.gmail.com%3e 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 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 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@). >> >> > Konstantin Shvachko urn:uuid:%3cCAKtuutFnb=k7A0kSenyhqpJp0M5XCFyUUbjPMnCT9jeofgOU_w@mail-gmail-com%3e Fri, 17 May 2013 20:10:15 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c14A974EE-804E-4B37-8AFF-2AD4BBF7B1F4@apache.org%3e There is a different vote thread that is happening on dev lists which potentially overrides this vote. You may want to hold on till that vote concludes. Thanks, +Vinod On May 16, 2013, at 6:23 PM, Konstantin Boudnik wrote: > > I can do RM'ing for this release. I would highly appreciate any help from > anyone who's interested in the stabilization of 2.0.x line of Hadoop. > > Thanks, > Cos Vinod Kumar Vavilapalli urn:uuid:%3c14A974EE-804E-4B37-8AFF-2AD4BBF7B1F4@apache-org%3e Fri, 17 May 2013 04:10:57 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c20130517012321.GC27292@linspire.com%3e On Tue, May 14, 2013 at 10:47PM, Konstantin Shvachko wrote: > Yes, Vinod. Thanks for understanding. > > The plan is not to add any new features in 2.0.5. Only API changes to allow > potential feature backports in subsequent releases. > I will rename branch-2.0-alpha Arun created to branch-2.0.5 (right after > this), make changes on it, then release. Similar to branch-0.23 model. > > Renaming of current 2.0.5-beta to 2.1 is great. > Do I understand correctly that renaming current 2.0.5-beta to 2.1 is a > change in CHANGES.txt and renaming Jira versions, since 2.0.5-beta branch > has not been carved? > > Guys, please raise your voice to volunteer for the RM role? I will take on > it if nobody wants it. > I guess it will take a day or two to sort things out after the vote. I can do RM'ing for this release. I would highly appreciate any help from anyone who's interested in the stabilization of 2.0.x line of Hadoop. Thanks, Cos > On Tue, May 14, 2013 at 6:45 PM, Vinod Kumar Vavilapalli < > vinodkv@hortonworks.com> wrote: > > > > > Have no idea what you meant there. > > > > Even though several others noted that it isn't clear what is being voted > > on, trying to make sense out of it, it seems that > > - you don't want any new features at all in 2.0.5. > > - The originally planned 2.0.5 *has* already got new features which go > > against this vote result. > > > > So I think, Arun proposed that we rename the originally planned 2.0.5 to > > 2.1 and you said yes. Arun then he went ahead and copied 2.0.4-alpha to > > 2.0-alpha where it can be 'stabilized'. > > > > And then this. > > > > Please make it clear. Unfortunately there are those who have the onus of > > reviewing/committing some 'features' to branch-2. Please let us know what > > is okay. > > > > Will start committing to branch-2 unless I hear otherwise. > > > > The other concern is about merging patches into this 'stability-branch'. > > Clearly the vote doesn't tell who the RM is and it isn't clear who is doing > > it. Till that happens, I'll skip merging patches to branch-2.0-alpha branch > > - whether the patch is a feature or a bug needs to be negotiated with the > > RM *when in doubt*. > > > > Thanks, > > +Vinod > > > > On May 14, 2013, at 11:52 AM, Konstantin Shvachko wrote: > > > > > Sounds like you are having fun, Arun. > > > 2.0.5 is explicitly in the subject line for this vote. > > > No worries I'll fix that. > > > > > > You should stop assuming - it's in nobody interests - and start reading. > > > --Konst > > > > > > > > > On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy > > wrote: > > > > > >> > > >> On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: > > >> > > >>>> I can point you towards a set of fixes I think important for YARN > > >>> (nodemanager, security etc.). > > >>> > > >>> That would be very much appreciated. > > >>> > > >>>> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. > > >>> > > >>> Thanks. > > >>> > > >> > > >> Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. > > >> > > >> This way you can start with a clean slate. Good luck. > > >> > > >> As I noted before in the thread, the APIs in branch-2.0-alpha will > > remain > > >> incompatible with branch-2. > > >> > > >> thanks, > > >> Arun > > > > Konstantin Boudnik urn:uuid:%3c20130517012321-GC27292@linspire-com%3e Fri, 17 May 2013 01:23:21 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCDBA8209.241F4%25nroberts@yahoo-inc.com%3e +1 (non-binding) >From my perspective: * The key feature that will drive me to adopt 2.x is Rolling Upgrades * In order to get to rolling upgrades, we need a compatibility story that is significantly better than we have today * We need a comprehensive definition of what compatibility really means * We need better testing in place to verify we're not breaking compatibility * We need better definition and testing of what rolling upgrades really means. Rolling between bug-fix releases ­ Required, Rolling between minor releases ­ Required, Rolling between major releases ­ Desired. * We need work-preserving restart on the YARN side. Restarting jobs isn't sufficient. * Š * Given that Rolling upgrades aren't there yet, and there is still work to be done to solidify the compatibility story, I'm ok with the feature window remaining open until these are in place, especially given the fact that the proposed features are likely to have non-zero impact on compatibility/rolling_upgrades. * I'd certainly like a release with rolling upgrades as soon as possible, so I feel like the feature window needs to ramp down very quickly. Something like 2.0.5-beta in May with the current list of proposed features, then 2.0.6-beta in late summer with full rolling upgrade support and a solid compatibility story, would seem like a reasonable timeline. Once we have a beta release with rolling upgrades, I can look at pushing 2.x to some of our larger clusters. Nathan Roberts nroberts@yahoo-inc.com On 5/15/13 12:57 PM, "Arun C Murthy" 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@). > Nathan Roberts urn:uuid:%3cCDBA8209-241F4%25nroberts@yahoo-inc-com%3e Thu, 16 May 2013 17:36:20 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c760CBD96-2B47-4CC3-A634-38309651EDAD@apache.org%3e There is a thread going on with a more specific release plan for 2.0.5-beta at common-dev@. Please vote there. Unlike the last vote where apparently it wasn't clear to some of the committers, stating clearly: all committers and PMC have binding votes for release plans according to Hadoop bylaws. Thanks, +Vinod Kumar Vavilapalli Begin forwarded message: > From: Arun C Murthy > Subject: [VOTE] - Release 2.0.5-beta > Date: May 15, 2013 10:57:30 AM PDT > To: common-dev@hadoop.apache.org > Reply-To: common-dev@hadoop.apache.org > > 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@). > Vinod Kumar Vavilapalli urn:uuid:%3c760CBD96-2B47-4CC3-A634-38309651EDAD@apache-org%3e Wed, 15 May 2013 18:08:57 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c48A037BF-5EE8-44EA-BE27-0BBB46DA0B5B@hortonworks.com%3e 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@). Arun C Murthy urn:uuid:%3c48A037BF-5EE8-44EA-BE27-0BBB46DA0B5B@hortonworks-com%3e Wed, 15 May 2013 17:57:30 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCADdVdVGWHZ0uYvdZGJGKpHeZxfn4j_hOqdT6dMsPzOtDWLWzcg@mail.gmail.com%3e Now, here's the rationale: speaking from an experience of building > a community-driven distribution on top of Hadoop releases I can > attest to how badly we (and all the downstream projects) need a > stable 2.x baseline. Perhaps a less featurefull one, but the one > that would parallel stability of 1.x code line. > > The downstream projects are struggling mightily with the fact that > it is never quite safe to assume 2.0.x to be stable (to be honest > we labeled it alpha for a reason). We have to have *something*. > Roman, I think no one disagrees with the need for stabilization. Even before this vote started, we were moving towards stability from 2.0.4-alpha to 2.0.5-beta with main focus on API/protocol compatibility, which I assume is the most important thing for downstream projects. > > Of course, as you point out, the fact that a more featureful > 2.1.x line now might become incompatible with a stable base > of 2.0.x is something to worry about. I've struggled with it > myself and finally accepted it as a much lesser evil. > > I think this is a bad idea. I am personally against incompatible 2.1.x. The lesser evil I see is, spending possibly few more days of including well tested features, instead of suddenly appearing on release discussions, starting this vote, disrupting the previous decisions and insisting on spinning out a release at any cost, without clearly articulating what the plans for stabilizing are or what compatibility will be guaranteed. Finally, imagine that we're successful with 2.0.x stabilization and all > of the downstream now has it as a default profile(*) I can guarantee > you that it would generate tons of additional feedback that would > be quite useful to future stabilization of 2.1.x. At this point this > feedback is lost. > I do not think feedback is lost. We are getting this feedback from many folks who are spending time, building features and testing features. We also get the feedback from 0.23 stabilization, which has immensely helped 2.x. No one is disagreeing about the need for quickly going to 2.0 GA. The disagreement is on the path towards that. Regards, Suresh Suresh Srinivas urn:uuid:%3cCADdVdVGWHZ0uYvdZGJGKpHeZxfn4j_hOqdT6dMsPzOtDWLWzcg@mail-gmail-com%3e Wed, 15 May 2013 17:39:46 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCA+ULb+s2+RS_PuXDhSAim5Rr-xPM3dpaFV4TOB0btNrTYE_0oQ@mail.gmail.com%3e On Wed, May 15, 2013 at 1:20 AM, Matt Foley wrote: > Additional features that everybody wants in Hadoop-2 still remain to be > added. We KNOW these will result in non-backward-compatible API changes. > So by trying to do a stability line of code now, we are terminating the > effort to achieve backward-compatibility in Hadoop-2 APIs. > > Did this community really intend to vote for that? Because that's what > we've now got. This was one of the crucial points for me as well (if you rewind the thread you could see my original vote being -1 precisely because I did NOT want to have incompatible changes within the same "namespace" of 2.0). After Arun has proposed a different namespace of 2.1.x I changed my vote to +1. Now, here's the rationale: speaking from an experience of building a community-driven distribution on top of Hadoop releases I can attest to how badly we (and all the downstream projects) need a stable 2.x baseline. Perhaps a less featurefull one, but the one that would parallel stability of 1.x code line. The downstream projects are struggling mightily with the fact that it is never quite safe to assume 2.0.x to be stable (to be honest we labeled it alpha for a reason). We have to have *something*. Of course, as you point out, the fact that a more featureful 2.1.x line now might become incompatible with a stable base of 2.0.x is something to worry about. I've struggled with it myself and finally accepted it as a much lesser evil. Finally, imagine that we're successful with 2.0.x stabilization and all of the downstream now has it as a default profile(*) I can guarantee you that it would generate tons of additional feedback that would be quite useful to future stabilization of 2.1.x. At this point this feedback is lost. Thanks, Roman. P.S. In fact we need it so badly, that Cos and I are going to have a panel discussion at HUG (@Yahoo campus) tonight on that very subject. Everybody who feels passionate about this and would like to share ideas/observations would be extremely welcome to participate on the panel. (*) And speaking of the default profiles, here's my favorite way of demonstrating that downstream is hurting: $ cd ~/src/random-hadoop-downstream-project $ mvn help:all-profiles Listing Profiles for Project: XXXX Profile Id: hadoop_0.20.203 (Active: true , Source: pom) Profile Id: hadoop_1.0 (Active: false , Source: pom) Profile Id: hadoop_non_secure (Active: false , Source: pom) Profile Id: hadoop_facebook (Active: false , Source: pom) Profile Id: hadoop_0.23 (Active: false , Source: pom) Profile Id: hadoop_yarn (Active: false , Source: pom) Profile Id: hadoop_2.0.0 (Active: false , Source: pom) Profile Id: hadoop_2.0.1 (Active: false , Source: pom) Profile Id: hadoop_2.0.2 (Active: false , Source: pom) Profile Id: hadoop_2.0.3 (Active: false , Source: pom) Profile Id: hadoop_trunk (Active: false , Source: pom) Profile Id: hadoop_cdh4.1.2 (Active: false , Source: pom) And good luck finding Maven artifacts for it! Roman Shaposhnik urn:uuid:%3cCA+ULb+s2+RS_PuXDhSAim5Rr-xPM3dpaFV4TOB0btNrTYE_0oQ@mail-gmail-com%3e Wed, 15 May 2013 16:50:23 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCABCYYb_jRYR26e0+BRPmziQAtL9mxmvVNhaXEvapdb7nEPw0Sg@mail.gmail.com%3e I have a question about dev process in light of this vote. As a contributor, how do I set the Target Version/s field correctly in jiras to inform reviewers and committers of the proper destination for my code? Before this vote, my rough guideline was "if Windows-specific, then 3.0.0, else 2.0.X and 3.0.0". After this vote, it seems there are some additional nuances, such that incompatible changes need to target 2.1.X + 3.0.0, and perhaps simple bug fixes like adding a null check need to target 2.0.X + 2.1.X + 3.0.0. As others have stated, there may even be ambiguity or disagreement about the definition of "simple bug fixes". The specifics are difficult to anticipate, so committers may need to come to agreement on some general guidelines, and then debate further as needed on individual patches. If this is generally confusing for the community (not just my own confusion), then I'll volunteer to add notes in the HowToContribute wiki once we have the answers. Chris Nauroth Hortonworks http://hortonworks.com/ On Wed, May 15, 2013 at 2:17 AM, Arun C Murthy wrote: > > On May 15, 2013, at 12:45 AM, Konstantin Shvachko wrote: > > > Hello Arun, > > > > Please accept my apologies for what could have been considered as a rude > > response. > > Didn't mean any sort of incivility. > > Accepted. Thanks. > > > Please attribute my emotional response to the onus of explaining over and > > over again that > > - I am not opposed to the features > > - not forcing a release profile on you > > - but rather propose a more conservative release sequence with a focus on > > stability. > > in the last two weeks. > > > > If the version rename we agreed upon earlier is still valid, please > proceed. > > I am blocked on the rename of artifacts. > > > > I presume we can move this to dev. > > Frankly, I'm still confused how/why this has evolved or where it's > reached. But yes, let's move it to dev. > > Arun > > Chris Nauroth urn:uuid:%3cCABCYYb_jRYR26e0+BRPmziQAtL9mxmvVNhaXEvapdb7nEPw0Sg@mail-gmail-com%3e Wed, 15 May 2013 16:31:37 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c50D98C33-F048-4F41-9519-4654079F7336@hortonworks.com%3e On May 15, 2013, at 12:45 AM, Konstantin Shvachko wrote: > Hello Arun, > > Please accept my apologies for what could have been considered as a rude > response. > Didn't mean any sort of incivility. Accepted. Thanks. > Please attribute my emotional response to the onus of explaining over and > over again that > - I am not opposed to the features > - not forcing a release profile on you > - but rather propose a more conservative release sequence with a focus on > stability. > in the last two weeks. > > If the version rename we agreed upon earlier is still valid, please proceed. > I am blocked on the rename of artifacts. > > I presume we can move this to dev. Frankly, I'm still confused how/why this has evolved or where it's reached. But yes, let's move it to dev. Arun Arun C Murthy urn:uuid:%3c50D98C33-F048-4F41-9519-4654079F7336@hortonworks-com%3e Wed, 15 May 2013 09:17:31 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCA+z3+9GupsVDoZrBee=NTTWvOKZBHdxT+ata5f1_dssp-4467A@mail.gmail.com%3e Having just finished the 1.2.0 release, I have now taken the time to carefully read this entire thread. (For a more enjoyable experience, I'm practicing walking on hot coals next week :-) I think something got lost in the argumentation: First of all, what I understand is that 1. Arun is being asked to take his progression of 2.0.x-alpha releases to a new 2.1.x (perhaps 2.1.x-beta?) line 2. Konst is being allowed to repurpose the 2.0.x line, starting with 2.0.5, into a stabilization line for the subset of Hadoop-2 features already in 2.0.4-alpha. [I say "allowed" because, while any committer can make a new branch and propose releases from it, Konst has proposed to take over an existing sequence of branches, for which a dedicated and long-term Release Manager has previously proposed a well-understood sequence of releases; see http://s.apache.org/BmM ] Here's the thing that got lost, and I think we better clarify: Additional features that everybody wants in Hadoop-2 still remain to be added. We KNOW these will result in non-backward-compatible API changes. So by trying to do a stability line of code now, we are terminating the effort to achieve backward-compatibility in Hadoop-2 APIs. Did this community really intend to vote for that? Because that's what we've now got. --Matt On Wed, May 15, 2013 at 12:45 AM, Konstantin Shvachko wrote: > Hello Arun, > > Please accept my apologies for what could have been considered as a rude > response. > Didn't mean any sort of incivility. > Please attribute my emotional response to the onus of explaining over and > over again that > - I am not opposed to the features > - not forcing a release profile on you > - but rather propose a more conservative release sequence with a focus on > stability. > in the last two weeks. > > If the version rename we agreed upon earlier is still valid, please > proceed. > I am blocked on the rename of artifacts. > > I presume we can move this to dev. > > Thanks, > --Konst > > > > On Tue, May 14, 2013 at 11:52 AM, Konstantin Shvachko > wrote: > > > Sounds like you are having fun, Arun. > > 2.0.5 is explicitly in the subject line for this vote. > > No worries I'll fix that. > > > > You should stop assuming - it's in nobody interests - and start reading. > > --Konst > > > > > > On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy >wrote: > > > >> > >> On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: > >> > >> >> I can point you towards a set of fixes I think important for YARN > >> > (nodemanager, security etc.). > >> > > >> > That would be very much appreciated. > >> > > >> >> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. > >> > > >> > Thanks. > >> > > >> > >> Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. > >> > >> This way you can start with a clean slate. Good luck. > >> > >> As I noted before in the thread, the APIs in branch-2.0-alpha will > remain > >> incompatible with branch-2. > >> > >> thanks, > >> Arun > > > > > > > Matt Foley urn:uuid:%3cCA+z3+9GupsVDoZrBee=NTTWvOKZBHdxT+ata5f1_dssp-4467A@mail-gmail-com%3e Wed, 15 May 2013 08:20:30 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutE_07DxPJthX9=XJin-WPBXH65YOMoaRfBRWgWkn=ucAA@mail.gmail.com%3e Hello Arun, Please accept my apologies for what could have been considered as a rude response. Didn't mean any sort of incivility. Please attribute my emotional response to the onus of explaining over and over again that - I am not opposed to the features - not forcing a release profile on you - but rather propose a more conservative release sequence with a focus on stability. in the last two weeks. If the version rename we agreed upon earlier is still valid, please proceed. I am blocked on the rename of artifacts. I presume we can move this to dev. Thanks, --Konst On Tue, May 14, 2013 at 11:52 AM, Konstantin Shvachko wrote: > Sounds like you are having fun, Arun. > 2.0.5 is explicitly in the subject line for this vote. > No worries I'll fix that. > > You should stop assuming - it's in nobody interests - and start reading. > --Konst > > > On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy wrote: > >> >> On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: >> >> >> I can point you towards a set of fixes I think important for YARN >> > (nodemanager, security etc.). >> > >> > That would be very much appreciated. >> > >> >> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. >> > >> > Thanks. >> > >> >> Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. >> >> This way you can start with a clean slate. Good luck. >> >> As I noted before in the thread, the APIs in branch-2.0-alpha will remain >> incompatible with branch-2. >> >> thanks, >> Arun > > > Konstantin Shvachko urn:uuid:%3cCAKtuutE_07DxPJthX9=XJin-WPBXH65YOMoaRfBRWgWkn=ucAA@mail-gmail-com%3e Wed, 15 May 2013 07:45:02 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCA+z3+9Er-fx6XwZ=refL1aa70qSKKREhBc3Rz0XP3aSOhaVh6w@mail.gmail.com%3e I'm happy to announce that on May 13, Hadoop version 1.2.0 passed its release vote. It is now available in SVN and is in process of propagating to artifact mirrors. It should be available on all mirrors by end of day Wednesday. This release delivers over 200 enhancements and bug-fixes, compared to the previous 1.1.2 release. Major enhancements include: - DistCp v2 backported - Web services for JobTracker - WebHDFS enhancements - Extensions of task placement and replica placement policy interfaces - Offline Image Viewer backported - Namenode more robust in case of edit log corruption - Add NodeGroups level to NetworkTopology - Add "unset" to Configuration API Please see the Hadoop 1.2.0 Release Notes for more details. This is a beta release. I intend to start a stabilization release (version 1.2.1) in 3 weeks from now. All open Jira tickets with Target Version "1.2.0" that weren't yet closed, were moved to Target Version 1.3.0. However, if you want something fixed in 1.2.1, you are encouraged to edit that ticket, change its Target Version to 1.2.1, and contribute a patch to branch-1.2. Bug fixes are welcome in 1.2.1. However, we ask that significant feature enhancements be contributed to branch-1 for the future version 1.3.0, instead. Thank you, and enjoy your new release. Best regards, --Matt (release manager, version 1.2) Matt Foley urn:uuid:%3cCA+z3+9Er-fx6XwZ=refL1aa70qSKKREhBc3Rz0XP3aSOhaVh6w@mail-gmail-com%3e Wed, 15 May 2013 07:32:02 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCADadbPGV9VcCJCUiE0cxmjTGTyT_9_KmqLUOBAvogDAFDoHo7A@mail.gmail.com%3e NSW == some random phone substitution. I meant "specifics" On 14 May 2013 23:09, "Steve Loughran" wrote: > That's because i thought this was a PMC vote. I marked mine as non binding > as I'm only a commiter. Now that the NSW of this badly structured vote is > clearer, I would vote -1 binding on it unless it was clarified better and > accounted with a policy to receive how you would get forward API > compatibility while keeping out those features that you seem personally > opposed to.. > On 14 May 2013 21:42, "Konstantin Shvachko" wrote: > >> Vinod, >> >> Steve explicitly marked his vote as non-binding. >> I counted it as such. >> >> Thanks, >> --Konst >> >> >> On Tue, May 14, 2013 at 1:15 PM, Vinod Kumar Vavilapalli < >> vinodkv@hortonworks.com> wrote: >> >> > >> > The vote count is wrong: >> > >> > 6 binding +1s >> > 5 binding -1s >> > 4 non-binding +1s >> > 2 non-binding -1s. >> > >> > I think you mis-counted stevel, whose vote is binding. >> > >> > On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: >> > >> > > This vote passes with >> > > 6 binding +1s >> > > 4 non-binding +1 >> > > 4 binding -1 >> > > 3 non-binding -1 >> > > >> > > Thank you for voting, >> > > --Konstantin >> > > >> > > >> > > On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko >> > > wrote: >> > > >> > >> Please vote on the following plan for Hadoop release 2.0.5 >> > >> - bug fixes encountered in current release 2.0.4-alpha >> > >> - make all API changes to allow freezing them post 2.0.5 >> > >> - no new features >> > >> >> > >> As discussed on @dev thread >> > >> http://s.apache.org/fs >> > >> this will allow to stabilize 2.0 branch in a short and predictable >> > period >> > >> of time. >> > >> This enables a powerful option to have the release tested at Yahoo >> > scale. >> > >> The plan is to follow up with 2.1.0 - the stable release. >> > >> New features can and should be added on top of the stable release >> once >> > it >> > >> is out. >> > >> >> > >> Hadoop by-laws: >> > >> http://hadoop.apache.org/bylaws.html >> > >> >> > >> "Release Plan >> > >> Defines the timetable and actions for a release. The plan also >> > nominates a >> > >> Release Manager. >> > >> Lazy majority of active committers" >> > >> >> > >> assume nomination of a Release Manager with the plan. >> > >> It would be really good if Arun continues if this plan is adopted. >> > >> We can return to the RM topic if not. >> > >> >> > >> The vote will run for 7 days until next Wed, May 8th. >> > >> >> > >> Thanks, >> > >> --Konstantin >> > >> >> > >> > >> > Steve Loughran urn:uuid:%3cCADadbPGV9VcCJCUiE0cxmjTGTyT_9_KmqLUOBAvogDAFDoHo7A@mail-gmail-com%3e Wed, 15 May 2013 06:10:47 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCADadbPHS=-ui4fDdVM9zwvX7u7=j8D3j6wmxNdmsySxNe9pr3A@mail.gmail.com%3e That's because i thought this was a PMC vote. I marked mine as non binding as I'm only a commiter. Now that the NSW of this badly structured vote is clearer, I would vote -1 binding on it unless it was clarified better and accounted with a policy to receive how you would get forward API compatibility while keeping out those features that you seem personally opposed to.. On 14 May 2013 21:42, "Konstantin Shvachko" wrote: > Vinod, > > Steve explicitly marked his vote as non-binding. > I counted it as such. > > Thanks, > --Konst > > > On Tue, May 14, 2013 at 1:15 PM, Vinod Kumar Vavilapalli < > vinodkv@hortonworks.com> wrote: > > > > > The vote count is wrong: > > > > 6 binding +1s > > 5 binding -1s > > 4 non-binding +1s > > 2 non-binding -1s. > > > > I think you mis-counted stevel, whose vote is binding. > > > > On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: > > > > > This vote passes with > > > 6 binding +1s > > > 4 non-binding +1 > > > 4 binding -1 > > > 3 non-binding -1 > > > > > > Thank you for voting, > > > --Konstantin > > > > > > > > > On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko > > > wrote: > > > > > >> Please vote on the following plan for Hadoop release 2.0.5 > > >> - bug fixes encountered in current release 2.0.4-alpha > > >> - make all API changes to allow freezing them post 2.0.5 > > >> - no new features > > >> > > >> As discussed on @dev thread > > >> http://s.apache.org/fs > > >> this will allow to stabilize 2.0 branch in a short and predictable > > period > > >> of time. > > >> This enables a powerful option to have the release tested at Yahoo > > scale. > > >> The plan is to follow up with 2.1.0 - the stable release. > > >> New features can and should be added on top of the stable release once > > it > > >> is out. > > >> > > >> Hadoop by-laws: > > >> http://hadoop.apache.org/bylaws.html > > >> > > >> "Release Plan > > >> Defines the timetable and actions for a release. The plan also > > nominates a > > >> Release Manager. > > >> Lazy majority of active committers" > > >> > > >> assume nomination of a Release Manager with the plan. > > >> It would be really good if Arun continues if this plan is adopted. > > >> We can return to the RM topic if not. > > >> > > >> The vote will run for 7 days until next Wed, May 8th. > > >> > > >> Thanks, > > >> --Konstantin > > >> > > > > > Steve Loughran urn:uuid:%3cCADadbPHS=-ui4fDdVM9zwvX7u7=j8D3j6wmxNdmsySxNe9pr3A@mail-gmail-com%3e Wed, 15 May 2013 06:09:14 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutFGZ55xc+jBH8A-V1Nb597K5vSF31-s_3WobFnNyMPvig@mail.gmail.com%3e Yes, Vinod. Thanks for understanding. The plan is not to add any new features in 2.0.5. Only API changes to allow potential feature backports in subsequent releases. I will rename branch-2.0-alpha Arun created to branch-2.0.5 (right after this), make changes on it, then release. Similar to branch-0.23 model. Renaming of current 2.0.5-beta to 2.1 is great. Do I understand correctly that renaming current 2.0.5-beta to 2.1 is a change in CHANGES.txt and renaming Jira versions, since 2.0.5-beta branch has not been carved? Guys, please raise your voice to volunteer for the RM role? I will take on it if nobody wants it. I guess it will take a day or two to sort things out after the vote. Thanks, --Konst On Tue, May 14, 2013 at 6:45 PM, Vinod Kumar Vavilapalli < vinodkv@hortonworks.com> wrote: > > Have no idea what you meant there. > > Even though several others noted that it isn't clear what is being voted > on, trying to make sense out of it, it seems that > - you don't want any new features at all in 2.0.5. > - The originally planned 2.0.5 *has* already got new features which go > against this vote result. > > So I think, Arun proposed that we rename the originally planned 2.0.5 to > 2.1 and you said yes. Arun then he went ahead and copied 2.0.4-alpha to > 2.0-alpha where it can be 'stabilized'. > > And then this. > > Please make it clear. Unfortunately there are those who have the onus of > reviewing/committing some 'features' to branch-2. Please let us know what > is okay. > > Will start committing to branch-2 unless I hear otherwise. > > The other concern is about merging patches into this 'stability-branch'. > Clearly the vote doesn't tell who the RM is and it isn't clear who is doing > it. Till that happens, I'll skip merging patches to branch-2.0-alpha branch > - whether the patch is a feature or a bug needs to be negotiated with the > RM *when in doubt*. > > Thanks, > +Vinod > > On May 14, 2013, at 11:52 AM, Konstantin Shvachko wrote: > > > Sounds like you are having fun, Arun. > > 2.0.5 is explicitly in the subject line for this vote. > > No worries I'll fix that. > > > > You should stop assuming - it's in nobody interests - and start reading. > > --Konst > > > > > > On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy > wrote: > > > >> > >> On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: > >> > >>>> I can point you towards a set of fixes I think important for YARN > >>> (nodemanager, security etc.). > >>> > >>> That would be very much appreciated. > >>> > >>>> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. > >>> > >>> Thanks. > >>> > >> > >> Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. > >> > >> This way you can start with a clean slate. Good luck. > >> > >> As I noted before in the thread, the APIs in branch-2.0-alpha will > remain > >> incompatible with branch-2. > >> > >> thanks, > >> Arun > > Konstantin Shvachko urn:uuid:%3cCAKtuutFGZ55xc+jBH8A-V1Nb597K5vSF31-s_3WobFnNyMPvig@mail-gmail-com%3e Wed, 15 May 2013 05:47:07 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutFRNC7jHKbaCzSkNUBSazML8hvESTzxFaPs=caJ6ORGyw@mail.gmail.com%3e Steve, 2.0.4-alpha is released. --Konst On Tue, May 14, 2013 at 5:50 PM, Steve Loughran wrote: > On 14 May 2013 11:52, Konstantin Shvachko wrote: > > > Sounds like you are having fun, Arun. > > 2.0.5 is explicitly in the subject line for this vote. > > No worries I'll fix that. > > > > You should stop assuming - it's in nobody interests - and start reading. > > --Konst > > > > OK, I've been reading and have to say I'm confused. > > "If the next release has to be 2.0.5 I would like to make an alternative > proposal, which would include > - stabilization of current 2.0.4 > - making all API changes to allow freezing them post 2.0.5 > And nothing else. > " > > This means, if my interpretation is correct, that > > 1. there is a new fork off 2.0.4-alpha which has a name like 2.0.4-alpha-1 > (as requested in JIRA), which will iterated until something ships, name > potentially 2.0.5 > > 2. All "features" since 2.0.4-alpha are out, but API stabilisation is in. > > 3. There is some agreed on definition of API which may include -but is not > restricted to-: class signature, wire format, persistent data structures, > semantics as defined by tests cases, semantics as defined by some > formal/semi-formal specification, and the n-dimensional configuration > manifold defined by the set of parameters read from -config.xml. > > Implications > > #1: there is/will-soon-be a fork in SVN of 2.0.4-alpha which is going to be > released. > > #2: the RM and/or others have volunteered to pull in all the changes needed > to say "this is frozen and stable" and if you code against it then its > going to work for the duration of the 2.x line. > > #3: but not changes considered "features". > > Now: > > 1. What if there is a feature that is also an API change? How is the > definition of feature vs non-feature going to be taken up? > > 2. If there is already a change between 2.0.4-alpha and the forthcoming > 2.0.5-beta which is visible at the API level then these will have to be > backport that so that its behaviour remains consistent over time. > > 3 If those changes in (2) are part of a feature by (1), then is someone > going to have to tease out the bits that will be declared "stable, API" and > not "feature, unstable" > > Help me understand, > > -Steve > Konstantin Shvachko urn:uuid:%3cCAKtuutFRNC7jHKbaCzSkNUBSazML8hvESTzxFaPs=caJ6ORGyw@mail-gmail-com%3e Wed, 15 May 2013 05:09:05 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutEWBUARkXZ1mp72nHsC-+Ji2poTRkTwOhyBCSbWNjiwHQ@mail.gmail.com%3e Vinod, Steve explicitly marked his vote as non-binding. I counted it as such. Thanks, --Konst On Tue, May 14, 2013 at 1:15 PM, Vinod Kumar Vavilapalli < vinodkv@hortonworks.com> wrote: > > The vote count is wrong: > > 6 binding +1s > 5 binding -1s > 4 non-binding +1s > 2 non-binding -1s. > > I think you mis-counted stevel, whose vote is binding. > > On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: > > > This vote passes with > > 6 binding +1s > > 4 non-binding +1 > > 4 binding -1 > > 3 non-binding -1 > > > > Thank you for voting, > > --Konstantin > > > > > > On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko > > wrote: > > > >> Please vote on the following plan for Hadoop release 2.0.5 > >> - bug fixes encountered in current release 2.0.4-alpha > >> - make all API changes to allow freezing them post 2.0.5 > >> - no new features > >> > >> As discussed on @dev thread > >> http://s.apache.org/fs > >> this will allow to stabilize 2.0 branch in a short and predictable > period > >> of time. > >> This enables a powerful option to have the release tested at Yahoo > scale. > >> The plan is to follow up with 2.1.0 - the stable release. > >> New features can and should be added on top of the stable release once > it > >> is out. > >> > >> Hadoop by-laws: > >> http://hadoop.apache.org/bylaws.html > >> > >> "Release Plan > >> Defines the timetable and actions for a release. The plan also > nominates a > >> Release Manager. > >> Lazy majority of active committers" > >> > >> assume nomination of a Release Manager with the plan. > >> It would be really good if Arun continues if this plan is adopted. > >> We can return to the RM topic if not. > >> > >> The vote will run for 7 days until next Wed, May 8th. > >> > >> Thanks, > >> --Konstantin > >> > > Konstantin Shvachko urn:uuid:%3cCAKtuutEWBUARkXZ1mp72nHsC-+Ji2poTRkTwOhyBCSbWNjiwHQ@mail-gmail-com%3e Wed, 15 May 2013 04:42:20 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c214E5E69-B834-4238-91B1-EAE00CA5D233@hortonworks.com%3e Konstantine I read the email from Arun that you quoted, three times; I can't see anything that Arun said that warrants your rude response. You have made a couple of uncivil comments recently. Not sure what is bugging you, but regardless, this sort of behavior is unwarranted. Further, such insulting comments does not help the conversation in this thread which, as several have noted, is already confusing . sanjay On May 14, 2013, at 11:52 AM, Konstantin Shvachko wrote: > Sounds like you are having fun, Arun. > 2.0.5 is explicitly in the subject line for this vote. > No worries I'll fix that. > > You should stop assuming - it's in nobody interests - and start reading. > --Konst > > > On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy wrote: > >> >> On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: >> >>>> I can point you towards a set of fixes I think important for YARN >>> (nodemanager, security etc.). >>> >>> That would be very much appreciated. >>> >>>> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. >>> >>> Thanks. >>> >> >> Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. >> >> This way you can start with a clean slate. Good luck. >> >> As I noted before in the thread, the APIs in branch-2.0-alpha will remain >> incompatible with branch-2. >> >> thanks, >> Arun sanjay Radia urn:uuid:%3c214E5E69-B834-4238-91B1-EAE00CA5D233@hortonworks-com%3e Wed, 15 May 2013 04:16:15 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cB7E0E682-3C5E-42C1-950C-AB71E97552D8@hortonworks.com%3e Have no idea what you meant there. Even though several others noted that it isn't clear what is being voted on, trying to make sense out of it, it seems that - you don't want any new features at all in 2.0.5. - The originally planned 2.0.5 *has* already got new features which go against this vote result. So I think, Arun proposed that we rename the originally planned 2.0.5 to 2.1 and you said yes. Arun then he went ahead and copied 2.0.4-alpha to 2.0-alpha where it can be 'stabilized'. And then this. Please make it clear. Unfortunately there are those who have the onus of reviewing/committing some 'features' to branch-2. Please let us know what is okay. Will start committing to branch-2 unless I hear otherwise. The other concern is about merging patches into this 'stability-branch'. Clearly the vote doesn't tell who the RM is and it isn't clear who is doing it. Till that happens, I'll skip merging patches to branch-2.0-alpha branch - whether the patch is a feature or a bug needs to be negotiated with the RM *when in doubt*. Thanks, +Vinod On May 14, 2013, at 11:52 AM, Konstantin Shvachko wrote: > Sounds like you are having fun, Arun. > 2.0.5 is explicitly in the subject line for this vote. > No worries I'll fix that. > > You should stop assuming - it's in nobody interests - and start reading. > --Konst > > > On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy wrote: > >> >> On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: >> >>>> I can point you towards a set of fixes I think important for YARN >>> (nodemanager, security etc.). >>> >>> That would be very much appreciated. >>> >>>> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. >>> >>> Thanks. >>> >> >> Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. >> >> This way you can start with a clean slate. Good luck. >> >> As I noted before in the thread, the APIs in branch-2.0-alpha will remain >> incompatible with branch-2. >> >> thanks, >> Arun Vinod Kumar Vavilapalli urn:uuid:%3cB7E0E682-3C5E-42C1-950C-AB71E97552D8@hortonworks-com%3e Wed, 15 May 2013 01:45:21 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCADadbPE=wX8Yh0-E32e9SqU1gPXtzrnymTd7WU6Wm+v5N8m9yw@mail.gmail.com%3e On 14 May 2013 11:52, Konstantin Shvachko wrote: > Sounds like you are having fun, Arun. > 2.0.5 is explicitly in the subject line for this vote. > No worries I'll fix that. > > You should stop assuming - it's in nobody interests - and start reading. > --Konst > OK, I've been reading and have to say I'm confused. "If the next release has to be 2.0.5 I would like to make an alternative proposal, which would include - stabilization of current 2.0.4 - making all API changes to allow freezing them post 2.0.5 And nothing else. " This means, if my interpretation is correct, that 1. there is a new fork off 2.0.4-alpha which has a name like 2.0.4-alpha-1 (as requested in JIRA), which will iterated until something ships, name potentially 2.0.5 2. All "features" since 2.0.4-alpha are out, but API stabilisation is in. 3. There is some agreed on definition of API which may include -but is not restricted to-: class signature, wire format, persistent data structures, semantics as defined by tests cases, semantics as defined by some formal/semi-formal specification, and the n-dimensional configuration manifold defined by the set of parameters read from -config.xml. Implications #1: there is/will-soon-be a fork in SVN of 2.0.4-alpha which is going to be released. #2: the RM and/or others have volunteered to pull in all the changes needed to say "this is frozen and stable" and if you code against it then its going to work for the duration of the 2.x line. #3: but not changes considered "features". Now: 1. What if there is a feature that is also an API change? How is the definition of feature vs non-feature going to be taken up? 2. If there is already a change between 2.0.4-alpha and the forthcoming 2.0.5-beta which is visible at the API level then these will have to be backport that so that its behaviour remains consistent over time. 3 If those changes in (2) are part of a feature by (1), then is someone going to have to tease out the bits that will be declared "stable, API" and not "feature, unstable" Help me understand, -Steve Steve Loughran urn:uuid:%3cCADadbPE=wX8Yh0-E32e9SqU1gPXtzrnymTd7WU6Wm+v5N8m9yw@mail-gmail-com%3e Wed, 15 May 2013 00:50:48 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCA+4052mUhSYELTNUJMUQS-2Xdzv+gW2XW4j9i7QdE8tjBP6kiA@mail.gmail.com%3e Konst, On Tue, May 14, 2013 at 11:52 AM, Konstantin Shvachko wrote: > Sounds like you are having fun, Arun. > 2.0.5 is explicitly in the subject line for this vote. > No worries I'll fix that. > > You should stop assuming - it's in nobody interests - and start reading. > This sort of incivility is really not helping this conversation at all. I think your points might be better received if you were to avoid this sort of thing. I'm certainly sensitive to compatibility/stability concerns, but as it stands I'm having trouble separating your arguments from ad hominem comments. -- Aaron T. Myers Software Engineer, Cloudera "Aaron T. Myers" urn:uuid:%3cCA+4052mUhSYELTNUJMUQS-2Xdzv+gW2XW4j9i7QdE8tjBP6kiA@mail-gmail-com%3e Tue, 14 May 2013 21:39:23 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c25d2246e4fff94e35bde2a3eb830d871@mail.gmail.com%3e I thought I saw an email from Chris Douglas explaining why this vote may not be valid? What is the resolution? -----Original Message----- From: Arpit Gupta [mailto:arpit@hortonworks.com] Sent: Tuesday, May 14, 2013 1:54 PM To: general@hadoop.apache.org Subject: Re: [RESULT] Release plan for Hadoop 2.0.5 I was not aware that committers had binding vote on this. Can i still vote? Or can the vote be extended? -- Arpit Gupta Hortonworks Inc. http://hortonworks.com/ On May 14, 2013, at 1:15 PM, Vinod Kumar Vavilapalli wrote: > > The vote count is wrong: > > 6 binding +1s > 5 binding -1s > 4 non-binding +1s > 2 non-binding -1s. > > I think you mis-counted stevel, whose vote is binding. > > On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: > >> This vote passes with >> 6 binding +1s >> 4 non-binding +1 >> 4 binding -1 >> 3 non-binding -1 >> >> Thank you for voting, >> --Konstantin >> >> >> On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko >> wrote: >> >>> Please vote on the following plan for Hadoop release 2.0.5 >>> - bug fixes encountered in current release 2.0.4-alpha >>> - make all API changes to allow freezing them post 2.0.5 >>> - no new features >>> >>> As discussed on @dev thread >>> http://s.apache.org/fs >>> this will allow to stabilize 2.0 branch in a short and predictable >>> period of time. >>> This enables a powerful option to have the release tested at Yahoo scale. >>> The plan is to follow up with 2.1.0 - the stable release. >>> New features can and should be added on top of the stable release >>> once it is out. >>> >>> Hadoop by-laws: >>> http://hadoop.apache.org/bylaws.html >>> >>> "Release Plan >>> Defines the timetable and actions for a release. The plan also >>> nominates a Release Manager. >>> Lazy majority of active committers" >>> >>> assume nomination of a Release Manager with the plan. >>> It would be really good if Arun continues if this plan is adopted. >>> We can return to the RM topic if not. >>> >>> The vote will run for 7 days until next Wed, May 8th. >>> >>> Thanks, >>> --Konstantin >>> > Bikas Saha urn:uuid:%3c25d2246e4fff94e35bde2a3eb830d871@mail-gmail-com%3e Tue, 14 May 2013 20:59:23 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c07A3CD2A-CBB2-44BC-B967-08B7A6FDBB9C@hortonworks.com%3e I was not aware that committers had binding vote on this. Can i still vote? Or can the vote be extended? -- Arpit Gupta Hortonworks Inc. http://hortonworks.com/ On May 14, 2013, at 1:15 PM, Vinod Kumar Vavilapalli wrote: > > The vote count is wrong: > > 6 binding +1s > 5 binding -1s > 4 non-binding +1s > 2 non-binding -1s. > > I think you mis-counted stevel, whose vote is binding. > > On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: > >> This vote passes with >> 6 binding +1s >> 4 non-binding +1 >> 4 binding -1 >> 3 non-binding -1 >> >> Thank you for voting, >> --Konstantin >> >> >> On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko >> wrote: >> >>> Please vote on the following plan for Hadoop release 2.0.5 >>> - bug fixes encountered in current release 2.0.4-alpha >>> - make all API changes to allow freezing them post 2.0.5 >>> - no new features >>> >>> As discussed on @dev thread >>> http://s.apache.org/fs >>> this will allow to stabilize 2.0 branch in a short and predictable period >>> of time. >>> This enables a powerful option to have the release tested at Yahoo scale. >>> The plan is to follow up with 2.1.0 - the stable release. >>> New features can and should be added on top of the stable release once it >>> is out. >>> >>> Hadoop by-laws: >>> http://hadoop.apache.org/bylaws.html >>> >>> "Release Plan >>> Defines the timetable and actions for a release. The plan also nominates a >>> Release Manager. >>> Lazy majority of active committers" >>> >>> assume nomination of a Release Manager with the plan. >>> It would be really good if Arun continues if this plan is adopted. >>> We can return to the RM topic if not. >>> >>> The vote will run for 7 days until next Wed, May 8th. >>> >>> Thanks, >>> --Konstantin >>> > Arpit Gupta urn:uuid:%3c07A3CD2A-CBB2-44BC-B967-08B7A6FDBB9C@hortonworks-com%3e Tue, 14 May 2013 20:53:45 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cB32A08C5-F472-4823-A3CE-D2E13E4D7209@hortonworks.com%3e The vote count is wrong: 6 binding +1s 5 binding -1s 4 non-binding +1s 2 non-binding -1s. I think you mis-counted stevel, whose vote is binding. On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: > This vote passes with > 6 binding +1s > 4 non-binding +1 > 4 binding -1 > 3 non-binding -1 > > Thank you for voting, > --Konstantin > > > On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko > wrote: > >> Please vote on the following plan for Hadoop release 2.0.5 >> - bug fixes encountered in current release 2.0.4-alpha >> - make all API changes to allow freezing them post 2.0.5 >> - no new features >> >> As discussed on @dev thread >> http://s.apache.org/fs >> this will allow to stabilize 2.0 branch in a short and predictable period >> of time. >> This enables a powerful option to have the release tested at Yahoo scale. >> The plan is to follow up with 2.1.0 - the stable release. >> New features can and should be added on top of the stable release once it >> is out. >> >> Hadoop by-laws: >> http://hadoop.apache.org/bylaws.html >> >> "Release Plan >> Defines the timetable and actions for a release. The plan also nominates a >> Release Manager. >> Lazy majority of active committers" >> >> assume nomination of a Release Manager with the plan. >> It would be really good if Arun continues if this plan is adopted. >> We can return to the RM topic if not. >> >> The vote will run for 7 days until next Wed, May 8th. >> >> Thanks, >> --Konstantin >> Vinod Kumar Vavilapalli urn:uuid:%3cB32A08C5-F472-4823-A3CE-D2E13E4D7209@hortonworks-com%3e Tue, 14 May 2013 20:15:41 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutHk8_cUUj37LBHiHdGx3-6usf7PdD-nf8TL48G=XFtRCw@mail.gmail.com%3e Sounds like you are having fun, Arun. 2.0.5 is explicitly in the subject line for this vote. No worries I'll fix that. You should stop assuming - it's in nobody interests - and start reading. --Konst On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy wrote: > > On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: > > >> I can point you towards a set of fixes I think important for YARN > > (nodemanager, security etc.). > > > > That would be very much appreciated. > > > >> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. > > > > Thanks. > > > > Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. > > This way you can start with a clean slate. Good luck. > > As I noted before in the thread, the APIs in branch-2.0-alpha will remain > incompatible with branch-2. > > thanks, > Arun Konstantin Shvachko urn:uuid:%3cCAKtuutHk8_cUUj37LBHiHdGx3-6usf7PdD-nf8TL48G=XFtRCw@mail-gmail-com%3e Tue, 14 May 2013 18:52:28 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCDB7DB78.10B81%25evans@yahoo-inc.com%3e Chris, I realize that my metaphor was not perfect none are. I don't belive that .snapshots or any other features on the table are bad, not well tested, or have design flaws. I am just stating that any time thousands of lines of code are changed for any reason there will be bugs no matter who wrote it and no matter who tested it. We are all human and we will all miss something. I simply want to reduce the time frame between when code is written and when it is rolled out to be more fully tested. I see API stabilization as a critical piece of this, and would like to help the community get in a mindset where we are ready for rolling upgrades when they do come. If the community thinks that snapshots or some other feature should go in in the same time frame as API lockdown I am fine with that. It just means that for me to go to production with that code will in all likelihood take longer. I apologize if "junkyard" or "dumping ground" has offended anyone. It was not my intention to offend, I just wanted to describe what I have seen happening where a change does not go into branch-2 for some reason (possibly because of an incompatibility) and it will go into trunk. Historically it would then sit with little more than unit tests to find bugs. I personally don't see any reason for a patch to go into trunk and not branch-2 unless it breaks compatibility. And if it breaks compatibility why is it going into trunk? Is it really that difficult to maintain compatibility and add new features at the same time? Then if trunk and branch-2 are essentially identical why would we want to maintain two copies of the same thing? These are the questions that I struggle to find an answer to, and are part of the reason why I am in favor of Konstantin's proposal. Although I do agree with you Chris that we need more clarification in the roles involved with his release plan. --Bobby On 5/13/13 4:46 PM, "Chris Douglas" wrote: >Bobby- > >As much as I enjoy the Evel Knievel image, your argument is not >finding traction for lack of a visceral metaphor. It's the lack of >detail. We're not jumping buses, we're adding features to code, where >it's possible to be specific. If you're uncomfortable with the design, >implementation, or test plan of a feature, then share your >reservations. Either someone can reassure you that your issue is >covered by existing tests, they can add new tests, or- given enough >evidence- we can agree that the feature needs more time to bake before >being added to the beta. If you need extra time to do this, please >insist. Given all that's been written, I literally can't believe that >nobody has time to do this, and it would be a lot more productive. > >I share your concerns about trunk, abstractly. Currently, there's >almost nothing there that isn't in branch-2 (which makes metaphors >like "junkyard" and "dumping ground" sound a little hysterical, >frankly). Once 2.x reaches beta, we should probably explore rolling >new alpha releases to ensure it doesn't rot. > >On Sun, May 12, 2013 at 9:26 PM, Konstantin Shvachko > wrote: >> You keep twisting around the purpose of the vote and my position in it. >> As I said before: http://s.apache.org/WBf >> I am not against the features. And I am not blocking them. >> I propose to release them in a different than yours order, addressing >> features vs. stability tradeoff. > >It's possible we're confused. Your proposal sounds like Arun should RM >a release with a particular profile. I apologize if I assumed more >than you intended. > >> I don't know how to stop votes even if I wanted to. >> As Apache members you should have more vote-stopping power than me if >>you >> think it is against ASF norms. > >The content of releases isn't a power struggle. You have all the tools >and authority you need to create a release. Nobody has authority to >block you, and frankly, nobody is trying. However, your technical >input on the particular features would be most welcome. -C Robert Evans urn:uuid:%3cCDB7DB78-10B81%25evans@yahoo-inc-com%3e Tue, 14 May 2013 18:32:39 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCACO5Y4wZ2F1dnLjzypQb7bjfF=G778xKh5EhSd1-WWv=VRhpiA@mail.gmail.com%3e On Tue, May 14, 2013 at 11:10 AM, Arun C Murthy wrote: > As I noted before in the thread, the APIs in branch-2.0-alpha will remain incompatible with branch-2. +1 -C Chris Douglas urn:uuid:%3cCACO5Y4wZ2F1dnLjzypQb7bjfF=G778xKh5EhSd1-WWv=VRhpiA@mail-gmail-com%3e Tue, 14 May 2013 18:22:30 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c4EE9AF76-1592-4878-AB63-2C63A2D840F0@hortonworks.com%3e My understanding, as Konstantin agreed, is that 2.0.5 will now be called 2.1. He will focus on stabilizing 2.0.4-alpha even though API incompats remain. Arun On May 14, 2013, at 11:08 AM, Roman Shaposhnik wrote: > On Tue, May 14, 2013 at 10:40 AM, Arun C Murthy wrote: >> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. > > Not that it matters anymore (since Konstantin has tabulated the vote) but > I'd like to state for the record that this move: > 2.0.5-beta -> 2.1 > 2.0.5 now becoming Konstantin's stabilization release > takes care of my primary concern and I'm now +1 on the > proposal. > > I'll start a separate thread on what Bigtop should be focusing on. > > Thanks, > Roman. -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ Arun C Murthy urn:uuid:%3c4EE9AF76-1592-4878-AB63-2C63A2D840F0@hortonworks-com%3e Tue, 14 May 2013 18:12:01 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c334C393B-E9FE-4C04-A84A-AFB0F8D4D969@hortonworks.com%3e On May 14, 2013, at 11:04 AM, Konstantin Shvachko wrote: >> I can point you towards a set of fixes I think important for YARN > (nodemanager, security etc.). > > That would be very much appreciated. > >> I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. > > Thanks. > Thanks. I've copied branch-2.0.4-alpha as a new branch-2.0-alpha branch. This way you can start with a clean slate. Good luck. As I noted before in the thread, the APIs in branch-2.0-alpha will remain incompatible with branch-2. thanks, Arun Arun C Murthy urn:uuid:%3c334C393B-E9FE-4C04-A84A-AFB0F8D4D969@hortonworks-com%3e Tue, 14 May 2013 18:10:43 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCA+ULb+sUypLwYT4gTuEqTv+_HZC-OqX65+rdi37KER7xUEa32g@mail.gmail.com%3e On Tue, May 14, 2013 at 10:40 AM, Arun C Murthy wrote: > I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. Not that it matters anymore (since Konstantin has tabulated the vote) but I'd like to state for the record that this move: 2.0.5-beta -> 2.1 2.0.5 now becoming Konstantin's stabilization release takes care of my primary concern and I'm now +1 on the proposal. I'll start a separate thread on what Bigtop should be focusing on. Thanks, Roman. Roman Shaposhnik urn:uuid:%3cCA+ULb+sUypLwYT4gTuEqTv+_HZC-OqX65+rdi37KER7xUEa32g@mail-gmail-com%3e Tue, 14 May 2013 18:08:18 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3cCAKtuutGqbn8uYnOBMa3DjtWFBmSiJaJBZktvkHtK=tCGj2VHZA@mail.gmail.com%3e > I can point you towards a set of fixes I think important for YARN (nodemanager, security etc.). That would be very much appreciated. > I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. Thanks. On Tue, May 14, 2013 at 10:40 AM, Arun C Murthy wrote: > Konstantin, > > As others have noted it isn't clear what this vote was voting towards. > > If the plan is to make further stabilize 2.0.x (post 2.0.4) releases > while 2.1 becomes beta, you are welcome to do so. I can point you towards a > set of fixes I think important for YARN (nodemanager, security etc.). > > I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. > > thanks, > Arun > > On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: > > > This vote passes with > > 6 binding +1s > > 4 non-binding +1 > > 4 binding -1 > > 3 non-binding -1 > > > > Thank you for voting, > > --Konstantin > > > > > > On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko > > wrote: > > > >> Please vote on the following plan for Hadoop release 2.0.5 > >> - bug fixes encountered in current release 2.0.4-alpha > >> - make all API changes to allow freezing them post 2.0.5 > >> - no new features > >> > >> As discussed on @dev thread > >> http://s.apache.org/fs > >> this will allow to stabilize 2.0 branch in a short and predictable > period > >> of time. > >> This enables a powerful option to have the release tested at Yahoo > scale. > >> The plan is to follow up with 2.1.0 - the stable release. > >> New features can and should be added on top of the stable release once > it > >> is out. > >> > >> Hadoop by-laws: > >> http://hadoop.apache.org/bylaws.html > >> > >> "Release Plan > >> Defines the timetable and actions for a release. The plan also > nominates a > >> Release Manager. > >> Lazy majority of active committers" > >> > >> assume nomination of a Release Manager with the plan. > >> It would be really good if Arun continues if this plan is adopted. > >> We can return to the RM topic if not. > >> > >> The vote will run for 7 days until next Wed, May 8th. > >> > >> Thanks, > >> --Konstantin > >> > > -- > Arun C. Murthy > Hortonworks Inc. > http://hortonworks.com/ > > > Konstantin Shvachko urn:uuid:%3cCAKtuutGqbn8uYnOBMa3DjtWFBmSiJaJBZktvkHtK=tCGj2VHZA@mail-gmail-com%3e Tue, 14 May 2013 18:04:24 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c8BD71C17-70EC-4871-AA8E-D76145CE9D3E@hortonworks.com%3e Konstantin, As others have noted it isn't clear what this vote was voting towards. If the plan is to make further stabilize 2.0.x (post 2.0.4) releases while 2.1 becomes beta, you are welcome to do so. I can point you towards a set of fixes I think important for YARN (nodemanager, security etc.). I'll do the 2.1 series by renaming the planned 2.0.5 to 2.1. thanks, Arun On May 14, 2013, at 10:07 AM, Konstantin Shvachko wrote: > This vote passes with > 6 binding +1s > 4 non-binding +1 > 4 binding -1 > 3 non-binding -1 > > Thank you for voting, > --Konstantin > > > On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko > wrote: > >> Please vote on the following plan for Hadoop release 2.0.5 >> - bug fixes encountered in current release 2.0.4-alpha >> - make all API changes to allow freezing them post 2.0.5 >> - no new features >> >> As discussed on @dev thread >> http://s.apache.org/fs >> this will allow to stabilize 2.0 branch in a short and predictable period >> of time. >> This enables a powerful option to have the release tested at Yahoo scale. >> The plan is to follow up with 2.1.0 - the stable release. >> New features can and should be added on top of the stable release once it >> is out. >> >> Hadoop by-laws: >> http://hadoop.apache.org/bylaws.html >> >> "Release Plan >> Defines the timetable and actions for a release. The plan also nominates a >> Release Manager. >> Lazy majority of active committers" >> >> assume nomination of a Release Manager with the plan. >> It would be really good if Arun continues if this plan is adopted. >> We can return to the RM topic if not. >> >> The vote will run for 7 days until next Wed, May 8th. >> >> Thanks, >> --Konstantin >> -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/ Arun C Murthy urn:uuid:%3c8BD71C17-70EC-4871-AA8E-D76145CE9D3E@hortonworks-com%3e Tue, 14 May 2013 17:40:07 +0000 http://mail-archives.apache.org/mod_mbox/hadoop-general/201305.mbox/%3c20130514172632.GR1612@linspire.com%3e A follow up question: who is willing to step up as an RM for the release? I can reluctantly volunteer to carry on, unless someone wants to do it. Cos On Tue, May 14, 2013 at 10:07AM, Konstantin Shvachko wrote: > This vote passes with > 6 binding +1s > 4 non-binding +1 > 4 binding -1 > 3 non-binding -1 > > Thank you for voting, > --Konstantin > > > On Wed, May 1, 2013 at 12:53 PM, Konstantin Shvachko > wrote: > > > Please vote on the following plan for Hadoop release 2.0.5 > > - bug fixes encountered in current release 2.0.4-alpha > > - make all API changes to allow freezing them post 2.0.5 > > - no new features > > > > As discussed on @dev thread > > http://s.apache.org/fs > > this will allow to stabilize 2.0 branch in a short and predictable period > > of time. > > This enables a powerful option to have the release tested at Yahoo scale. > > The plan is to follow up with 2.1.0 - the stable release. > > New features can and should be added on top of the stable release once it > > is out. > > > > Hadoop by-laws: > > http://hadoop.apache.org/bylaws.html > > > > "Release Plan > > Defines the timetable and actions for a release. The plan also nominates a > > Release Manager. > > Lazy majority of active committers" > > > > assume nomination of a Release Manager with the plan. > > It would be really good if Arun continues if this plan is adopted. > > We can return to the RM topic if not. > > > > The vote will run for 7 days until next Wed, May 8th. > > > > Thanks, > > --Konstantin > > Konstantin Boudnik urn:uuid:%3c20130514172632-GR1612@linspire-com%3e Tue, 14 May 2013 17:26:32 +0000