On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> All,>> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would> like to release.>> This is a stabilization release that includes fixed for a couple a of issues> discovered in the testing with BigTop 0.6.0 release candidate.>> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0>> The maven artifacts are available via repository.apache.org.>> Please try the release bits and vote; the vote will run for the usual 7 days.

+1 (non-binding).

Built complete Bigtop distribution on top of the proposed RC, ran integrationtests on Bigtop jenkins for both secure and unsecure deployments. RanScoop 2 tests.

Hence, there's a good chance that it never will be backported. And I don'thave any plans to created 'a release per patch'.

> Also, this is the first time we are seeing a four-numbered scheme in Hadoop.> Why not call this 2.0.5-alpha?

There were precedents in four-numbered schemes before: 0.20.20[3-5].0 comes tomind.

As for 2.0.5-alpha: The release numbering games and votes that had happened inthe last few weeks are very confusing. Some of them never been concluded, thebranches are moved and artifact versions seem to be colliding. 2.0.4.x seemsto work well for the stabilization purposes and it will allow to unblockdownstream and integration projects quickly.

Cos

> Arun> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> > > All,> > > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would> > like to release.> > > > This is a stabilization release that includes fixed for a couple a of issues> > discovered in the testing with BigTop 0.6.0 release candidate.> > > > The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> > The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0> > > > The maven artifacts are available via repository.apache.org.> > > > Please try the release bits and vote; the vote will run for the usual 7 days.> > > > Thanks for your voting> > Cos> > > >

Hi Cos,I would also request that you renumber the release candidate to justthree-numbers, hence "2.0.5-alpha".

Arun, are you willing to start the 2.1.x name-space for your next release,so that 2.0.x-alpha can become an intermediate stabilization branch as Cosand Konst want?

I just think that using four-number schemes was symptomatic of thenear-forking we had back in the 0.20.xxx.y days, and I really don't want togo back there. Especially since you could say that "0.20.xxx.y" is justthree significant numbers, the leading zero being inconsequential.

> On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:> > I see you just re-opened MAPREUDCE-5211.> >> > Why not include MAPREDUCE-5211 as well rather than create one release> per patch?>> Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per>> https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574>> Hence, there's a good chance that it never will be backported. And I don't> have any plans to created 'a release per patch'.>> > Also, this is the first time we are seeing a four-numbered scheme in> Hadoop.> > Why not call this 2.0.5-alpha?>> There were precedents in four-numbered schemes before: 0.20.20[3-5].0> comes to> mind.>> As for 2.0.5-alpha: The release numbering games and votes that had> happened in> the last few weeks are very confusing. Some of them never been concluded,> the> branches are moved and artifact versions seem to be colliding. 2.0.4.x> seems> to work well for the stabilization purposes and it will allow to unblock> downstream and integration projects quickly.>> Cos>> > Arun> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> >> > > All,> > >> > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that> I would> > > like to release.> > >> > > This is a stabilization release that includes fixed for a couple a of> issues> > > discovered in the testing with BigTop 0.6.0 release candidate.> > >> > > The RC is available at:> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> > > The RC tag in svn is here:> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0> > >> > > The maven artifacts are available via repository.apache.org.> > >> > > Please try the release bits and vote; the vote will run for the usual> 7 days.> > >> > > Thanks for your voting> > > Cos> > >> >> >>

On Thu, May 30, 2013 at 03:11PM, Matt Foley wrote:> Hi Cos,> I would also request that you renumber the release candidate to just> three-numbers, hence "2.0.5-alpha".> > Arun, are you willing to start the 2.1.x name-space for your next release,> so that 2.0.x-alpha can become an intermediate stabilization branch as Cos> and Konst want?

Let's get the facts straight, Matt, please: this "want" has been expressed inthe official vote here http://s.apache.org/ZMf Apparently, 2.0.5-alpha isblocked now because of the another vote that hasn't been closed yet forwhatever reason. In order to unblock a number of releases in downstreamcomponent I have moved forward with this release. Do you have any materialobjections to the release that pursue this goal?

> I just think that using four-number schemes was symptomatic of the> near-forking we had back in the 0.20.xxx.y days, and I really don't want to> go back there. Especially since you could say that "0.20.xxx.y" is just> three significant numbers, the leading zero being inconsequential.

I dare to remind that forth part of the version is reserved - not in aparallel universe, of course - for "patch level" aka bug fixes. It hardly canbe taken a sign of 'forking' by any definition.

Cos

> So, would you please consider using 2.0.5-alpha?> > As for the "2.0.5-SNAPSHOT" in the branch-2 versioning, that's standard> usage. Whoever makes the 2.0.5 release (or any "next" release) is expected> to update the parent branch's SNAPSHOT default versioning, per> HowToReleasePostMavenization#Branching<https://wiki.apache.org/hadoop/HowToReleasePostMavenization#Branching>,> step 6.> > Thanks,> --Matt> > > On Thu, May 30, 2013 at 11:52 AM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> > > On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:> > > I see you just re-opened MAPREUDCE-5211.> > >> > > Why not include MAPREDUCE-5211 as well rather than create one release> > per patch?> >> > Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per> >> > https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574> >> > Hence, there's a good chance that it never will be backported. And I don't> > have any plans to created 'a release per patch'.> >> > > Also, this is the first time we are seeing a four-numbered scheme in> > Hadoop.> > > Why not call this 2.0.5-alpha?> >> > There were precedents in four-numbered schemes before: 0.20.20[3-5].0> > comes to> > mind.> >> > As for 2.0.5-alpha: The release numbering games and votes that had> > happened in> > the last few weeks are very confusing. Some of them never been concluded,> > the> > branches are moved and artifact versions seem to be colliding. 2.0.4.x> > seems> > to work well for the stabilization purposes and it will allow to unblock> > downstream and integration projects quickly.> >> > Cos> >> > > Arun> > >> > > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> > >> > > > All,> > > >> > > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that> > I would> > > > like to release.> > > >> > > > This is a stabilization release that includes fixed for a couple a of> > issues> > > > discovered in the testing with BigTop 0.6.0 release candidate.> > > >> > > > The RC is available at:> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> > > > The RC tag in svn is here:> > http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0> > > >> > > > The maven artifacts are available via repository.apache.org.> > > >> > > > Please try the release bits and vote; the vote will run for the usual> > 7 days.> > > >> > > > Thanks for your voting> > > > Cos> > > >> > >> > >> >

0.17.2 was missing some native libs so 0.17.2.1 was released to fixthat critical issue instead of calling it .3

J-D

On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> On Thu, May 30, 2013 at 03:11PM, Matt Foley wrote:>> Hi Cos,>> I would also request that you renumber the release candidate to just>> three-numbers, hence "2.0.5-alpha".>>>> Arun, are you willing to start the 2.1.x name-space for your next release,>> so that 2.0.x-alpha can become an intermediate stabilization branch as Cos>> and Konst want?>> Let's get the facts straight, Matt, please: this "want" has been expressed in> the official vote here http://s.apache.org/ZMf Apparently, 2.0.5-alpha is> blocked now because of the another vote that hasn't been closed yet for> whatever reason. In order to unblock a number of releases in downstream> component I have moved forward with this release. Do you have any material> objections to the release that pursue this goal?>>> I just think that using four-number schemes was symptomatic of the>> near-forking we had back in the 0.20.xxx.y days, and I really don't want to>> go back there. Especially since you could say that "0.20.xxx.y" is just>> three significant numbers, the leading zero being inconsequential.>> I dare to remind that forth part of the version is reserved - not in a> parallel universe, of course - for "patch level" aka bug fixes. It hardly can> be taken a sign of 'forking' by any definition.>> Cos>>> So, would you please consider using 2.0.5-alpha?>>>> As for the "2.0.5-SNAPSHOT" in the branch-2 versioning, that's standard>> usage. Whoever makes the 2.0.5 release (or any "next" release) is expected>> to update the parent branch's SNAPSHOT default versioning, per>> HowToReleasePostMavenization#Branching<https://wiki.apache.org/hadoop/HowToReleasePostMavenization#Branching>,>> step 6.>>>> Thanks,>> --Matt>>>>>> On Thu, May 30, 2013 at 11:52 AM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:>>>> > On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:>> > > I see you just re-opened MAPREUDCE-5211.>> > >>> > > Why not include MAPREDUCE-5211 as well rather than create one release>> > per patch?>> >>> > Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per>> >>> > https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574>> >>> > Hence, there's a good chance that it never will be backported. And I don't>> > have any plans to created 'a release per patch'.>> >>> > > Also, this is the first time we are seeing a four-numbered scheme in>> > Hadoop.>> > > Why not call this 2.0.5-alpha?>> >>> > There were precedents in four-numbered schemes before: 0.20.20[3-5].0>> > comes to>> > mind.>> >>> > As for 2.0.5-alpha: The release numbering games and votes that had>> > happened in>> > the last few weeks are very confusing. Some of them never been concluded,>> > the>> > branches are moved and artifact versions seem to be colliding. 2.0.4.x>> > seems>> > to work well for the stabilization purposes and it will allow to unblock>> > downstream and integration projects quickly.>> >>> > Cos>> >>> > > Arun>> > >>> > > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:>> > >>> > > > All,>> > > >>> > > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that>> > I would>> > > > like to release.>> > > >>> > > > This is a stabilization release that includes fixed for a couple a of>> > issues>> > > > discovered in the testing with BigTop 0.6.0 release candidate.>> > > >>> > > > The RC is available at:>> > http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/>> > > > The RC tag in svn is here:

On Thu, May 30, 2013 at 04:08PM, Jean-Daniel Cryans wrote:> FWIW, not that I have a dog in this fight, but the only release with a> 4th number (not including .0 like the 0.20.20x releases did) we had> was:> > http://hadoop.6.n7.nabble.com/VOTE-Release-0-17-2-1-rc-0-td13398.html> > 0.17.2 was missing some native libs so 0.17.2.1 was released to fix> that critical issue instead of calling it .3

Exactly the point - the _bigfix_ release. Thanks for pointing out thesimilarities.

Cos

> > J-D> > On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> > On Thu, May 30, 2013 at 03:11PM, Matt Foley wrote:> >> Hi Cos,> >> I would also request that you renumber the release candidate to just> >> three-numbers, hence "2.0.5-alpha".> >>> >> Arun, are you willing to start the 2.1.x name-space for your next release,> >> so that 2.0.x-alpha can become an intermediate stabilization branch as Cos> >> and Konst want?> >> > Let's get the facts straight, Matt, please: this "want" has been expressed in> > the official vote here http://s.apache.org/ZMf Apparently, 2.0.5-alpha is> > blocked now because of the another vote that hasn't been closed yet for> > whatever reason. In order to unblock a number of releases in downstream> > component I have moved forward with this release. Do you have any material> > objections to the release that pursue this goal?> >> >> I just think that using four-number schemes was symptomatic of the> >> near-forking we had back in the 0.20.xxx.y days, and I really don't want to> >> go back there. Especially since you could say that "0.20.xxx.y" is just> >> three significant numbers, the leading zero being inconsequential.> >> > I dare to remind that forth part of the version is reserved - not in a> > parallel universe, of course - for "patch level" aka bug fixes. It hardly can> > be taken a sign of 'forking' by any definition.> >> > Cos> >> >> So, would you please consider using 2.0.5-alpha?> >>> >> As for the "2.0.5-SNAPSHOT" in the branch-2 versioning, that's standard> >> usage. Whoever makes the 2.0.5 release (or any "next" release) is expected> >> to update the parent branch's SNAPSHOT default versioning, per> >> HowToReleasePostMavenization#Branching<https://wiki.apache.org/hadoop/HowToReleasePostMavenization#Branching>,> >> step 6.> >>> >> Thanks,> >> --Matt> >>> >>> >> On Thu, May 30, 2013 at 11:52 AM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> >>> >> > On Thu, May 30, 2013 at 10:57AM, Arun C Murthy wrote:> >> > > I see you just re-opened MAPREUDCE-5211.> >> > >> >> > > Why not include MAPREDUCE-5211 as well rather than create one release> >> > per patch?> >> >> >> > Arun, it is unclear if MAPREDUCE-5211 has implications in 2.0.4 as per> >> >> >> > https://issues.apache.org/jira/browse/MAPREDUCE-5211?focusedCommentId=13670574&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13670574> >> >> >> > Hence, there's a good chance that it never will be backported. And I don't> >> > have any plans to created 'a release per patch'.> >> >> >> > > Also, this is the first time we are seeing a four-numbered scheme in> >> > Hadoop.> >> > > Why not call this 2.0.5-alpha?> >> >> >> > There were precedents in four-numbered schemes before: 0.20.20[3-5].0> >> > comes to> >> > mind.> >> >> >> > As for 2.0.5-alpha: The release numbering games and votes that had> >> > happened in> >> > the last few weeks are very confusing. Some of them never been concluded,> >> > the> >> > branches are moved and artifact versions seem to be colliding. 2.0.4.x> >> > seems> >> > to work well for the stabilization purposes and it will allow to unblock> >> > downstream and integration projects quickly.> >> >> >> > Cos> >> >> >> > > Arun> >> > >> >> > > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> >> > >> >> > > > All,> >> > > >> >> > > > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that

> I see you just re-opened MAPREUDCE-4211.> > Why not include MAPREDUCE-4211 as well rather than create one release per patch?> > Also, this is the first time we are seeing a four-numbered scheme in Hadoop. Why not call this 2.0.5-alpha?> > Arun> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> >> All,>> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would>> like to release.>> >> This is a stabilization release that includes fixed for a couple a of issues>> discovered in the testing with BigTop 0.6.0 release candidate.>> >> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/>> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0>> >> The maven artifacts are available via repository.apache.org.>> >> Please try the release bits and vote; the vote will run for the usual 7 days.>> >> Thanks for your voting>> Cos>> > >

On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:> Why not include MAPREDUCE-4211 as well rather than create one release per patch?

>From Cos's description, it sounded like these were backports of fixesto help Sqoop2 and fix some build issues. If it's not just to fixupleftover bugs in 2.0.4 *once* so downstream projects can integrateagainst 2.0.4.1, and this a release series, then I've completelymisunderstood the purpose.

Cos, are you planning 2.0.4.2?

> Also, this is the first time we are seeing a four-numbered scheme in Hadoop. Why not call this 2.0.5-alpha?

Good point. Since it contains only backports from branch-2, it wouldmake sense for it to be an intermediate release.

I shouldn't have to say this, but I'm changing my vote to -1 while wework this out. -C

> On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:>>> All,>>>> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would>> like to release.>>>> This is a stabilization release that includes fixed for a couple a of issues>> discovered in the testing with BigTop 0.6.0 release candidate.>>>> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/>> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0>>>> The maven artifacts are available via repository.apache.org.>>>> Please try the release bits and vote; the vote will run for the usual 7 days.>>>> Thanks for your voting>> Cos>>>>

There's no misunderstanding Chris - this release is to unblock downstream.

As for your question: I don't have a crystal ball; I wish though. I think theanswer depends on will be there more blocking bugs found in the later releasesof Bigtop or other downstream components.This is bugfix release and, I guess, if there are more bugs found in thefuture - more releases would have to be cut. Isn't this is why the software isbeing released?

Now, the -1: I am not clear about the justification. What exactly we expect to"work out"?

Cos

On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:> > Why not include MAPREDUCE-4211 as well rather than create one release per patch?> > From Cos's description, it sounded like these were backports of fixes> to help Sqoop2 and fix some build issues. If it's not just to fixup> leftover bugs in 2.0.4 *once* so downstream projects can integrate> against 2.0.4.1, and this a release series, then I've completely> misunderstood the purpose.> > Cos, are you planning 2.0.4.2?> > > Also, this is the first time we are seeing a four-numbered scheme in Hadoop. Why not call this 2.0.5-alpha?> > Good point. Since it contains only backports from branch-2, it would> make sense for it to be an intermediate release.> > I shouldn't have to say this, but I'm changing my vote to -1 while we> work this out. -C> > > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> >> >> All,> >>> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would> >> like to release.> >>> >> This is a stabilization release that includes fixed for a couple a of issues> >> discovered in the testing with BigTop 0.6.0 release candidate.> >>> >> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> >> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0> >>> >> The maven artifacts are available via repository.apache.org.> >>> >> Please try the release bits and vote; the vote will run for the usual 7 days.> >>> >> Thanks for your voting> >> Cos> >>> >> >

On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> There's no misunderstanding Chris - this release is to unblock downstream.>> As for your question: I don't have a crystal ball; I wish though. I think the> answer depends on will be there more blocking bugs found in the later releases> of Bigtop or other downstream components.> This is bugfix release and, I guess, if there are more bugs found in the> future - more releases would have to be cut. Isn't this is why the software is> being released?

Sure, but they're all backports from the release currently marked for2.0.5. Either (a) these are really blocker bugs and we should roll apatch release or (b) some bleeding-edge work needs to work around thiswhile branch-2 is released in the next few weeks. If it's not severeenough to justify disrupting the versioning of snapshot mavenartifacts in branch-2, then we're clearly not in case (a).

I thought this was the result of extensive testing, and 2.0.4.1 was arelease to enable additional integration before 2.0.5. If we plan toroll more releases as a subset of the bug fixes committed to branch-2then just call it 2.0.5. Please make sure it- and any future,intermediate release- is worth the disruption.

> Now, the -1: I am not clear about the justification. What exactly we expect to> "work out"?

It's become fashionable to close threads and count votes in the middleof the discussion. I changed my vote instead of trusting you. -C

> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:>> > Why not include MAPREDUCE-4211 as well rather than create one release per patch?>>>> From Cos's description, it sounded like these were backports of fixes>> to help Sqoop2 and fix some build issues. If it's not just to fixup>> leftover bugs in 2.0.4 *once* so downstream projects can integrate>> against 2.0.4.1, and this a release series, then I've completely>> misunderstood the purpose.>>>> Cos, are you planning 2.0.4.2?>>>> > Also, this is the first time we are seeing a four-numbered scheme in Hadoop. Why not call this 2.0.5-alpha?>>>> Good point. Since it contains only backports from branch-2, it would>> make sense for it to be an intermediate release.>>>> I shouldn't have to say this, but I'm changing my vote to -1 while we>> work this out. -C>>>> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:>> >>> >> All,>> >>>> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would>> >> like to release.>> >>>> >> This is a stabilization release that includes fixed for a couple a of issues>> >> discovered in the testing with BigTop 0.6.0 release candidate.>> >>>> >> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/>> >> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0>> >>>> >> The maven artifacts are available via repository.apache.org.>> >>>> >> Please try the release bits and vote; the vote will run for the usual 7 days.>> >>>> >> Thanks for your voting>> >> Cos>> >>>> >>> >

On Thu, May 30, 2013 at 03:18PM, Chris Douglas wrote:> On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> > There's no misunderstanding Chris - this release is to unblock downstream.> >> > As for your question: I don't have a crystal ball; I wish though. I think the> > answer depends on will be there more blocking bugs found in the later releases> > of Bigtop or other downstream components.> > This is bugfix release and, I guess, if there are more bugs found in the> > future - more releases would have to be cut. Isn't this is why the software is> > being released?> > Sure, but they're all backports from the release currently marked for> 2.0.5. Either (a) these are really blocker bugs and we should roll a> patch release or (b) some bleeding-edge work needs to work around this> while branch-2 is released in the next few weeks. If it's not severe> enough to justify disrupting the versioning of snapshot maven> artifacts in branch-2, then we're clearly not in case (a).> > I thought this was the result of extensive testing, and 2.0.4.1 was a> release to enable additional integration before 2.0.5. If we plan to> roll more releases as a subset of the bug fixes committed to branch-2> then just call it 2.0.5. Please make sure it- and any future,> intermediate release- is worth the disruption.

There's no plans to release anything else at this point - this is a bug-fixrelease, as I pointed out on a numerous occasions. There's no new features -just 2 fixes.

2.0.5 matter became and still is too controversial at some point. The votestarted by Arun to override the results of the Konstantin's vote never beenclosed. The downstream projects are handing in the middle of the air becauseof that confusion.

> > Now, the -1: I am not clear about the justification. What exactly we expect to> > "work out"?> > It's become fashionable to close threads and count votes in the middle> of the discussion. I changed my vote instead of trusting you. -C

Have I missed something or you just called me a cheater and a lair right to my face?

Cos

> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:> >> > Why not include MAPREDUCE-4211 as well rather than create one release per patch?> >>> >> From Cos's description, it sounded like these were backports of fixes> >> to help Sqoop2 and fix some build issues. If it's not just to fixup> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate> >> against 2.0.4.1, and this a release series, then I've completely> >> misunderstood the purpose.> >>> >> Cos, are you planning 2.0.4.2?> >>> >> > Also, this is the first time we are seeing a four-numbered scheme in Hadoop. Why not call this 2.0.5-alpha?> >>> >> Good point. Since it contains only backports from branch-2, it would> >> make sense for it to be an intermediate release.> >>> >> I shouldn't have to say this, but I'm changing my vote to -1 while we> >> work this out. -C> >>> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> >> >> >> >> All,> >> >>> >> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would> >> >> like to release.> >> >>> >> >> This is a stabilization release that includes fixed for a couple a of issues> >> >> discovered in the testing with BigTop 0.6.0 release candidate.> >> >>> >> >> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> >> >> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0> >> >>> >> >> The maven artifacts are available via repository.apache.org.> >> >>> >> >> Please try the release bits and vote; the vote will run for the usual 7 days.> >> >>> >> >> Thanks for your voting> >> >> Cos> >> >>> >> >> >> >

On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> There's no plans to release anything else at this point - this is a bug-fix> release, as I pointed out on a numerous occasions. There's no new features -> just 2 fixes.

If you're worried about extending the voting by a week, I don't thinkanyone can reasonably object to a truncated schedule if the onlychange is the version number. Downstream fixes discovered in Bigtopare a sufficient reason for a patch release and I think we'd all likethem to become routine. Not just in 2.0.x, but in later releasebranches.

> 2.0.5 matter became and still is too controversial at some point. The vote> started by Arun to override the results of the Konstantin's vote never been> closed.

For the nth time, neither release plan vote was binding. We recentlyamended the bylaws to eliminate this confusion. There is no ambiguitybetween votes when neither is in scope.

> The downstream projects are handing in the middle of the air because> of that confusion.

Can we please ground our discussion when discussing compatibility andbugs? Breathless alarm is not proportional to the severity, here.

> Have I missed something or you just called me a cheater and a lair right to my face?

I called you neither. The prenominate votes were closed, counted, anddeclared to be binding over objections. I'm annoyed that I have totoggle my vote to prevent that tactic, but based on recent experienceI don't expect you to forgo it. I'd be happy to learn my caution isunnecessary. -C

>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:>> >> > Why not include MAPREDUCE-4211 as well rather than create one release per patch?>> >>>> >> From Cos's description, it sounded like these were backports of fixes>> >> to help Sqoop2 and fix some build issues. If it's not just to fixup>> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate>> >> against 2.0.4.1, and this a release series, then I've completely>> >> misunderstood the purpose.>> >>>> >> Cos, are you planning 2.0.4.2?>> >>>> >> > Also, this is the first time we are seeing a four-numbered scheme in Hadoop. Why not call this 2.0.5-alpha?>> >>>> >> Good point. Since it contains only backports from branch-2, it would>> >> make sense for it to be an intermediate release.>> >>>> >> I shouldn't have to say this, but I'm changing my vote to -1 while we>> >> work this out. -C>> >>>> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:>> >> >>> >> >> All,>> >> >>>> >> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would>> >> >> like to release.>> >> >>>> >> >> This is a stabilization release that includes fixed for a couple a of issues>> >> >> discovered in the testing with BigTop 0.6.0 release candidate.>> >> >>>> >> >> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/>> >> >> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0>> >> >>>> >> >> The maven artifacts are available via repository.apache.org.>> >> >>>> >> >> Please try the release bits and vote; the vote will run for the usual 7 days.>> >> >>>> >> >> Thanks for your voting>> >> >> Cos>> >> >>>> >> >>> >> >

On Thu, May 30, 2013 at 05:30PM, Chris Douglas wrote:> On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:> > There's no plans to release anything else at this point - this is a bug-fix> > release, as I pointed out on a numerous occasions. There's no new features -> > just 2 fixes.> > If you're worried about extending the voting by a week, I don't think> anyone can reasonably object to a truncated schedule if the only> change is the version number. Downstream fixes discovered in Bigtop> are a sufficient reason for a patch release and I think we'd all like> them to become routine. Not just in 2.0.x, but in later release> branches.

I have no issues of changing the version to 2.0.5-alpha and restarting to votefor the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote becauseof the number change?

> > 2.0.5 matter became and still is too controversial at some point. The vote> > started by Arun to override the results of the Konstantin's vote never been> > closed.> > For the nth time, neither release plan vote was binding. We recently> amended the bylaws to eliminate this confusion. There is no ambiguity> between votes when neither is in scope.

Does the result of bylaw vote nullifies the unfinished vote started by Arun?Sorry, I am dense, apparently.

> > The downstream projects are handing in the middle of the air because> > of that confusion.> > Can we please ground our discussion when discussing compatibility and> bugs? Breathless alarm is not proportional to the severity, here.

Good point. Can we limit the vote thread to the merits of the release then?

> > Have I missed something or you just called me a cheater and a lair right to my face?> > I called you neither. The prenominate votes were closed, counted, and> declared to be binding over objections. I'm annoyed that I have to> toggle my vote to prevent that tactic, but based on recent experience> I don't expect you to forgo it. I'd be happy to learn my caution is> unnecessary. -C

That sound like adding an insult to injury, if my forth-language skills do notmislead me.

Cos

> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:> >> >> > Why not include MAPREDUCE-4211 as well rather than create one release per patch?> >> >>> >> >> From Cos's description, it sounded like these were backports of fixes> >> >> to help Sqoop2 and fix some build issues. If it's not just to fixup> >> >> leftover bugs in 2.0.4 *once* so downstream projects can integrate> >> >> against 2.0.4.1, and this a release series, then I've completely> >> >> misunderstood the purpose.> >> >>> >> >> Cos, are you planning 2.0.4.2?> >> >>> >> >> > Also, this is the first time we are seeing a four-numbered scheme in Hadoop. Why not call this 2.0.5-alpha?> >> >>> >> >> Good point. Since it contains only backports from branch-2, it would> >> >> make sense for it to be an intermediate release.> >> >>> >> >> I shouldn't have to say this, but I'm changing my vote to -1 while we> >> >> work this out. -C> >> >>> >> >> > On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:> >> >> >> >> >> >> All,> >> >> >>> >> >> >> I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I would> >> >> >> like to release.> >> >> >>> >> >> >> This is a stabilization release that includes fixed for a couple a of issues> >> >> >> discovered in the testing with BigTop 0.6.0 release candidate.> >> >> >>> >> >> >> The RC is available at: http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> >> >> >> The RC tag in svn is here: http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0> >> >> >>> >> >> >> The maven artifacts are available via repository.apache.org.> >> >> >>> >> >> >> Please try the release bits and vote; the vote will run for the usual 7 days.> >> >> >>> >> >> >> Thanks for your voting> >> >> >> Cos

Technically, current branch-2 uses 2.0.5-SNAPSHOT and produces mavenartifacts with that version.So having another version with the same numbers will be confusing.Therefore 4-level numbers.I thought I mentioned it to you before.

> I see you just re-opened MAPREUDCE-4211.>> Why not include MAPREDUCE-4211 as well rather than create one release per> patch?>> Also, this is the first time we are seeing a four-numbered scheme in> Hadoop. Why not call this 2.0.5-alpha?>> Arun>> On May 24, 2013, at 8:48 PM, Konstantin Boudnik wrote:>> > All,> >> > I have created a release candidate (rc0) for hadoop-2.0.4.1-alpha that I> would> > like to release.> >> > This is a stabilization release that includes fixed for a couple a of> issues> > discovered in the testing with BigTop 0.6.0 release candidate.> >> > The RC is available at:> http://people.apache.org/~cos/hadoop-2.0.4.1-alpha-rc0/> > The RC tag in svn is here:> http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.4.1-alpha-rc0> >> > The maven artifacts are available via repository.apache.org.> >> > Please try the release bits and vote; the vote will run for the usual 7> days.> >> > Thanks for your voting> > Cos> >>>>

Good point Thomas - I have just fixed the name of the file. Nice catch!

Sigh... these three text files... If anyone feels strongly about having themin place - I will update the tarballs and recalculate the checksums. Or justleave it as is, perhaps? So, either way is fine with me.

Thanks, Cos

On Tue, Jun 04, 2013 at 08:47PM, Thomas Graves wrote:> Cos,> > The name of the mds file for the binary tar is missing a "." in your> apache directory: hadoop-2.0.5-alphatar.gz.mds> <http://people.apache.org/~cos/hadoop-2.0.5-alpha-rc2/hadoop-2.0.5-alphatar> .gz.mds>> > Contents of it are fine though so you might just add the ".".> > Also the NOTICE.txt, README.txt, and LICENSE.txt files are missing from> the top level directory in both the src and binary tar ball.> > Everything else looks good. Verified checksums, signatures, built, ran> single node cluster.> > Thanks,> Tom> > > > On 6/3/13 2:51 PM, "Konstantin Boudnik" <[EMAIL PROTECTED]> wrote:> > >I have rolled out release candidate (rc2) for hadoop-2.0.5-alpha.> >> >The difference between rc1 and rc2 is the "optimistic release date" is> >set for> >06/06/2013 in the CHANGES.txt files.> >> >The binary artifact is the same - there's no need to rebuild it. The maven> >artifacts are the same.> >> >The difference between the two RCs:> >> >svn diff \> > > >https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.5-alpha-rc> >1/ \> > > >https://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.5-alpha-rc> >2/> >> >New RC builds are uploaded to the web.> >The RC is available at:> >http://people.apache.org/~cos/hadoop-2.0.5-alpha-rc2/> >The RC tag in svn is here:> >http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.5-alpha-rc2> >> >I would like to extend the vote for another three days for it is such a> >minor> >change that doesn't affect anything but the recorded release date. Please> >cast your vote before 06/06/2013 5pm PDT.> >> >Thanks for your patience!> > Cos> >> >On Fri, May 31, 2013 at 09:27PM, Konstantin Boudnik wrote:> >> All,> >> > >> I have created a release candidate (rc1) for hadoop-2.0.5-alpha that I> >>would> >> like to release.> >> > >> This is a stabilization release that includes fixed for a couple a of> >>issues> >> discovered in the testing with BigTop 0.6.0 release candidate.> >> > >> The RC is available at:> >>http://people.apache.org/~cos/hadoop-2.0.5-alpha-rc1/> >> The RC tag in svn is here:> >>http://svn.apache.org/repos/asf/hadoop/common/tags/release-2.0.5-alpha-rc> >>1> >> > >> The maven artifacts will be available via repository.apache.org on Sat,> >>June> >> 1st, 2013 at 2 pm PDT as outlined here> >> http://s.apache.org/WKD> >> > >> Please try the release bits and vote; the vote will run for the 3 days,> >> because this is just a version name change. The bits are identical to> >>the ones> >> voted on before in> >> http://s.apache.org/2041move> >> > >> Thanks for your voting> >> Cos> >> >