You are viewing a plain text version of this content. The canonical link for it is here.

Posted to hdfs-dev@hadoop.apache.org by Konstantin Boudnik <co...@apache.org> on 2013/05/25 05:48:36 UTC

[VOTE] Release Apache Hadoop 2.0.4.1-alpha

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

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Roman Shaposhnik <rv...@apache.org>.

On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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 integration
tests on Bigtop jenkins for both secure and unsecure deployments. Ran
Scoop 2 tests.

Thanks,
Roman.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Roman Shaposhnik <rv...@apache.org>.

On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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 integration
tests on Bigtop jenkins for both secure and unsecure deployments. Ran
Scoop 2 tests.

Thanks,
Roman.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 the
similarities.

Cos

> 
> J-D
> 
> On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
> >> > > >
> >> > >
> >> > >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 the
similarities.

Cos

> 
> J-D
> 
> On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
> >> > > >
> >> > >
> >> > >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 the
similarities.

Cos

> 
> J-D
> 
> On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
> >> > > >
> >> > >
> >> > >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 the
similarities.

Cos

> 
> J-D
> 
> On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
> >> > > >
> >> > >
> >> > >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Jean-Daniel Cryans <jd...@apache.org>.

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

J-D

On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
>> > > >
>> > >
>> > >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Jean-Daniel Cryans <jd...@apache.org>.

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

J-D

On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
>> > > >
>> > >
>> > >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Jean-Daniel Cryans <jd...@apache.org>.

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

J-D

On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
>> > > >
>> > >
>> > >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Jean-Daniel Cryans <jd...@apache.org>.

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

J-D

On Thu, May 30, 2013 at 3:52 PM, Konstantin Boudnik <co...@apache.org> 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 <co...@apache.org> 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
>> > > >
>> > >
>> > >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 <co...@apache.org> 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
> > > >
> > >
> > >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 <co...@apache.org> 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
> > > >
> > >
> > >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 <co...@apache.org> 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
> > > >
> > >
> > >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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 <co...@apache.org> 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
> > > >
> > >
> > >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Matt Foley <ma...@apache.org>.

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?

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.

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 <co...@apache.org> 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
> > >
> >
> >
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Matt Foley <ma...@apache.org>.

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?

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.

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 <co...@apache.org> 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
> > >
> >
> >
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Matt Foley <ma...@apache.org>.

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?

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.

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 <co...@apache.org> 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
> > >
> >
> >
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Matt Foley <ma...@apache.org>.

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?

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.

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 <co...@apache.org> 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
> > >
> >
> >
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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
> > 
> 
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

Sorry, it should be MAPREDUCE-5211 (not MAPREDUCE-4211).

thanks,
Arun

On May 30, 2013, at 10:57 AM, Arun C Murthy wrote:

> 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
>> 
> 
> 

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

Sounds like a plan.

Thanks,
--Konst


On Thu, May 30, 2013 at 8:41 PM, Alejandro Abdelnur <tu...@cloudera.com>wrote:

> Konstantin, Cos,
>
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
>
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
>
> Thanks.
>
>
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org>
> wrote:
>
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
>
>
>
> --
> Alejandro
>

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

I changes are completed, I have updated branch-2 and trunk CHANGES.txt files
as planned. Version of the branch-2 is set to 2.1.0-beta; 2.0.5-alpha release
artifacts are deployed to the staging area.

Thanks for your patience, guys!
  Cos

On Fri, May 31, 2013 at 12:45PM, Konstantin Boudnik wrote:
> Guys,
> 
> I will be performing some changes wrt to moving 2.0.4.1 release candidate to
> 2.0.5 space. As outline below by Alejandro:
> 
> 1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging can
> be done after the next two steps.
> 
> I will be doing all these modifications in the next hour or so.
> 
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> 
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on trunk
> and branch-2 between 1 pm and 2 pm PDT.
> 
> Please let me know if you see any flaw above, questions.
>   Cos
> 
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> > 
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
> 
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> 
> > Please take care of the rest.
> 
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

I changes are completed, I have updated branch-2 and trunk CHANGES.txt files
as planned. Version of the branch-2 is set to 2.1.0-beta; 2.0.5-alpha release
artifacts are deployed to the staging area.

Thanks for your patience, guys!
  Cos

On Fri, May 31, 2013 at 12:45PM, Konstantin Boudnik wrote:
> Guys,
> 
> I will be performing some changes wrt to moving 2.0.4.1 release candidate to
> 2.0.5 space. As outline below by Alejandro:
> 
> 1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging can
> be done after the next two steps.
> 
> I will be doing all these modifications in the next hour or so.
> 
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> 
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on trunk
> and branch-2 between 1 pm and 2 pm PDT.
> 
> Please let me know if you see any flaw above, questions.
>   Cos
> 
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> > 
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
> 
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> 
> > Please take care of the rest.
> 
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Indeed! The second part is happening on Saturday, JUN01 2013 1PM-2PM PST. 

On Fri, May 31, 2013 at 01:01PM, Alejandro Abdelnur wrote:
> Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
> (FRI MAY31 1PM PST). Correct?
> 
> Thx
> 
> On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > Guys,
> >
> > I will be performing some changes wrt to moving 2.0.4.1 release candidate
> > to
> > 2.0.5 space. As outline below by Alejandro:
> >
> > 1. I will create new 2.0.5-alpha branch from the current head of
> > 2.0.4-alpha
> > that contains 2.0.4.1 changes
> > 2. consequently, set the artifacts version on the new branch to be
> > 2.0.5-alpha
> > 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> > 4. At this point I can cut an RC and put it out for re-vote. The staging
> > can
> > be done after the next two steps.
> >
> > I will be doing all these modifications in the next hour or so.
> >
> > Tomorrow at 1 pm PDT I would like to:
> > 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> > 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> > names
> > 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> >
> > To avoid any collisions during the last two steps - especially 2. - I would
> > ask everyone to hold off the modifications of the CHANGES.txt files on
> > trunk
> > and branch-2 between 1 pm and 2 pm PDT.
> >
> > Please let me know if you see any flaw above, questions.
> >   Cos
> >
> > > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > > housekeeping as you work the new RC.
> > >
> > > * rename the svn branch
> > > * update the versions in the POMs
> > > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > > version, change the fix version of the 2 JIRAs that make the RC
> >
> > > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> > versions
> > > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> >
> > > Please take care of the rest.
> >
> > > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> >
> 
> 
> 
> -- 
> Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

I changes are completed, I have updated branch-2 and trunk CHANGES.txt files
as planned. Version of the branch-2 is set to 2.1.0-beta; 2.0.5-alpha release
artifacts are deployed to the staging area.

Thanks for your patience, guys!
  Cos

On Fri, May 31, 2013 at 12:45PM, Konstantin Boudnik wrote:
> Guys,
> 
> I will be performing some changes wrt to moving 2.0.4.1 release candidate to
> 2.0.5 space. As outline below by Alejandro:
> 
> 1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging can
> be done after the next two steps.
> 
> I will be doing all these modifications in the next hour or so.
> 
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> 
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on trunk
> and branch-2 between 1 pm and 2 pm PDT.
> 
> Please let me know if you see any flaw above, questions.
>   Cos
> 
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> > 
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
> 
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> 
> > Please take care of the rest.
> 
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Indeed! The second part is happening on Saturday, JUN01 2013 1PM-2PM PST. 

On Fri, May 31, 2013 at 01:01PM, Alejandro Abdelnur wrote:
> Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
> (FRI MAY31 1PM PST). Correct?
> 
> Thx
> 
> On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > Guys,
> >
> > I will be performing some changes wrt to moving 2.0.4.1 release candidate
> > to
> > 2.0.5 space. As outline below by Alejandro:
> >
> > 1. I will create new 2.0.5-alpha branch from the current head of
> > 2.0.4-alpha
> > that contains 2.0.4.1 changes
> > 2. consequently, set the artifacts version on the new branch to be
> > 2.0.5-alpha
> > 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> > 4. At this point I can cut an RC and put it out for re-vote. The staging
> > can
> > be done after the next two steps.
> >
> > I will be doing all these modifications in the next hour or so.
> >
> > Tomorrow at 1 pm PDT I would like to:
> > 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> > 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> > names
> > 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> >
> > To avoid any collisions during the last two steps - especially 2. - I would
> > ask everyone to hold off the modifications of the CHANGES.txt files on
> > trunk
> > and branch-2 between 1 pm and 2 pm PDT.
> >
> > Please let me know if you see any flaw above, questions.
> >   Cos
> >
> > > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > > housekeeping as you work the new RC.
> > >
> > > * rename the svn branch
> > > * update the versions in the POMs
> > > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > > version, change the fix version of the 2 JIRAs that make the RC
> >
> > > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> > versions
> > > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> >
> > > Please take care of the rest.
> >
> > > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> >
> 
> 
> 
> -- 
> Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Indeed! The second part is happening on Saturday, JUN01 2013 1PM-2PM PST. 

On Fri, May 31, 2013 at 01:01PM, Alejandro Abdelnur wrote:
> Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
> (FRI MAY31 1PM PST). Correct?
> 
> Thx
> 
> On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > Guys,
> >
> > I will be performing some changes wrt to moving 2.0.4.1 release candidate
> > to
> > 2.0.5 space. As outline below by Alejandro:
> >
> > 1. I will create new 2.0.5-alpha branch from the current head of
> > 2.0.4-alpha
> > that contains 2.0.4.1 changes
> > 2. consequently, set the artifacts version on the new branch to be
> > 2.0.5-alpha
> > 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> > 4. At this point I can cut an RC and put it out for re-vote. The staging
> > can
> > be done after the next two steps.
> >
> > I will be doing all these modifications in the next hour or so.
> >
> > Tomorrow at 1 pm PDT I would like to:
> > 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> > 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> > names
> > 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> >
> > To avoid any collisions during the last two steps - especially 2. - I would
> > ask everyone to hold off the modifications of the CHANGES.txt files on
> > trunk
> > and branch-2 between 1 pm and 2 pm PDT.
> >
> > Please let me know if you see any flaw above, questions.
> >   Cos
> >
> > > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > > housekeeping as you work the new RC.
> > >
> > > * rename the svn branch
> > > * update the versions in the POMs
> > > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > > version, change the fix version of the 2 JIRAs that make the RC
> >
> > > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> > versions
> > > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> >
> > > Please take care of the rest.
> >
> > > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> >
> 
> 
> 
> -- 
> Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Indeed! The second part is happening on Saturday, JUN01 2013 1PM-2PM PST. 

On Fri, May 31, 2013 at 01:01PM, Alejandro Abdelnur wrote:
> Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
> (FRI MAY31 1PM PST). Correct?
> 
> Thx
> 
> On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > Guys,
> >
> > I will be performing some changes wrt to moving 2.0.4.1 release candidate
> > to
> > 2.0.5 space. As outline below by Alejandro:
> >
> > 1. I will create new 2.0.5-alpha branch from the current head of
> > 2.0.4-alpha
> > that contains 2.0.4.1 changes
> > 2. consequently, set the artifacts version on the new branch to be
> > 2.0.5-alpha
> > 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> > 4. At this point I can cut an RC and put it out for re-vote. The staging
> > can
> > be done after the next two steps.
> >
> > I will be doing all these modifications in the next hour or so.
> >
> > Tomorrow at 1 pm PDT I would like to:
> > 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> > 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> > names
> > 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> >
> > To avoid any collisions during the last two steps - especially 2. - I would
> > ask everyone to hold off the modifications of the CHANGES.txt files on
> > trunk
> > and branch-2 between 1 pm and 2 pm PDT.
> >
> > Please let me know if you see any flaw above, questions.
> >   Cos
> >
> > > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > > housekeeping as you work the new RC.
> > >
> > > * rename the svn branch
> > > * update the versions in the POMs
> > > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > > version, change the fix version of the 2 JIRAs that make the RC
> >
> > > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> > versions
> > > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> >
> > > Please take care of the rest.
> >
> > > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> >
> 
> 
> 
> -- 
> Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
(FRI MAY31 1PM PST). Correct?

Thx

On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Guys,
>
> I will be performing some changes wrt to moving 2.0.4.1 release candidate
> to
> 2.0.5 space. As outline below by Alejandro:
>
> 1. I will create new 2.0.5-alpha branch from the current head of
> 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be
> 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging
> can
> be done after the next two steps.
>
> I will be doing all these modifications in the next hour or so.
>
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
>
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on
> trunk
> and branch-2 between 1 pm and 2 pm PDT.
>
> Please let me know if you see any flaw above, questions.
>   Cos
>
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> >
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
>
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
>
> > Please take care of the rest.
>
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
>



-- 
Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
(FRI MAY31 1PM PST). Correct?

Thx

On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Guys,
>
> I will be performing some changes wrt to moving 2.0.4.1 release candidate
> to
> 2.0.5 space. As outline below by Alejandro:
>
> 1. I will create new 2.0.5-alpha branch from the current head of
> 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be
> 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging
> can
> be done after the next two steps.
>
> I will be doing all these modifications in the next hour or so.
>
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
>
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on
> trunk
> and branch-2 between 1 pm and 2 pm PDT.
>
> Please let me know if you see any flaw above, questions.
>   Cos
>
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> >
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
>
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
>
> > Please take care of the rest.
>
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
>



-- 
Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

I changes are completed, I have updated branch-2 and trunk CHANGES.txt files
as planned. Version of the branch-2 is set to 2.1.0-beta; 2.0.5-alpha release
artifacts are deployed to the staging area.

Thanks for your patience, guys!
  Cos

On Fri, May 31, 2013 at 12:45PM, Konstantin Boudnik wrote:
> Guys,
> 
> I will be performing some changes wrt to moving 2.0.4.1 release candidate to
> 2.0.5 space. As outline below by Alejandro:
> 
> 1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging can
> be done after the next two steps.
> 
> I will be doing all these modifications in the next hour or so.
> 
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> 
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on trunk
> and branch-2 between 1 pm and 2 pm PDT.
> 
> Please let me know if you see any flaw above, questions.
>   Cos
> 
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> > 
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
> 
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> 
> > Please take care of the rest.
> 
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
(FRI MAY31 1PM PST). Correct?

Thx

On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Guys,
>
> I will be performing some changes wrt to moving 2.0.4.1 release candidate
> to
> 2.0.5 space. As outline below by Alejandro:
>
> 1. I will create new 2.0.5-alpha branch from the current head of
> 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be
> 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging
> can
> be done after the next two steps.
>
> I will be doing all these modifications in the next hour or so.
>
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
>
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on
> trunk
> and branch-2 between 1 pm and 2 pm PDT.
>
> Please let me know if you see any flaw above, questions.
>   Cos
>
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> >
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
>
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
>
> > Please take care of the rest.
>
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
>



-- 
Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Azuryy Yu <az...@gmail.com>.

2.1.0-alpha is 2.0.5-beta actually.

--Send from my Sony mobile.
On Jun 1, 2013 8:14 AM, "Ted Yu" <yu...@gmail.com> wrote:

> I am currently testing HBase 0.95 using 2.0.5-SNAPSHOT artifacts.
>
> Would 2.1.0-SNAPSHOT maven artifacts be available after tomorrow's change ?
>
> Thanks
>
> On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > Guys,
> >
> > I will be performing some changes wrt to moving 2.0.4.1 release candidate
> > to
> > 2.0.5 space. As outline below by Alejandro:
> >
> > 1. I will create new 2.0.5-alpha branch from the current head of
> > 2.0.4-alpha
> > that contains 2.0.4.1 changes
> > 2. consequently, set the artifacts version on the new branch to be
> > 2.0.5-alpha
> > 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> > 4. At this point I can cut an RC and put it out for re-vote. The staging
> > can
> > be done after the next two steps.
> >
> > I will be doing all these modifications in the next hour or so.
> >
> > Tomorrow at 1 pm PDT I would like to:
> > 1. update the version of the artifacts on branch-2 to become
> 2.1.0-SNAPSHOT
> > 2. update the CHANGES.txt in the trunk and branch-2 to reflect new
> version
> > names
> > 3. at this point it should safe to do the staging for 2.0.5-alpha RC
> >
> > To avoid any collisions during the last two steps - especially 2. - I
> would
> > ask everyone to hold off the modifications of the CHANGES.txt files on
> > trunk
> > and branch-2 between 1 pm and 2 pm PDT.
> >
> > Please let me know if you see any flaw above, questions.
> >   Cos
> >
> > > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > > housekeeping as you work the new RC.
> > >
> > > * rename the svn branch
> > > * update the versions in the POMs
> > > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > > version, change the fix version of the 2 JIRAs that make the RC
> >
> > > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> > versions
> > > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> >
> > > Please take care of the rest.
> >
> > > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> >
>

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Ted Yu <yu...@gmail.com>.

I am currently testing HBase 0.95 using 2.0.5-SNAPSHOT artifacts.

Would 2.1.0-SNAPSHOT maven artifacts be available after tomorrow's change ?

Thanks

On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Guys,
>
> I will be performing some changes wrt to moving 2.0.4.1 release candidate
> to
> 2.0.5 space. As outline below by Alejandro:
>
> 1. I will create new 2.0.5-alpha branch from the current head of
> 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be
> 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging
> can
> be done after the next two steps.
>
> I will be doing all these modifications in the next hour or so.
>
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
>
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on
> trunk
> and branch-2 between 1 pm and 2 pm PDT.
>
> Please let me know if you see any flaw above, questions.
>   Cos
>
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> >
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
>
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
>
> > Please take care of the rest.
>
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
>

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Cos, just to be clear, this is happening SAT JUN01 1PM-2PM PST, not now
(FRI MAY31 1PM PST). Correct?

Thx

On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Guys,
>
> I will be performing some changes wrt to moving 2.0.4.1 release candidate
> to
> 2.0.5 space. As outline below by Alejandro:
>
> 1. I will create new 2.0.5-alpha branch from the current head of
> 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be
> 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging
> can
> be done after the next two steps.
>
> I will be doing all these modifications in the next hour or so.
>
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
>
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on
> trunk
> and branch-2 between 1 pm and 2 pm PDT.
>
> Please let me know if you see any flaw above, questions.
>   Cos
>
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> >
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
>
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
>
> > Please take care of the rest.
>
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
>



-- 
Alejandro

Re: Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Ted Yu <yu...@gmail.com>.

I am currently testing HBase 0.95 using 2.0.5-SNAPSHOT artifacts.

Would 2.1.0-SNAPSHOT maven artifacts be available after tomorrow's change ?

Thanks

On Fri, May 31, 2013 at 12:45 PM, Konstantin Boudnik <co...@apache.org> wrote:

> Guys,
>
> I will be performing some changes wrt to moving 2.0.4.1 release candidate
> to
> 2.0.5 space. As outline below by Alejandro:
>
> 1. I will create new 2.0.5-alpha branch from the current head of
> 2.0.4-alpha
> that contains 2.0.4.1 changes
> 2. consequently, set the artifacts version on the new branch to be
> 2.0.5-alpha
> 3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
> 4. At this point I can cut an RC and put it out for re-vote. The staging
> can
> be done after the next two steps.
>
> I will be doing all these modifications in the next hour or so.
>
> Tomorrow at 1 pm PDT I would like to:
> 1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
> 2. update the CHANGES.txt in the trunk and branch-2 to reflect new version
> names
> 3. at this point it should safe to do the staging for 2.0.5-alpha RC
>
> To avoid any collisions during the last two steps - especially 2. - I would
> ask everyone to hold off the modifications of the CHANGES.txt files on
> trunk
> and branch-2 between 1 pm and 2 pm PDT.
>
> Please let me know if you see any flaw above, questions.
>   Cos
>
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> >
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
>
> > I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha
> versions
> > in jira for HADOOP, HDFS, YARN & MAPREDUCE.
>
> > Please take care of the rest.
>
> > Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
>

Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Guys,

I will be performing some changes wrt to moving 2.0.4.1 release candidate to
2.0.5 space. As outline below by Alejandro:

1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
that contains 2.0.4.1 changes
2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
4. At this point I can cut an RC and put it out for re-vote. The staging can
be done after the next two steps.

I will be doing all these modifications in the next hour or so.

Tomorrow at 1 pm PDT I would like to:
1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
3. at this point it should safe to do the staging for 2.0.5-alpha RC

To avoid any collisions during the last two steps - especially 2. - I would
ask everyone to hold off the modifications of the CHANGES.txt files on trunk
and branch-2 between 1 pm and 2 pm PDT.

Please let me know if you see any flaw above, questions.
  Cos

> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

> I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> in jira for HADOOP, HDFS, YARN & MAPREDUCE.

> Please take care of the rest.

> Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Guys,

I will be performing some changes wrt to moving 2.0.4.1 release candidate to
2.0.5 space. As outline below by Alejandro:

1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
that contains 2.0.4.1 changes
2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
4. At this point I can cut an RC and put it out for re-vote. The staging can
be done after the next two steps.

I will be doing all these modifications in the next hour or so.

Tomorrow at 1 pm PDT I would like to:
1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
3. at this point it should safe to do the staging for 2.0.5-alpha RC

To avoid any collisions during the last two steps - especially 2. - I would
ask everyone to hold off the modifications of the CHANGES.txt files on trunk
and branch-2 between 1 pm and 2 pm PDT.

Please let me know if you see any flaw above, questions.
  Cos

> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

> I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> in jira for HADOOP, HDFS, YARN & MAPREDUCE.

> Please take care of the rest.

> Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Thanks for the headstart Arun!

I will be sending a separate email to the *-dev@ lists outlining the plan and
the schedule of the changes, so we won't step on each other feet, like Vinod
expressed earlier.

Cos

On Fri, May 31, 2013 at 11:20AM, Arun C Murthy wrote:
> 
> On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:
> 
> > Konstantin, Cos,
> > 
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> > 
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
> 
> I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> 
> Please take care of the rest.
> 
> Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> 
> thanks,
> Arun
> 
> > 
> > Thanks.
> > 
> > 
> > On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> > 
> >> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> >> wrote:
> >>> I have no issues of changing the version to 2.0.5-alpha and restarting
> >> to vote
> >>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> >> because
> >>> of the number change?
> >> 
> >> +1 Sounds great.
> >> 
> >>> Does the result of bylaw vote nullifies the unfinished vote started by
> >> Arun?
> >>> Sorry, I am dense, apparently.
> >> 
> >> Yes, nobody should feel bound by either vote. The bylaw change
> >> clarifies that release plans are for RMs to solicit feedback and gauge
> >> PMC support for an artifact, not pre-approvals for doing work.
> >> 
> >>> Can we limit the vote thread to the merits of the release then?
> >> 
> >> Happily.
> >> 
> >>> That sound like adding an insult to injury, if my forth-language skills
> >> do not
> >>> mislead me.
> >> 
> >> They do mislead you, or I've expressed the point imprecisely. We can
> >> take this offline. -C
> >> 
> >>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> >> acm@hortonworks.com> 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
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >> 
> > 
> > 
> > 
> > -- 
> > Alejandro
> 
> --
> Arun C. Murthy
> Hortonworks Inc.
> http://hortonworks.com/
> 
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Thanks for the headstart Arun!

I will be sending a separate email to the *-dev@ lists outlining the plan and
the schedule of the changes, so we won't step on each other feet, like Vinod
expressed earlier.

Cos

On Fri, May 31, 2013 at 11:20AM, Arun C Murthy wrote:
> 
> On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:
> 
> > Konstantin, Cos,
> > 
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> > 
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
> 
> I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> 
> Please take care of the rest.
> 
> Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> 
> thanks,
> Arun
> 
> > 
> > Thanks.
> > 
> > 
> > On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> > 
> >> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> >> wrote:
> >>> I have no issues of changing the version to 2.0.5-alpha and restarting
> >> to vote
> >>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> >> because
> >>> of the number change?
> >> 
> >> +1 Sounds great.
> >> 
> >>> Does the result of bylaw vote nullifies the unfinished vote started by
> >> Arun?
> >>> Sorry, I am dense, apparently.
> >> 
> >> Yes, nobody should feel bound by either vote. The bylaw change
> >> clarifies that release plans are for RMs to solicit feedback and gauge
> >> PMC support for an artifact, not pre-approvals for doing work.
> >> 
> >>> Can we limit the vote thread to the merits of the release then?
> >> 
> >> Happily.
> >> 
> >>> That sound like adding an insult to injury, if my forth-language skills
> >> do not
> >>> mislead me.
> >> 
> >> They do mislead you, or I've expressed the point imprecisely. We can
> >> take this offline. -C
> >> 
> >>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> >> acm@hortonworks.com> 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
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >> 
> > 
> > 
> > 
> > -- 
> > Alejandro
> 
> --
> Arun C. Murthy
> Hortonworks Inc.
> http://hortonworks.com/
> 
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Thanks for the headstart Arun!

I will be sending a separate email to the *-dev@ lists outlining the plan and
the schedule of the changes, so we won't step on each other feet, like Vinod
expressed earlier.

Cos

On Fri, May 31, 2013 at 11:20AM, Arun C Murthy wrote:
> 
> On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:
> 
> > Konstantin, Cos,
> > 
> > As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> > housekeeping as you work the new RC.
> > 
> > * rename the svn branch
> > * update the versions in the POMs
> > * update the CHANGES.txt in trunk, branch-2 and the release branch
> > * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> > version, change the fix version of the 2 JIRAs that make the RC
> 
> I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> in jira for HADOOP, HDFS, YARN & MAPREDUCE.
> 
> Please take care of the rest.
> 
> Also, in branch-2, the version should be 2.1.0-SNAPSHOT.
> 
> thanks,
> Arun
> 
> > 
> > Thanks.
> > 
> > 
> > On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> > 
> >> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> >> wrote:
> >>> I have no issues of changing the version to 2.0.5-alpha and restarting
> >> to vote
> >>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> >> because
> >>> of the number change?
> >> 
> >> +1 Sounds great.
> >> 
> >>> Does the result of bylaw vote nullifies the unfinished vote started by
> >> Arun?
> >>> Sorry, I am dense, apparently.
> >> 
> >> Yes, nobody should feel bound by either vote. The bylaw change
> >> clarifies that release plans are for RMs to solicit feedback and gauge
> >> PMC support for an artifact, not pre-approvals for doing work.
> >> 
> >>> Can we limit the vote thread to the merits of the release then?
> >> 
> >> Happily.
> >> 
> >>> That sound like adding an insult to injury, if my forth-language skills
> >> do not
> >>> mislead me.
> >> 
> >> They do mislead you, or I've expressed the point imprecisely. We can
> >> take this offline. -C
> >> 
> >>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> >> acm@hortonworks.com> 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
> >>>>>>>>>> 
> >>>>>>>>> 
> >>>>>>>>> 
> >> 
> > 
> > 
> > 
> > -- 
> > Alejandro
> 
> --
> Arun C. Murthy
> Hortonworks Inc.
> http://hortonworks.com/
> 
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:

> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions in jira for HADOOP, HDFS, YARN & MAPREDUCE.

Please take care of the rest.

Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

thanks,
Arun

> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>> to vote
>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>> because
>>> of the number change?
>> 
>> +1 Sounds great.
>> 
>>> Does the result of bylaw vote nullifies the unfinished vote started by
>> Arun?
>>> Sorry, I am dense, apparently.
>> 
>> Yes, nobody should feel bound by either vote. The bylaw change
>> clarifies that release plans are for RMs to solicit feedback and gauge
>> PMC support for an artifact, not pre-approvals for doing work.
>> 
>>> Can we limit the vote thread to the merits of the release then?
>> 
>> Happily.
>> 
>>> That sound like adding an insult to injury, if my forth-language skills
>> do not
>>> mislead me.
>> 
>> They do mislead you, or I've expressed the point imprecisely. We can
>> take this offline. -C
>> 
>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>> acm@hortonworks.com> 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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>> 
> 
> 
> 
> -- 
> Alejandro

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Vinod Kumar Vavilapalli <vi...@hortonworks.com>.

This started out as something and ended up as something else altogether.

In any case, I think you should give a fresh heads up outside this thread.

There are a bunch of commits and merges happening into branch-2 and thus 2.0.5, so it'll be safe to have an explicit hold-off/all-clear signaling. Otherwise you'll be racing with others on CHANGES.txt commits and the JIRA version set.

Thanks,
+Vinod


On May 30, 2013, at 10:50 PM, Konstantin Boudnik wrote:

> Thanks Alejandro,
> 
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!
> 
> Cos
> 
> On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
>> Konstantin, Cos,
>> 
>> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
>> housekeeping as you work the new RC.
>> 
>> * rename the svn branch
>> * update the versions in the POMs
>> * update the CHANGES.txt in trunk, branch-2 and the release branch
>> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
>> version, change the fix version of the 2 JIRAs that make the RC
>> 
>> Thanks.
>> 
>> 
>> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
>> 
>>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>>> wrote:
>>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>>> to vote
>>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>>> because
>>>> of the number change?
>>> 
>>> +1 Sounds great.
>>> 
>>>> Does the result of bylaw vote nullifies the unfinished vote started by
>>> Arun?
>>>> Sorry, I am dense, apparently.
>>> 
>>> Yes, nobody should feel bound by either vote. The bylaw change
>>> clarifies that release plans are for RMs to solicit feedback and gauge
>>> PMC support for an artifact, not pre-approvals for doing work.
>>> 
>>>> Can we limit the vote thread to the merits of the release then?
>>> 
>>> Happily.
>>> 
>>>> That sound like adding an insult to injury, if my forth-language skills
>>> do not
>>>> mislead me.
>>> 
>>> They do mislead you, or I've expressed the point imprecisely. We can
>>> take this offline. -C
>>> 
>>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>>> acm@hortonworks.com> 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
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Roman Shaposhnik <rv...@apache.org>.

On Thu, May 30, 2013 at 10:50 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Thanks Alejandro,
>
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!

Let me know if I can help in any way. Obviously, I'm going to pull
the 2.0.5-alpha RC into Bigtop the minute it is available, but
if there's anything else I can help with (JIRA manipulation, etc.)
please let me know.

Thanks,
Roman.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Vinod Kumar Vavilapalli <vi...@hortonworks.com>.

This started out as something and ended up as something else altogether.

In any case, I think you should give a fresh heads up outside this thread.

There are a bunch of commits and merges happening into branch-2 and thus 2.0.5, so it'll be safe to have an explicit hold-off/all-clear signaling. Otherwise you'll be racing with others on CHANGES.txt commits and the JIRA version set.

Thanks,
+Vinod


On May 30, 2013, at 10:50 PM, Konstantin Boudnik wrote:

> Thanks Alejandro,
> 
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!
> 
> Cos
> 
> On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
>> Konstantin, Cos,
>> 
>> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
>> housekeeping as you work the new RC.
>> 
>> * rename the svn branch
>> * update the versions in the POMs
>> * update the CHANGES.txt in trunk, branch-2 and the release branch
>> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
>> version, change the fix version of the 2 JIRAs that make the RC
>> 
>> Thanks.
>> 
>> 
>> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
>> 
>>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>>> wrote:
>>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>>> to vote
>>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>>> because
>>>> of the number change?
>>> 
>>> +1 Sounds great.
>>> 
>>>> Does the result of bylaw vote nullifies the unfinished vote started by
>>> Arun?
>>>> Sorry, I am dense, apparently.
>>> 
>>> Yes, nobody should feel bound by either vote. The bylaw change
>>> clarifies that release plans are for RMs to solicit feedback and gauge
>>> PMC support for an artifact, not pre-approvals for doing work.
>>> 
>>>> Can we limit the vote thread to the merits of the release then?
>>> 
>>> Happily.
>>> 
>>>> That sound like adding an insult to injury, if my forth-language skills
>>> do not
>>>> mislead me.
>>> 
>>> They do mislead you, or I've expressed the point imprecisely. We can
>>> take this offline. -C
>>> 
>>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>>> acm@hortonworks.com> 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
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Vinod Kumar Vavilapalli <vi...@hortonworks.com>.

This started out as something and ended up as something else altogether.

In any case, I think you should give a fresh heads up outside this thread.

There are a bunch of commits and merges happening into branch-2 and thus 2.0.5, so it'll be safe to have an explicit hold-off/all-clear signaling. Otherwise you'll be racing with others on CHANGES.txt commits and the JIRA version set.

Thanks,
+Vinod


On May 30, 2013, at 10:50 PM, Konstantin Boudnik wrote:

> Thanks Alejandro,
> 
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!
> 
> Cos
> 
> On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
>> Konstantin, Cos,
>> 
>> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
>> housekeeping as you work the new RC.
>> 
>> * rename the svn branch
>> * update the versions in the POMs
>> * update the CHANGES.txt in trunk, branch-2 and the release branch
>> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
>> version, change the fix version of the 2 JIRAs that make the RC
>> 
>> Thanks.
>> 
>> 
>> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
>> 
>>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>>> wrote:
>>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>>> to vote
>>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>>> because
>>>> of the number change?
>>> 
>>> +1 Sounds great.
>>> 
>>>> Does the result of bylaw vote nullifies the unfinished vote started by
>>> Arun?
>>>> Sorry, I am dense, apparently.
>>> 
>>> Yes, nobody should feel bound by either vote. The bylaw change
>>> clarifies that release plans are for RMs to solicit feedback and gauge
>>> PMC support for an artifact, not pre-approvals for doing work.
>>> 
>>>> Can we limit the vote thread to the merits of the release then?
>>> 
>>> Happily.
>>> 
>>>> That sound like adding an insult to injury, if my forth-language skills
>>> do not
>>>> mislead me.
>>> 
>>> They do mislead you, or I've expressed the point imprecisely. We can
>>> take this offline. -C
>>> 
>>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>>> acm@hortonworks.com> 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
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Roman Shaposhnik <rv...@apache.org>.

On Thu, May 30, 2013 at 10:50 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Thanks Alejandro,
>
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!

Let me know if I can help in any way. Obviously, I'm going to pull
the 2.0.5-alpha RC into Bigtop the minute it is available, but
if there's anything else I can help with (JIRA manipulation, etc.)
please let me know.

Thanks,
Roman.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Roman Shaposhnik <rv...@apache.org>.

On Thu, May 30, 2013 at 10:50 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Thanks Alejandro,
>
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!

Let me know if I can help in any way. Obviously, I'm going to pull
the 2.0.5-alpha RC into Bigtop the minute it is available, but
if there's anything else I can help with (JIRA manipulation, etc.)
please let me know.

Thanks,
Roman.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Vinod Kumar Vavilapalli <vi...@hortonworks.com>.

This started out as something and ended up as something else altogether.

In any case, I think you should give a fresh heads up outside this thread.

There are a bunch of commits and merges happening into branch-2 and thus 2.0.5, so it'll be safe to have an explicit hold-off/all-clear signaling. Otherwise you'll be racing with others on CHANGES.txt commits and the JIRA version set.

Thanks,
+Vinod


On May 30, 2013, at 10:50 PM, Konstantin Boudnik wrote:

> Thanks Alejandro,
> 
> that's what my plan for the morning. Thanks for putting together the
> check-list - would be easier for me not to miss anything. I am aiming to have
> the bits out by noon or so. Appreciate the help!
> 
> Cos
> 
> On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
>> Konstantin, Cos,
>> 
>> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
>> housekeeping as you work the new RC.
>> 
>> * rename the svn branch
>> * update the versions in the POMs
>> * update the CHANGES.txt in trunk, branch-2 and the release branch
>> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
>> version, change the fix version of the 2 JIRAs that make the RC
>> 
>> Thanks.
>> 
>> 
>> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
>> 
>>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>>> wrote:
>>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>>> to vote
>>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>>> because
>>>> of the number change?
>>> 
>>> +1 Sounds great.
>>> 
>>>> Does the result of bylaw vote nullifies the unfinished vote started by
>>> Arun?
>>>> Sorry, I am dense, apparently.
>>> 
>>> Yes, nobody should feel bound by either vote. The bylaw change
>>> clarifies that release plans are for RMs to solicit feedback and gauge
>>> PMC support for an artifact, not pre-approvals for doing work.
>>> 
>>>> Can we limit the vote thread to the merits of the release then?
>>> 
>>> Happily.
>>> 
>>>> That sound like adding an insult to injury, if my forth-language skills
>>> do not
>>>> mislead me.
>>> 
>>> They do mislead you, or I've expressed the point imprecisely. We can
>>> take this offline. -C
>>> 
>>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>>> acm@hortonworks.com> 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
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Thanks Alejandro,

that's what my plan for the morning. Thanks for putting together the
check-list - would be easier for me not to miss anything. I am aiming to have
the bits out by noon or so. Appreciate the help!

Cos

On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
> 
> 
> 
> -- 
> Alejandro

Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Guys,

I will be performing some changes wrt to moving 2.0.4.1 release candidate to
2.0.5 space. As outline below by Alejandro:

1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
that contains 2.0.4.1 changes
2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
4. At this point I can cut an RC and put it out for re-vote. The staging can
be done after the next two steps.

I will be doing all these modifications in the next hour or so.

Tomorrow at 1 pm PDT I would like to:
1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
3. at this point it should safe to do the staging for 2.0.5-alpha RC

To avoid any collisions during the last two steps - especially 2. - I would
ask everyone to hold off the modifications of the CHANGES.txt files on trunk
and branch-2 between 1 pm and 2 pm PDT.

Please let me know if you see any flaw above, questions.
  Cos

> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

> I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> in jira for HADOOP, HDFS, YARN & MAPREDUCE.

> Please take care of the rest.

> Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Heads up: moving from 2.0.4.1-alpha to 2.0.5-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Guys,

I will be performing some changes wrt to moving 2.0.4.1 release candidate to
2.0.5 space. As outline below by Alejandro:

1. I will create new 2.0.5-alpha branch from the current head of 2.0.4-alpha
that contains 2.0.4.1 changes
2. consequently, set the artifacts version on the new branch to be 2.0.5-alpha
3. the CHANGES.txt will be updated accordingly on the new 2.0.5 branch
4. At this point I can cut an RC and put it out for re-vote. The staging can
be done after the next two steps.

I will be doing all these modifications in the next hour or so.

Tomorrow at 1 pm PDT I would like to:
1. update the version of the artifacts on branch-2 to become 2.1.0-SNAPSHOT
2. update the CHANGES.txt in the trunk and branch-2 to reflect new version names
3. at this point it should safe to do the staging for 2.0.5-alpha RC

To avoid any collisions during the last two steps - especially 2. - I would
ask everyone to hold off the modifications of the CHANGES.txt files on trunk
and branch-2 between 1 pm and 2 pm PDT.

Please let me know if you see any flaw above, questions.
  Cos

> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

> I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions
> in jira for HADOOP, HDFS, YARN & MAPREDUCE.

> Please take care of the rest.

> Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Thanks Alejandro,

that's what my plan for the morning. Thanks for putting together the
check-list - would be easier for me not to miss anything. I am aiming to have
the bits out by noon or so. Appreciate the help!

Cos

On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
> 
> 
> 
> -- 
> Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

Sounds like a plan.

Thanks,
--Konst


On Thu, May 30, 2013 at 8:41 PM, Alejandro Abdelnur <tu...@cloudera.com>wrote:

> Konstantin, Cos,
>
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
>
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
>
> Thanks.
>
>
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org>
> wrote:
>
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
>
>
>
> --
> Alejandro
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:

> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions in jira for HADOOP, HDFS, YARN & MAPREDUCE.

Please take care of the rest.

Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

thanks,
Arun

> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>> to vote
>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>> because
>>> of the number change?
>> 
>> +1 Sounds great.
>> 
>>> Does the result of bylaw vote nullifies the unfinished vote started by
>> Arun?
>>> Sorry, I am dense, apparently.
>> 
>> Yes, nobody should feel bound by either vote. The bylaw change
>> clarifies that release plans are for RMs to solicit feedback and gauge
>> PMC support for an artifact, not pre-approvals for doing work.
>> 
>>> Can we limit the vote thread to the merits of the release then?
>> 
>> Happily.
>> 
>>> That sound like adding an insult to injury, if my forth-language skills
>> do not
>>> mislead me.
>> 
>> They do mislead you, or I've expressed the point imprecisely. We can
>> take this offline. -C
>> 
>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>> acm@hortonworks.com> 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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>> 
> 
> 
> 
> -- 
> Alejandro

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

Sounds like a plan.

Thanks,
--Konst


On Thu, May 30, 2013 at 8:41 PM, Alejandro Abdelnur <tu...@cloudera.com>wrote:

> Konstantin, Cos,
>
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
>
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
>
> Thanks.
>
>
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org>
> wrote:
>
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
>
>
>
> --
> Alejandro
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

Sounds like a plan.

Thanks,
--Konst


On Thu, May 30, 2013 at 8:41 PM, Alejandro Abdelnur <tu...@cloudera.com>wrote:

> Konstantin, Cos,
>
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
>
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
>
> Thanks.
>
>
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org>
> wrote:
>
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
>
>
>
> --
> Alejandro
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Thanks Alejandro,

that's what my plan for the morning. Thanks for putting together the
check-list - would be easier for me not to miss anything. I am aiming to have
the bits out by noon or so. Appreciate the help!

Cos

On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
> 
> 
> 
> -- 
> Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Thanks Alejandro,

that's what my plan for the morning. Thanks for putting together the
check-list - would be easier for me not to miss anything. I am aiming to have
the bits out by noon or so. Appreciate the help!

Cos

On Thu, May 30, 2013 at 08:41PM, Alejandro Abdelnur wrote:
> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC
> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
> > On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I have no issues of changing the version to 2.0.5-alpha and restarting
> > to vote
> > > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> > because
> > > of the number change?
> >
> > +1 Sounds great.
> >
> > > Does the result of bylaw vote nullifies the unfinished vote started by
> > Arun?
> > > Sorry, I am dense, apparently.
> >
> > Yes, nobody should feel bound by either vote. The bylaw change
> > clarifies that release plans are for RMs to solicit feedback and gauge
> > PMC support for an artifact, not pre-approvals for doing work.
> >
> > > Can we limit the vote thread to the merits of the release then?
> >
> > Happily.
> >
> > > That sound like adding an insult to injury, if my forth-language skills
> > do not
> > > mislead me.
> >
> > They do mislead you, or I've expressed the point imprecisely. We can
> > take this offline. -C
> >
> > >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> > >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> > acm@hortonworks.com> 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
> > >> >> >> >>
> > >> >> >> >
> > >> >> >> >
> >
> 
> 
> 
> -- 
> Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:

> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions in jira for HADOOP, HDFS, YARN & MAPREDUCE.

Please take care of the rest.

Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

thanks,
Arun

> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>> to vote
>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>> because
>>> of the number change?
>> 
>> +1 Sounds great.
>> 
>>> Does the result of bylaw vote nullifies the unfinished vote started by
>> Arun?
>>> Sorry, I am dense, apparently.
>> 
>> Yes, nobody should feel bound by either vote. The bylaw change
>> clarifies that release plans are for RMs to solicit feedback and gauge
>> PMC support for an artifact, not pre-approvals for doing work.
>> 
>>> Can we limit the vote thread to the merits of the release then?
>> 
>> Happily.
>> 
>>> That sound like adding an insult to injury, if my forth-language skills
>> do not
>>> mislead me.
>> 
>> They do mislead you, or I've expressed the point imprecisely. We can
>> take this offline. -C
>> 
>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>> acm@hortonworks.com> 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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>> 
> 
> 
> 
> -- 
> Alejandro

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

On May 30, 2013, at 8:41 PM, Alejandro Abdelnur wrote:

> Konstantin, Cos,
> 
> As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
> housekeeping as you work the new RC.
> 
> * rename the svn branch
> * update the versions in the POMs
> * update the CHANGES.txt in trunk, branch-2 and the release branch
> * change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
> version, change the fix version of the 2 JIRAs that make the RC

I renamed 2.0.5-beta to 2.1.0-beta and 2.0.4.1-alpha to 2.0.5-alpha versions in jira for HADOOP, HDFS, YARN & MAPREDUCE.

Please take care of the rest.

Also, in branch-2, the version should be 2.1.0-SNAPSHOT.

thanks,
Arun

> 
> Thanks.
> 
> 
> On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:
> 
>> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>> I have no issues of changing the version to 2.0.5-alpha and restarting
>> to vote
>>> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
>> because
>>> of the number change?
>> 
>> +1 Sounds great.
>> 
>>> Does the result of bylaw vote nullifies the unfinished vote started by
>> Arun?
>>> Sorry, I am dense, apparently.
>> 
>> Yes, nobody should feel bound by either vote. The bylaw change
>> clarifies that release plans are for RMs to solicit feedback and gauge
>> PMC support for an artifact, not pre-approvals for doing work.
>> 
>>> Can we limit the vote thread to the merits of the release then?
>> 
>> Happily.
>> 
>>> That sound like adding an insult to injury, if my forth-language skills
>> do not
>>> mislead me.
>> 
>> They do mislead you, or I've expressed the point imprecisely. We can
>> take this offline. -C
>> 
>>>>>>> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>>>>>>>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
>> acm@hortonworks.com> 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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>> 
> 
> 
> 
> -- 
> Alejandro

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Konstantin, Cos,

As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
housekeeping as you work the new RC.

* rename the svn branch
* update the versions in the POMs
* update the CHANGES.txt in trunk, branch-2 and the release branch
* change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
version, change the fix version of the 2 JIRAs that make the RC

Thanks.


On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting
> to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> because
> > of the number change?
>
> +1 Sounds great.
>
> > Does the result of bylaw vote nullifies the unfinished vote started by
> Arun?
> > Sorry, I am dense, apparently.
>
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
>
> > Can we limit the vote thread to the merits of the release then?
>
> Happily.
>
> > That sound like adding an insult to injury, if my forth-language skills
> do not
> > mislead me.
>
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
>
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> acm@hortonworks.com> 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
> >> >> >> >>
> >> >> >> >
> >> >> >> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Chris,

with 2.0.5-alpha (rc1) out, would you please take a look at the release bits?
I assume the four-digit numbering scheme issue has been resolved now.

Regards,
  Cos

On Thu, May 30, 2013 at 06:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> > of the number change?
> 
> +1 Sounds great.
> 
> > Does the result of bylaw vote nullifies the unfinished vote started by Arun?
> > Sorry, I am dense, apparently.
> 
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
> 
> > Can we limit the vote thread to the merits of the release then?
> 
> Happily.
> 
> > That sound like adding an insult to injury, if my forth-language skills do not
> > mislead me.
> 
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
> 
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
> >> >> >> >>
> >> >> >> >
> >> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Chris,

with 2.0.5-alpha (rc1) out, would you please take a look at the release bits?
I assume the four-digit numbering scheme issue has been resolved now.

Regards,
  Cos

On Thu, May 30, 2013 at 06:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> > of the number change?
> 
> +1 Sounds great.
> 
> > Does the result of bylaw vote nullifies the unfinished vote started by Arun?
> > Sorry, I am dense, apparently.
> 
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
> 
> > Can we limit the vote thread to the merits of the release then?
> 
> Happily.
> 
> > That sound like adding an insult to injury, if my forth-language skills do not
> > mislead me.
> 
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
> 
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
> >> >> >> >>
> >> >> >> >
> >> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

Chris,

with 2.0.5-alpha (rc1) out, would you please take a look at the release bits?
I assume the four-digit numbering scheme issue has been resolved now.

Regards,
  Cos

On Thu, May 30, 2013 at 06:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> > of the number change?
> 
> +1 Sounds great.
> 
> > Does the result of bylaw vote nullifies the unfinished vote started by Arun?
> > Sorry, I am dense, apparently.
> 
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
> 
> > Can we limit the vote thread to the merits of the release then?
> 
> Happily.
> 
> > That sound like adding an insult to injury, if my forth-language skills do not
> > mislead me.
> 
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
> 
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
> >> >> >> >>
> >> >> >> >
> >> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Konstantin, Cos,

As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
housekeeping as you work the new RC.

* rename the svn branch
* update the versions in the POMs
* update the CHANGES.txt in trunk, branch-2 and the release branch
* change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
version, change the fix version of the 2 JIRAs that make the RC

Thanks.


On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting
> to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> because
> > of the number change?
>
> +1 Sounds great.
>
> > Does the result of bylaw vote nullifies the unfinished vote started by
> Arun?
> > Sorry, I am dense, apparently.
>
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
>
> > Can we limit the vote thread to the merits of the release then?
>
> Happily.
>
> > That sound like adding an insult to injury, if my forth-language skills
> do not
> > mislead me.
>
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
>
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> acm@hortonworks.com> 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
> >> >> >> >>
> >> >> >> >
> >> >> >> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Konstantin, Cos,

As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
housekeeping as you work the new RC.

* rename the svn branch
* update the versions in the POMs
* update the CHANGES.txt in trunk, branch-2 and the release branch
* change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
version, change the fix version of the 2 JIRAs that make the RC

Thanks.


On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting
> to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> because
> > of the number change?
>
> +1 Sounds great.
>
> > Does the result of bylaw vote nullifies the unfinished vote started by
> Arun?
> > Sorry, I am dense, apparently.
>
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
>
> > Can we limit the vote thread to the merits of the release then?
>
> Happily.
>
> > That sound like adding an insult to injury, if my forth-language skills
> do not
> > mislead me.
>
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
>
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> acm@hortonworks.com> 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
> >> >> >> >>
> >> >> >> >
> >> >> >> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

Konstantin, Cos,

As we change from 2.0.4.1 to 2.0.5 you'll need to do the following
housekeeping as you work the new RC.

* rename the svn branch
* update the versions in the POMs
* update the CHANGES.txt in trunk, branch-2 and the release branch
* change the current 2.0.5 version in JIRA to 2.1.0, create a new 2.0.5
version, change the fix version of the 2 JIRAs that make the RC

Thanks.


On Thu, May 30, 2013 at 6:18 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > I have no issues of changing the version to 2.0.5-alpha and restarting
> to vote
> > for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote
> because
> > of the number change?
>
> +1 Sounds great.
>
> > Does the result of bylaw vote nullifies the unfinished vote started by
> Arun?
> > Sorry, I am dense, apparently.
>
> Yes, nobody should feel bound by either vote. The bylaw change
> clarifies that release plans are for RMs to solicit feedback and gauge
> PMC support for an artifact, not pre-approvals for doing work.
>
> > Can we limit the vote thread to the merits of the release then?
>
> Happily.
>
> > That sound like adding an insult to injury, if my forth-language skills
> do not
> > mislead me.
>
> They do mislead you, or I've expressed the point imprecisely. We can
> take this offline. -C
>
> >> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
> >> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <
> acm@hortonworks.com> 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
> >> >> >> >>
> >> >> >> >
> >> >> >> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> of the number change?

+1 Sounds great.

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

Yes, nobody should feel bound by either vote. The bylaw change
clarifies that release plans are for RMs to solicit feedback and gauge
PMC support for an artifact, not pre-approvals for doing work.

> Can we limit the vote thread to the merits of the release then?

Happily.

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

They do mislead you, or I've expressed the point imprecisely. We can
take this offline. -C

>> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >> >>
>> >> >> >
>> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> of the number change?

+1 Sounds great.

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

Yes, nobody should feel bound by either vote. The bylaw change
clarifies that release plans are for RMs to solicit feedback and gauge
PMC support for an artifact, not pre-approvals for doing work.

> Can we limit the vote thread to the merits of the release then?

Happily.

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

They do mislead you, or I've expressed the point imprecisely. We can
take this offline. -C

>> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >> >>
>> >> >> >
>> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> of the number change?

+1 Sounds great.

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

Yes, nobody should feel bound by either vote. The bylaw change
clarifies that release plans are for RMs to solicit feedback and gauge
PMC support for an artifact, not pre-approvals for doing work.

> Can we limit the vote thread to the merits of the release then?

Happily.

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

They do mislead you, or I've expressed the point imprecisely. We can
take this offline. -C

>> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >> >>
>> >> >> >
>> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 5:51 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I have no issues of changing the version to 2.0.5-alpha and restarting to vote
> for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
> of the number change?

+1 Sounds great.

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

Yes, nobody should feel bound by either vote. The bylaw change
clarifies that release plans are for RMs to solicit feedback and gauge
PMC support for an artifact, not pre-approvals for doing work.

> Can we limit the vote thread to the merits of the release then?

Happily.

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

They do mislead you, or I've expressed the point imprecisely. We can
take this offline. -C

>> >> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >> >>
>> >> >> >
>> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

On Thu, May 30, 2013 at 05:30PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <co...@apache.org> 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 vote
for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
of 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 not
mislead 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 <ac...@hortonworks.com> 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
> >> >> >>
> >> >> >
> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

On Thu, May 30, 2013 at 05:30PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <co...@apache.org> 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 vote
for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
of 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 not
mislead 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 <ac...@hortonworks.com> 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
> >> >> >>
> >> >> >
> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

On Thu, May 30, 2013 at 05:30PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <co...@apache.org> 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 vote
for the release content, e.g. 2 bug fixes. Shall I call 3 days re-vote because
of 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 not
mislead 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 <ac...@hortonworks.com> 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
> >> >> >>
> >> >> >
> >> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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.

> 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.

> 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

>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >>
>> >> >
>> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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.

> 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.

> 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

>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >>
>> >> >
>> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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.

> 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.

> 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

>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >>
>> >> >
>> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 3:25 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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.

> 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.

> 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

>> > On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> >> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >> >>
>> >> >
>> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

On Thu, May 30, 2013 at 03:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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-fix
release, 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 vote
started by Arun to override the results of the Konstantin's vote never been
closed. The downstream projects are handing in the middle of the air because
of 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 <ac...@hortonworks.com> 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
> >> >>
> >> >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

On Thu, May 30, 2013 at 03:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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-fix
release, 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 vote
started by Arun to override the results of the Konstantin's vote never been
closed. The downstream projects are handing in the middle of the air because
of 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 <ac...@hortonworks.com> 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
> >> >>
> >> >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

On Thu, May 30, 2013 at 03:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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-fix
release, 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 vote
started by Arun to override the results of the Konstantin's vote never been
closed. The downstream projects are handing in the middle of the air because
of 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 <ac...@hortonworks.com> 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
> >> >>
> >> >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

On Thu, May 30, 2013 at 03:18PM, Chris Douglas wrote:
> On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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-fix
release, 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 vote
started by Arun to override the results of the Konstantin's vote never been
closed. The downstream projects are handing in the middle of the air because
of 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 <ac...@hortonworks.com> 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
> >> >>
> >> >
> >> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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

> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >>
>> >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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

> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >>
>> >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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

> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >>
>> >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 2:39 PM, Konstantin Boudnik <co...@apache.org> 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.

> 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

> On Thu, May 30, 2013 at 01:48PM, Chris Douglas wrote:
>> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>> >>
>> >
>> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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?

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 <ac...@hortonworks.com> 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
> >>
> >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

On the version number we use, if it is greater than 2.0.4, I really don't
care. Though I think Konstantin argument that branch-2 is publishing as
2.0.5-SNAPSHOT has some ground (still, it could be argued that they are DEV
JARs so they can be  in flux).

On the changes that went into this RC, they are exactly a fix for Sqoop2 to
work with the release and a build fix for Bigtop. As far as I can tell
there is nothing else in this RC as compared with 2.0.4-alpha.

So, effectively, this RC is just a fixup of 2.0.4 for Sqoop and Bigtop.

MAPREDUCE-5211 seems nasty enough to be included.

But I'd leave that to the RM (Cos in this case) to decide if  he wants to
go ahead without  it and then do a 2.0.4.2. Personally i would cut a second
RC including MAPREDUCE-5211. But I don't think that not having it would be
reason enough for a -1 (if that is the reason for the -1).

Thanks.

On Thu, May 30, 2013 at 1:48 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com>
> 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
> >>
> >
> >
>

-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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?

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 <ac...@hortonworks.com> 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
> >>
> >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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?

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 <ac...@hortonworks.com> 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
> >>
> >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

On the version number we use, if it is greater than 2.0.4, I really don't
care. Though I think Konstantin argument that branch-2 is publishing as
2.0.5-SNAPSHOT has some ground (still, it could be argued that they are DEV
JARs so they can be  in flux).

On the changes that went into this RC, they are exactly a fix for Sqoop2 to
work with the release and a build fix for Bigtop. As far as I can tell
there is nothing else in this RC as compared with 2.0.4-alpha.

So, effectively, this RC is just a fixup of 2.0.4 for Sqoop and Bigtop.

MAPREDUCE-5211 seems nasty enough to be included.

But I'd leave that to the RM (Cos in this case) to decide if  he wants to
go ahead without  it and then do a 2.0.4.2. Personally i would cut a second
RC including MAPREDUCE-5211. But I don't think that not having it would be
reason enough for a -1 (if that is the reason for the -1).

Thanks.

On Thu, May 30, 2013 at 1:48 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com>
> 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
> >>
> >
> >
>

-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

On the version number we use, if it is greater than 2.0.4, I really don't
care. Though I think Konstantin argument that branch-2 is publishing as
2.0.5-SNAPSHOT has some ground (still, it could be argued that they are DEV
JARs so they can be  in flux).

On the changes that went into this RC, they are exactly a fix for Sqoop2 to
work with the release and a build fix for Bigtop. As far as I can tell
there is nothing else in this RC as compared with 2.0.4-alpha.

So, effectively, this RC is just a fixup of 2.0.4 for Sqoop and Bigtop.

MAPREDUCE-5211 seems nasty enough to be included.

But I'd leave that to the RM (Cos in this case) to decide if  he wants to
go ahead without  it and then do a 2.0.4.2. Personally i would cut a second
RC including MAPREDUCE-5211. But I don't think that not having it would be
reason enough for a -1 (if that is the reason for the -1).

Thanks.

On Thu, May 30, 2013 at 1:48 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com>
> 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
> >>
> >
> >
>

-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

On the version number we use, if it is greater than 2.0.4, I really don't
care. Though I think Konstantin argument that branch-2 is publishing as
2.0.5-SNAPSHOT has some ground (still, it could be argued that they are DEV
JARs so they can be  in flux).

On the changes that went into this RC, they are exactly a fix for Sqoop2 to
work with the release and a build fix for Bigtop. As far as I can tell
there is nothing else in this RC as compared with 2.0.4-alpha.

So, effectively, this RC is just a fixup of 2.0.4 for Sqoop and Bigtop.

MAPREDUCE-5211 seems nasty enough to be included.

But I'd leave that to the RM (Cos in this case) to decide if  he wants to
go ahead without  it and then do a 2.0.4.2. Personally i would cut a second
RC including MAPREDUCE-5211. But I don't think that not having it would be
reason enough for a -1 (if that is the reason for the -1).

Thanks.

On Thu, May 30, 2013 at 1:48 PM, Chris Douglas <cd...@apache.org> wrote:

> On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com>
> 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
> >>
> >
> >
>

-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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?

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 <ac...@hortonworks.com> 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
> >>
> >
> >

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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
> > 
> 
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

> Why not call this 2.0.5-alpha?

Technically, current branch-2 uses 2.0.5-SNAPSHOT and produces maven
artifacts 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.

Thanks,
--Konst


On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

> 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
> >
>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

> Why not call this 2.0.5-alpha?

Technically, current branch-2 uses 2.0.5-SNAPSHOT and produces maven
artifacts 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.

Thanks,
--Konst


On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

> 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
> >
>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

Sorry, it should be MAPREDUCE-5211 (not MAPREDUCE-4211).

thanks,
Arun

On May 30, 2013, at 10:57 AM, Arun C Murthy wrote:

> 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
>> 
> 
> 

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Boudnik <co...@apache.org>.

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
> > 
> 
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

> Why not call this 2.0.5-alpha?

Technically, current branch-2 uses 2.0.5-SNAPSHOT and produces maven
artifacts 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.

Thanks,
--Konst


On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> wrote:

> 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
> >
>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

On Thu, May 30, 2013 at 10:57 AM, Arun C Murthy <ac...@hortonworks.com> 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
>>
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

Sorry, it should be MAPREDUCE-5211 (not MAPREDUCE-4211).

thanks,
Arun

On May 30, 2013, at 10:57 AM, Arun C Murthy wrote:

> 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
>> 
> 
> 

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

Sorry, it should be MAPREDUCE-5211 (not MAPREDUCE-4211).

thanks,
Arun

On May 30, 2013, at 10:57 AM, Arun C Murthy wrote:

> 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
>> 
> 
> 

--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

+1

Checksum and signature match, ran some unit tests, verified w/ a diff
of release-2.0.4-alpha that the release contains MAPREDUCE-5240 and
HADOOP-9407, plus some fixups to the release notes. -C

On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Anatoli Fomenko <af...@yahoo.com>.

+1 (non-binding)

Anatoli

----- Original Message -----
From: Konstantin Boudnik <co...@apache.org>
To: common-dev@hadoop.apache.org; hdfs-dev@hadoop.apache.org; mapreduce-dev@hadoop.apache.org; yarn-dev@hadoop.apache.org
Cc: 
Sent: Friday, May 24, 2013 8:48 PM
Subject: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

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

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

+1, verified MD5 and signature. Did a full build, started pseudo cluster,
run a few MR jobs, verified httpfs works.

Thanks.


On Sat, May 25, 2013 at 10:01 AM, Sangjin Lee <sj...@apache.org> wrote:

> +1 (non-binding)
>
> Thanks,
> Sangjin
>
>
> On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org>
> 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
> >
> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

+1, verified MD5 and signature. Did a full build, started pseudo cluster,
run a few MR jobs, verified httpfs works.

Thanks.


On Sat, May 25, 2013 at 10:01 AM, Sangjin Lee <sj...@apache.org> wrote:

> +1 (non-binding)
>
> Thanks,
> Sangjin
>
>
> On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org>
> 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
> >
> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

+1, verified MD5 and signature. Did a full build, started pseudo cluster,
run a few MR jobs, verified httpfs works.

Thanks.


On Sat, May 25, 2013 at 10:01 AM, Sangjin Lee <sj...@apache.org> wrote:

> +1 (non-binding)
>
> Thanks,
> Sangjin
>
>
> On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org>
> 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
> >
> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Alejandro Abdelnur <tu...@cloudera.com>.

+1, verified MD5 and signature. Did a full build, started pseudo cluster,
run a few MR jobs, verified httpfs works.

Thanks.


On Sat, May 25, 2013 at 10:01 AM, Sangjin Lee <sj...@apache.org> wrote:

> +1 (non-binding)
>
> Thanks,
> Sangjin
>
>
> On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org>
> 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
> >
> >
>



-- 
Alejandro

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Sangjin Lee <sj...@apache.org>.

+1 (non-binding)

Thanks,
Sangjin


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Sangjin Lee <sj...@apache.org>.

+1 (non-binding)

Thanks,
Sangjin


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

+1

Checksum and signature match, ran some unit tests, verified w/ a diff
of release-2.0.4-alpha that the release contains MAPREDUCE-5240 and
HADOOP-9407, plus some fixups to the release notes. -C

On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Sangjin Lee <sj...@apache.org>.

+1 (non-binding)

Thanks,
Sangjin


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

+1
I verified checksums, the signature, built sources on CentOS, ran tests and
a few hadoop commands.

Thanks,
--Konst


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

+1
I verified checksums, the signature, built sources on CentOS, ran tests and
a few hadoop commands.

Thanks,
--Konst


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

+1

Checksum and signature match, ran some unit tests, verified w/ a diff
of release-2.0.4-alpha that the release contains MAPREDUCE-5240 and
HADOOP-9407, plus some fixups to the release notes. -C

On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Chris Douglas <cd...@apache.org>.

+1

Checksum and signature match, ran some unit tests, verified w/ a diff
of release-2.0.4-alpha that the release contains MAPREDUCE-5240 and
HADOOP-9407, plus some fixups to the release notes. -C

On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Arun C Murthy <ac...@hortonworks.com>.

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
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

+1
I verified checksums, the signature, built sources on CentOS, ran tests and
a few hadoop commands.

Thanks,
--Konst


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>
>

Re: [VOTE] Release Apache Hadoop 2.0.4.1-alpha

Posted by Konstantin Shvachko <sh...@gmail.com>.

+1
I verified checksums, the signature, built sources on CentOS, ran tests and
a few hadoop commands.

Thanks,
--Konst


On Fri, May 24, 2013 at 8:48 PM, Konstantin Boudnik <co...@apache.org> 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
>
>