Re: [VOTE] - Release 2.0.5-beta
+1 on 2.0.5 defined in this thread with the new features. But I am supportive of an earlier release that has ALL the compatibility changes, without the features. sanjay On May 15, 2013, at 10:57 AM, Arun C Murthy wrote: Folks, ... 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
Re: [VOTE] - Release 2.0.5-beta
-1 for the record. This is a great plan for 2.1, which I would gladly support, but not for 2.0.5. I do not see how the previous vote could have been confusing, as it contained a direct quotation of the relative clause of Bylaws. Arun, the format of this vote remains confusing. What is the action and what approval method you plan to use is still undefined. Thanks, --Konstantin On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc. IMHO technical arguments (incompatibility b/w 2.0 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as seizing the moment. There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention. To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration. I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content: # HDFS-347 # HDFS Snapshots # Windows support # Necessary final API/protocol changes such as: * Final YARN API changes: YARN-386 * MR Binary Compatibility: MAPREDUCE-5108 * Final RPC cleanup: HADOOP-8990 People working on the above features have all expressed considerable comfort with them and are ready to stand-by to help expedite any necessary bug-fixes etc. to get to stabilization quickly. I'm confident we can get this release out by end of May. This sets stage for a hadoop-2.x GA release right after with some more testing - this means I think I can quickly turn around and make bug-fix releases as necessary right after 2.0.5-beta. I request that people consider helping out with this plan and sign up to help push hadoop-2.x to stability as outlined above. I believe this will help achieve our shared goals of quickly stabilizing hadoop-2 and help ensure we can support it for forseeable future in a compatible manner for the benefit of our users and downstream projects. Please vote, the vote will run the normal 7 days. Obviously, I'm +1. thanks, Arun PS: To keep this discussion grounded in technical details I've moved this to dev@ (bcc general@).
Re: [VOTE] - Release 2.0.5-beta
Chris, I find you are contradicting yourself within this message and with some other of yours. But I want to address only one thing here This has exposed a bug in our bylaws, which we can fix. This could be a bug, and we may need to fix it. But until then it is a bylaw, which is the only rule we have to come to an agreement if we disagree. If we both respect the rules we can come to an agreement. If not and people start forcing their way by saying the rule is wrong - let's ignore it today, or by conducting an infinite chain of counter votes - this creates chaos. Thanks, --Konstantin On Sat, May 18, 2013 at 4:22 PM, Chris Douglas cdoug...@apache.org wrote: The release plan vote is not binding in any way. Nobody lost a vote, or risks having an outcome reversed, because there are no consequences to these exercises. Konstantin, I've been trying to tell you for more than a week that you can go forward without anyone's blessing or consent. There are no precedents, because the release plan vote has been a formality until now, and I don't know of any other projects that even bother with it. Most of our committers and PMC members didn't even know who was eligible to vote on it, because we usually ignore it. What *does* matter is the majority vote of the PMC on the release artifact. While we under-defined what the release plan means, we have zero ambiguity on when a release artifact becomes real. In the discussion, you were offered a minor release series, help selecting patches from branch-2, and every administrative barrier was removed from your path. Instead of taking this and running with it, you continued to press for... I don't know what. Please decide how you're going to move a development branch- any of them- forward and start working on it. There is nothing to win in these threads. This has exposed a bug in our bylaws, which we can fix. Right now, these votes are confusing everybody and stalling the project. I don't care who comes up with 2.0.5-beta, whether it's part of 2.1, or if we create 3.0. Any committer who wants to offer an candidate needs to demonstrate that they have a non-trivial, non-sectarian proportion of the community behind it by (1) creating the artifact (2) passing a PMC vote to make that artifact a release. It's that simple. With respect to the board: they are not parents, and we are not children. Neither are they interested or equipped to tell us how to partition releases of Hadoop. This is routine development, we are failing at it, but we will recover by eliminating this pointless ritual and getting back to producing software. -C On Fri, May 17, 2013 at 1:10 PM, Konstantin Shvachko shv.had...@gmail.com wrote: BCC: general@ Since we recognize now that this is a vote to overrule previous decision, I am referring to Vinod's note on general *http://s.apache.org/h7x* should this be brought to the attention of the Board? I don't remember any precedents of this kind in Hadoop history. But other projects may have had such experience. A clarification on categorizing this action and on voting practices from ASF may help. Thanks, --Konstantin On Wed, May 15, 2013 at 3:36 PM, Konstantin Shvachko shv.had...@gmail.comwrote: Arun, I am glad I at least convinced you to finally announce your release plan and put it into vote. Even though it is to overrule the vote that just completed, which you were against and lost, well - Twice. I am glad you removed the NFS feature from the list proposed earlier. I think this vote is late. The lazy consensus on that issue has been just reached. I don't see the basis for the new vote, and it is not clear what action you seek to approve. Thanks, --Konstantin On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc. IMHO technical arguments (incompatibility b/w 2.0 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as seizing the moment. There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's
[jira] [Created] (HADOOP-9583) test-patch gives +1 despite build failure when running tests
Jason Lowe created HADOOP-9583: -- Summary: test-patch gives +1 despite build failure when running tests Key: HADOOP-9583 URL: https://issues.apache.org/jira/browse/HADOOP-9583 Project: Hadoop Common Issue Type: Bug Affects Versions: 3.0.0 Reporter: Jason Lowe Priority: Critical I've seen a couple of checkins recently where tests have timed out resulting in a Maven build failure yet test-patch reports an overall +1 on the patch. This is encouraging commits of patches that subsequently break builds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Where should we host Hadoop FileSystem plugins for 3rd Party FileSystems?
Hi Folks My name is Steve Watt and I am presently working on enabling glusterfs to be used as a Hadoop FileSystem. Most of the work thus far has involved developing a Hadoop FileSystem plugin for glusterfs. I'm getting to the point where the plugin is becoming stable and I've been trying to understand where the right place is to host/manage/version it. Steve Loughran was kind enough to point out a few past threads in the community (http://lucene.472066.n3.nabble.com/Need-to-add-fs-shim-to-use-QFS-td4012118.html) that show a disposition to move away from Hadoop Common containing client code (plugins) for 3rd party FileSystems. This makes sense and allows the filesystem plugin developer more autonomy as well as reduces Hadoop Common's dependence on 3rd Party libraries. I'm easy either way. I just wanted to verify that the community's preference is still to have client code for 3rd Party FileSystems hosted and managed outside of Hadoop Common before I take that direction. Regards Steve Watt
[jira] [Created] (HADOOP-9584) fix findbugs warnings
Giridharan Kesavan created HADOOP-9584: -- Summary: fix findbugs warnings Key: HADOOP-9584 URL: https://issues.apache.org/jira/browse/HADOOP-9584 Project: Hadoop Common Issue Type: Bug Affects Versions: 1.3.0 Reporter: Giridharan Kesavan https://builds.apache.org/job/Hadoop-branch1/94/findbugsResult/ this url shows about 203 findbugs warnings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9585) unit test failure :org.apache.hadoop.fs.TestFsShellReturnCode.testChgrp
Giridharan Kesavan created HADOOP-9585: -- Summary: unit test failure :org.apache.hadoop.fs.TestFsShellReturnCode.testChgrp Key: HADOOP-9585 URL: https://issues.apache.org/jira/browse/HADOOP-9585 Project: Hadoop Common Issue Type: Bug Components: test Affects Versions: 1.3.0 Environment: https://builds.apache.org/job/Hadoop-branch1/lastCompletedBuild/testReport/org.apache.hadoop.fs/TestFsShellReturnCode/testChgrp/ Reporter: Giridharan Kesavan Standard Error chmod: could not get status for '/home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChmod/fileDoesNotExist': File /home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChmod/fileDoesNotExist does not exist. chmod: could not get status for '/home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChmod/nonExistingfiles*' chown: could not get status for '/home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChown/fileDoesNotExist': File /home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChown/fileDoesNotExist does not exist. chown: could not get status for '/home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChown/nonExistingfiles*' chgrp: failed on 'file:/home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChgrp/fileExists': chgrp: changing group of `/home/jenkins/jenkins-slave/workspace/Hadoop-branch1/trunk/build/test/data/testChgrp/fileExists': Operation not permitted -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9586) unit test failure: org.apache.hadoop.hdfs.TestFileCreation.testFileCreationSetLocalInterface
Giridharan Kesavan created HADOOP-9586: -- Summary: unit test failure: org.apache.hadoop.hdfs.TestFileCreation.testFileCreationSetLocalInterface Key: HADOOP-9586 URL: https://issues.apache.org/jira/browse/HADOOP-9586 Project: Hadoop Common Issue Type: Bug Components: test Affects Versions: 1.3.0 Reporter: Giridharan Kesavan https://builds.apache.org/job/Hadoop-branch1/lastCompletedBuild/testReport/org.apache.hadoop.hdfs/TestFileCreation/testFileCreationSetLocalInterface/ org.apache.hadoop.ipc.RemoteException: java.io.IOException: File /user/jenkins/filestatus.dat could only be replicated to 0 nodes, instead of 1 at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getAdditionalBlock(FSNamesystem.java:1920) at org.apache.hadoop.hdfs.server.namenode.NameNode.addBlock(NameNode.java:783) at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:587) at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1432) at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1428) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:396) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1190) at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1426) at org.apache.hadoop.ipc.Client.call(Client.java:1107) at org.apache.hadoop.ipc.RPC$Invoker.invoke(RPC.java:229) at $Proxy5.addBlock(Unknown Source) at org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:85) at org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:62) at $Proxy5.addBlock(Unknown Source) at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.locateFollowingBlock(DFSClient.java:3720) at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.nextBlockOutputStream(DFSClient.java:3580) at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream.access$2600(DFSClient.java:2783) at org.apache.hadoop.hdfs.DFSClient$DFSOutputStream$DataStreamer.run(DFSClient.java:3023) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9587) unit test failure: org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup.testBalancerWithRackLocality
Giridharan Kesavan created HADOOP-9587: -- Summary: unit test failure: org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup.testBalancerWithRackLocality Key: HADOOP-9587 URL: https://issues.apache.org/jira/browse/HADOOP-9587 Project: Hadoop Common Issue Type: Bug Components: test Affects Versions: 1.3.0 Environment: https://builds.apache.org/job/Hadoop-branch1/lastCompletedBuild/testReport/org.apache.hadoop.hdfs.server.balancer/TestBalancerWithNodeGroup/testBalancerWithRackLocality/ Reporter: Giridharan Kesavan Error Message Rebalancing expected avg utilization to become 0.2, but on datanode 127.0.0.1:34261 it remains at 0.08 after more than 2 msec. Stacktrace at org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup.waitForBalancer(TestBalancerWithNodeGroup.java:165) at org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup.runBalancer(TestBalancerWithNodeGroup.java:195) at org.apache.hadoop.hdfs.server.balancer.TestBalancerWithNodeGroup.testBalancerWithRackLocality(TestBalancerWithNodeGroup.java:297) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [VOTE] - Release 2.0.5-beta
I've now started a separate discussion thread in common-dev@, titled [PROPOSAL] change in bylaws to remove Release Plan vote. If it achieves consensus, I'll put it to a vote to so change the bylaws. Best, --Matt On Sat, May 18, 2013 at 4:22 PM, Chris Douglas cdoug...@apache.org wrote: The release plan vote is not binding in any way. Nobody lost a vote, or risks having an outcome reversed, because there are no consequences to these exercises. Konstantin, I've been trying to tell you for more than a week that you can go forward without anyone's blessing or consent. There are no precedents, because the release plan vote has been a formality until now, and I don't know of any other projects that even bother with it. Most of our committers and PMC members didn't even know who was eligible to vote on it, because we usually ignore it. What *does* matter is the majority vote of the PMC on the release artifact. While we under-defined what the release plan means, we have zero ambiguity on when a release artifact becomes real. In the discussion, you were offered a minor release series, help selecting patches from branch-2, and every administrative barrier was removed from your path. Instead of taking this and running with it, you continued to press for... I don't know what. Please decide how you're going to move a development branch- any of them- forward and start working on it. There is nothing to win in these threads. This has exposed a bug in our bylaws, which we can fix. Right now, these votes are confusing everybody and stalling the project. I don't care who comes up with 2.0.5-beta, whether it's part of 2.1, or if we create 3.0. Any committer who wants to offer an candidate needs to demonstrate that they have a non-trivial, non-sectarian proportion of the community behind it by (1) creating the artifact (2) passing a PMC vote to make that artifact a release. It's that simple. With respect to the board: they are not parents, and we are not children. Neither are they interested or equipped to tell us how to partition releases of Hadoop. This is routine development, we are failing at it, but we will recover by eliminating this pointless ritual and getting back to producing software. -C On Fri, May 17, 2013 at 1:10 PM, Konstantin Shvachko shv.had...@gmail.com wrote: BCC: general@ Since we recognize now that this is a vote to overrule previous decision, I am referring to Vinod's note on general *http://s.apache.org/h7x* should this be brought to the attention of the Board? I don't remember any precedents of this kind in Hadoop history. But other projects may have had such experience. A clarification on categorizing this action and on voting practices from ASF may help. Thanks, --Konstantin On Wed, May 15, 2013 at 3:36 PM, Konstantin Shvachko shv.had...@gmail.comwrote: Arun, I am glad I at least convinced you to finally announce your release plan and put it into vote. Even though it is to overrule the vote that just completed, which you were against and lost, well - Twice. I am glad you removed the NFS feature from the list proposed earlier. I think this vote is late. The lazy consensus on that issue has been just reached. I don't see the basis for the new vote, and it is not clear what action you seek to approve. Thanks, --Konstantin On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy a...@hortonworks.com wrote: Folks, A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc. IMHO technical arguments (incompatibility b/w 2.0 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as seizing the moment. There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention. To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration. I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content: # HDFS-347 # HDFS Snapshots # Windows support # Necessary final API/protocol changes such as: * Final YARN API changes: YARN-386
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+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.mattm...@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 ma...@apache.org Reply-To: common-dev@hadoop.apache.org common-dev@hadoop.apache.org, ma...@apache.org ma...@apache.org Date: Tuesday, May 21, 2013 2:10 PM To: common-dev@hadoop.apache.org 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary herehttp://incubator.apache.org/guides/releasemanagement.html#best-practi 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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)
[jira] [Created] (HADOOP-9589) Extra master key is created when AbstractDelegationTokenSecretManager is started
Jian He created HADOOP-9589: --- Summary: Extra master key is created when AbstractDelegationTokenSecretManager is started Key: HADOOP-9589 URL: https://issues.apache.org/jira/browse/HADOOP-9589 Project: Hadoop Common Issue Type: Bug Reporter: Jian He Assignee: Jian He When AbstractDelegationTokenSecretManager starts , AbstractDelegationTokenSecretManager.startThreads().updateCurrentKey() creates the first master key. Immediately after that, ExpiredTokenRemover thread is started, and it will creates the second master by calling rollMasterKey on its first loop. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 Thanks for taking care of this, Matt. -C On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary herehttp://incubator.apache.org/guides/releasemanagement.html#best-practice) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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)
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 I've always found the Release Plan votes a bit bizarre, and the fact that we've gone through many releases that did not have a corresponding Release Plan vote suggest to me that we should just scrap them. -- Aaron T. Myers Software Engineer, Cloudera On Tue, May 21, 2013 at 5:37 PM, Chris Douglas cdoug...@apache.org wrote: +1 Thanks for taking care of this, Matt. -C On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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)
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 On Tue, May 21, 2013 at 2:48 PM, Suresh Srinivas sur...@hortonworks.comwrote: +1 On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/ -- Alejandro
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 -Giri On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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)
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 -- Arpit Gupta Hortonworks Inc. http://hortonworks.com/ On May 21, 2013, at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary herehttp://incubator.apache.org/guides/releasemanagement.html#best-practice) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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)
RE: [PROPOSAL] change in bylaws to remove Release Plan vote
I see one significant benefit to having Release Plan votes: Fewer releases with more members of the community working on any given release. In turn, fewer Hadoop releases implies less confusion for end users attempting to download and use an Apache Hadoop release. If there are a dozen different releases of Apache Hadoop available for download at the Apache Hadoop website, end users will go to a commercial vendor packaged version of Hadoop. That is not good for the Apache Hadoop community as a whole. Jagane
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1, thanks for taking the initiative on this Matt. On May 21, 2013, at 2:10 PM, Matt Foley wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary herehttp://incubator.apache.org/guides/releasemanagement.html#best-practice) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- Arun C. Murthy Hortonworks Inc. http://hortonworks.com/
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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)
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 (non-binding) On Tue, May 21, 2013 at 4:02 PM, Eli Collins e...@cloudera.com wrote: +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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)
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 On Tue, May 21, 2013 at 4:02 PM, Eli Collins e...@cloudera.com wrote: +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1 (non-binding) On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey jiten...@hortonworks.comwrote: +1 On Tue, May 21, 2013 at 4:02 PM, Eli Collins e...@cloudera.com wrote: +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
+1. thanks mahadev On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla ka...@cloudera.com wrote: +1 (non-binding) On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey jiten...@hortonworks.comwrote: +1 On Tue, May 21, 2013 at 4:02 PM, Eli Collins e...@cloudera.com wrote: +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
13/14 +1's. I think that constitutes consensus. Moving this to a VOTE thread. Please repeat your +1s :-) Cheers, --Matt On Tue, May 21, 2013 at 5:33 PM, Mahadev Konar maha...@hortonworks.comwrote: +1. thanks mahadev On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla ka...@cloudera.com wrote: +1 (non-binding) On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey jiten...@hortonworks.comwrote: +1 On Tue, May 21, 2013 at 4:02 PM, Eli Collins e...@cloudera.com wrote: +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
Why repeat just tally new ones? Sent from my iPhone On May 21, 2013, at 6:58 PM, Matt Foley ma...@apache.org wrote: 13/14 +1's. I think that constitutes consensus. Moving this to a VOTE thread. Please repeat your +1s :-) Cheers, --Matt On Tue, May 21, 2013 at 5:33 PM, Mahadev Konar maha...@hortonworks.comwrote: +1. thanks mahadev On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla ka...@cloudera.com wrote: +1 (non-binding) On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey jiten...@hortonworks.comwrote: +1 On Tue, May 21, 2013 at 4:02 PM, Eli Collins e...@cloudera.com wrote: +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
Ok, if no one complains I will phrase the vote to include +1's explicitly cast in the discussion thread. --Matt On Tue, May 21, 2013 at 6:58 PM, Mattmann, Chris A (398J) chris.a.mattm...@jpl.nasa.gov wrote: Why repeat just tally new ones? Sent from my iPhone On May 21, 2013, at 6:58 PM, Matt Foley ma...@apache.org wrote: 13/14 +1's. I think that constitutes consensus. Moving this to a VOTE thread. Please repeat your +1s :-) Cheers, --Matt On Tue, May 21, 2013 at 5:33 PM, Mahadev Konar maha...@hortonworks.com wrote: +1. thanks mahadev On Tue, May 21, 2013 at 4:48 PM, Karthik Kambatla ka...@cloudera.com wrote: +1 (non-binding) On Tue, May 21, 2013 at 4:13 PM, Jitendra Pandey jiten...@hortonworks.comwrote: +1 On Tue, May 21, 2013 at 4:02 PM, Eli Collins e...@cloudera.com wrote: +1 thanks Matt. On Tue, May 21, 2013 at 2:10 PM, Matt Foley ma...@apache.org wrote: 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 http://www.apache.org/dev/release.html and here http://www.apache.org/foundation/voting.html, with non-normative commentary here http://incubator.apache.org/guides/releasemanagement.html#best-practice ) 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 Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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) -- http://hortonworks.com/download/
[VOTE] change in bylaws to remove Release Plan vote
This was previously discussed in the thread [PROPOSAL] change in bylaws to remove Release Plan vote. 13 people explicitly cast +1s in that thread. Absent objection I will count those as votes without requiring them to (re-)respond to this VOTE thread. The following change is proposed in the Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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. === Best regards, --Matt (long-time release manager)
Re: [PROPOSAL] change in bylaws to remove Release Plan vote
Hi Jagane, since you did not explicitly cast a -1 or other numerical vote, please if you wish go ahead and cast a vote in the VOTE thread. Best regards, --Matt On Tue, May 21, 2013 at 3:47 PM, Jagane Sundar jag...@sundar.org wrote: I see one significant benefit to having Release Plan votes: Fewer releases with more members of the community working on any given release. In turn, fewer Hadoop releases implies less confusion for end users attempting to download and use an Apache Hadoop release. If there are a dozen different releases of Apache Hadoop available for download at the Apache Hadoop website, end users will go to a commercial vendor packaged version of Hadoop. That is not good for the Apache Hadoop community as a whole. Jagane
Re: [VOTE] change in bylaws to remove Release Plan vote
+1. -- Hitesh On May 21, 2013, at 7:03 PM, Matt Foley wrote: This was previously discussed in the thread [PROPOSAL] change in bylaws to remove Release Plan vote. 13 people explicitly cast +1s in that thread. Absent objection I will count those as votes without requiring them to (re-)respond to this VOTE thread. The following change is proposed in the Bylawshttp://hadoop.apache.org/bylaws.html 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 HowToReleasehttps://wiki.apache.org/hadoop/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. === Best regards, --Matt (long-time release manager)
[jira] [Created] (HADOOP-9590) Move to JDK7 improved APIs for file operations when available
Ivan Mitic created HADOOP-9590: -- Summary: Move to JDK7 improved APIs for file operations when available Key: HADOOP-9590 URL: https://issues.apache.org/jira/browse/HADOOP-9590 Project: Hadoop Common Issue Type: Improvement Reporter: Ivan Mitic JDK6 does not have a complete support for local file system file operations. Specifically: - JDK6 does not provide symlink/hardlink APIs what forced Hadoop to defer to shell based tooling - JDK6 does not return any useful error information when File#mkdir/mkdirs or File#renameTo fails making it unnecessary hard to troubleshoot some issues - JDK6 File#canRead/canWrite/canExecute do not perform any access checks on Windows making APIs inconsistent with the Unix behavior - JDK6 File#setReadable/setWritable/setExecutable do not change access rights on Windows making APIs inconsistent with the Unix behavior - JDK6 File#length does not work as expected on symlinks on Windows - JDK6 File#renameTo does not work as expected on symlinks on Windows All above resulted in Hadoop community having to fill in the gaps by providing equivalent native implementations or applying workarounds. JDK7 addressed (as far as I know) all (or most) of the above problems, either thru the newly introduced [Files|http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html] class or thru bug fixes. This is a tracking Jira to revisit above mediations once JDK7 becomes the supported platform by the Hadoop community. This work would allow significant portion of the native platform-dependent code to be replaced with Java equivalents what is goodness w.r.t. Hadoop cross-platform support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (HADOOP-9591) Hadoop SnappyCodec (incorrectly?) uses block compression
Uri Laserson created HADOOP-9591: Summary: Hadoop SnappyCodec (incorrectly?) uses block compression Key: HADOOP-9591 URL: https://issues.apache.org/jira/browse/HADOOP-9591 Project: Hadoop Common Issue Type: Bug Components: io Reporter: Uri Laserson org.apache.hadoop.io.compress.SnappyCodec ends up calling BlockCompressorStream and BlockDecompressorStream. However, this really takes in the SequenceFile abstraction unnecessarily, as it wraps chunks of Snappy-compressed data with extra metainformation. It's also not documented that this Snappy coded uses block compression. This has turned out to be a problem with Parquet-MR, since it uses this SnappyCodec to compress its pages, but rather than just Snappy-compressed data, it's Snappy-compressed wrapped in extra data. So tools that just expect regular Snappy compression break (e.g., Impala). There should be another codec added that uses CompressorStream instead. Here is a rough outline, though I'm not sure how to correctly test for whether the Snappy libs are present wrt backwards compatibility. https://github.com/laserson/parquet-mr/blob/raw_snappy/parquet-hadoop/src/main/java/parquet/hadoop/util/RawSnappyCodec.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
