[VOTE] - Release 2.0.5-beta

classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[VOTE] - Release 2.0.5-beta

Arun Murthy
Folks,

A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc.

IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as "seizing the moment". There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention.

To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration.

I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content:
# HDFS-347
# HDFS Snapshots
# Windows support
# Necessary & final API/protocol changes such as:
 * Final YARN API changes: YARN-386
 * MR Binary Compatibility: MAPREDUCE-5108
 * Final RPC cleanup: HADOOP-8990

People working on the above features have all expressed considerable comfort with them and are ready to stand-by to help expedite any necessary bug-fixes etc. to get to stabilization quickly. I'm confident we can get this release out by end of May. This sets stage for a hadoop-2.x GA release right after with some more testing - this means I think I can quickly turn around and make bug-fix releases as necessary right after 2.0.5-beta.

I request that people consider helping out with this plan and sign up to help push hadoop-2.x to stability as outlined above. I believe this will help achieve our shared goals of quickly stabilizing hadoop-2 and help ensure we can support it for forseeable future in a compatible manner for the benefit of our users and downstream projects.

Please vote, the vote will run the normal 7 days. Obviously, I'm +1.

thanks,
Arun

PS: To keep this discussion grounded in technical details I've moved this to dev@ (bcc general@).

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Suresh Srinivas-2
This is the course that we were taking before the unfortunate disruption.
We should be able to meet both the stabilization goals and compatibility
goals quickly with this proposal. I personally am willing to invest a lot
of time in testing, code reviews and work on adding missing functionality
to ensure the goal of this proposal is successful.

+1.


On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]> wrote:

> Folks,
>
> A considerable number of people have expressed confusion regarding the
> recent vote on 2.0.5, beta status etc. given lack of specifics, the voting
> itself (validity of the vote itself, whose votes are binding) etc.
>
> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability
> of 3 features under debate etc.) have been lost in the discussion in favor
> of non-technical (almost dramatic) nuances such as "seizing the moment".
> There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1)
> - this is a red flag for me; particularly when there are just 3 features
> being debated and active committers and contributors are confident of and
> ready to stand by their work. All patches, I believe, are ready to be
> merged in the the next few days per discussions on jira. This will,
> clearly, not delay the other API work which everyone agrees is crucial. As
> a result, I feel no recourse but to restart a new vote - all attempts at
> calm, reasoned, civil discussion based on technical arguments have come to
> naught - I apologize for the thrash caused to everyone's attention.
>
> To get past all of this confusion, I'd like to present an alternate,
> specific proposal for consideration.
>
> I propose we continue the original plan and make a 2.0.5-beta release by
> May end with the following content:
> # HDFS-347
> # HDFS Snapshots
> # Windows support
> # Necessary & final API/protocol changes such as:
>  * Final YARN API changes: YARN-386
>  * MR Binary Compatibility: MAPREDUCE-5108
>  * Final RPC cleanup: HADOOP-8990
>
> People working on the above features have all expressed considerable
> comfort with them and are ready to stand-by to help expedite any necessary
> bug-fixes etc. to get to stabilization quickly. I'm confident we can get
> this release out by end of May. This sets stage for a hadoop-2.x GA release
> right after with some more testing - this means I think I can quickly turn
> around and make bug-fix releases as necessary right after 2.0.5-beta.
>
> I request that people consider helping out with this plan and sign up to
> help push hadoop-2.x to stability as outlined above. I believe this will
> help achieve our shared goals of quickly stabilizing hadoop-2 and help
> ensure we can support it for forseeable future in a compatible manner for
> the benefit of our users and downstream projects.
>
> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>
> thanks,
> Arun
>
> PS: To keep this discussion grounded in technical details I've moved this
> to dev@ (bcc general@).
>
>


--
http://hortonworks.com/download/
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Vinod Vavilapalli
In reply to this post by Arun Murthy

Seems like you forgot to bcc. Forwarding this to general.

Thanks,
+Vinod
On May 15, 2013, at 10:57 AM, Arun C Murthy wrote:

> Folks,
>
> A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc.
>
> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as "seizing the moment". There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention.
>
> To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration.
>
> I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content:
> # HDFS-347
> # HDFS Snapshots
> # Windows support
> # Necessary & final API/protocol changes such as:
> * Final YARN API changes: YARN-386
> * MR Binary Compatibility: MAPREDUCE-5108
> * Final RPC cleanup: HADOOP-8990
>
> People working on the above features have all expressed considerable comfort with them and are ready to stand-by to help expedite any necessary bug-fixes etc. to get to stabilization quickly. I'm confident we can get this release out by end of May. This sets stage for a hadoop-2.x GA release right after with some more testing - this means I think I can quickly turn around and make bug-fix releases as necessary right after 2.0.5-beta.
>
> I request that people consider helping out with this plan and sign up to help push hadoop-2.x to stability as outlined above. I believe this will help achieve our shared goals of quickly stabilizing hadoop-2 and help ensure we can support it for forseeable future in a compatible manner for the benefit of our users and downstream projects.
>
> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>
> thanks,
> Arun
>
> PS: To keep this discussion grounded in technical details I've moved this to dev@ (bcc general@).
>

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Amir Sanjar
In reply to this post by Arun Murthy

good, glad we are back on track again.  
BTW, we have already started build (IBM and OpenJDK SDK), unit test, and limited integration testing  on x86 and POWER, results are promising.

Best Regards
Amir Sanjar

System Management Architect
PowerLinux Open Source Hadoop development lead
IBM Senior Software Engineer
Phone# 512-286-8393
Fax#      512-838-8858



Arun C Murthy ---05/15/2013 12:58:20 PM---Folks, A considerable number of people have expressed confusion regarding the recent vote on 2.0.5,

From: Arun C Murthy <[hidden email]>
To: [hidden email],
Date: 05/15/2013 12:58 PM
Subject: [VOTE] - Release 2.0.5-beta





Folks,

A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc.

IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as "seizing the moment". There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention.

To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration.

I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content:
# HDFS-347
# HDFS Snapshots
# Windows support
# Necessary & final API/protocol changes such as:
* Final YARN API changes: YARN-386
* MR Binary Compatibility: MAPREDUCE-5108
* Final RPC cleanup: HADOOP-8990

People working on the above features have all expressed considerable comfort with them and are ready to stand-by to help expedite any necessary bug-fixes etc. to get to stabilization quickly. I'm confident we can get this release out by end of May. This sets stage for a hadoop-2.x GA release right after with some more testing - this means I think I can quickly turn around and make bug-fix releases as necessary right after 2.0.5-beta.

I request that people consider helping out with this plan and sign up to help push hadoop-2.x to stability as outlined above. I believe this will help achieve our shared goals of quickly stabilizing hadoop-2 and help ensure we can support it for forseeable future in a compatible manner for the benefit of our users and downstream projects.

Please vote, the vote will run the normal 7 days. Obviously, I'm +1.

thanks,
Arun

PS: To keep this discussion grounded in technical details I've moved this to dev@ (bcc general@).


Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Karthik Kambatla-2
In reply to this post by Arun Murthy
Hi Arun,

Can we add HADOOP-9517 to the list - having compatibility guidelines should
help us support users and downstream projects better?

Thanks
Karthik


On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]> wrote:

> Folks,
>
> A considerable number of people have expressed confusion regarding the
> recent vote on 2.0.5, beta status etc. given lack of specifics, the voting
> itself (validity of the vote itself, whose votes are binding) etc.
>
> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability
> of 3 features under debate etc.) have been lost in the discussion in favor
> of non-technical (almost dramatic) nuances such as "seizing the moment".
> There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1)
> - this is a red flag for me; particularly when there are just 3 features
> being debated and active committers and contributors are confident of and
> ready to stand by their work. All patches, I believe, are ready to be
> merged in the the next few days per discussions on jira. This will,
> clearly, not delay the other API work which everyone agrees is crucial. As
> a result, I feel no recourse but to restart a new vote - all attempts at
> calm, reasoned, civil discussion based on technical arguments have come to
> naught - I apologize for the thrash caused to everyone's attention.
>
> To get past all of this confusion, I'd like to present an alternate,
> specific proposal for consideration.
>
> I propose we continue the original plan and make a 2.0.5-beta release by
> May end with the following content:
> # HDFS-347
> # HDFS Snapshots
> # Windows support
> # Necessary & final API/protocol changes such as:
>  * Final YARN API changes: YARN-386
>  * MR Binary Compatibility: MAPREDUCE-5108
>  * Final RPC cleanup: HADOOP-8990
>
> People working on the above features have all expressed considerable
> comfort with them and are ready to stand-by to help expedite any necessary
> bug-fixes etc. to get to stabilization quickly. I'm confident we can get
> this release out by end of May. This sets stage for a hadoop-2.x GA release
> right after with some more testing - this means I think I can quickly turn
> around and make bug-fix releases as necessary right after 2.0.5-beta.
>
> I request that people consider helping out with this plan and sign up to
> help push hadoop-2.x to stability as outlined above. I believe this will
> help achieve our shared goals of quickly stabilizing hadoop-2 and help
> ensure we can support it for forseeable future in a compatible manner for
> the benefit of our users and downstream projects.
>
> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>
> thanks,
> Arun
>
> PS: To keep this discussion grounded in technical details I've moved this
> to dev@ (bcc general@).
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Alejandro Abdelnur
Do we need to add YARN-397?

Thanks.


On Wed, May 15, 2013 at 11:23 AM, Karthik Kambatla <[hidden email]>wrote:

> Hi Arun,
>
> Can we add HADOOP-9517 to the list - having compatibility guidelines should
> help us support users and downstream projects better?
>
> Thanks
> Karthik
>
>
> On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]>
> wrote:
>
> > Folks,
> >
> > A considerable number of people have expressed confusion regarding the
> > recent vote on 2.0.5, beta status etc. given lack of specifics, the
> voting
> > itself (validity of the vote itself, whose votes are binding) etc.
> >
> > IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current
> stability
> > of 3 features under debate etc.) have been lost in the discussion in
> favor
> > of non-technical (almost dramatic) nuances such as "seizing the moment".
> > There is now dangerous talk of tolerating incompatibility b/w 2.0 and
> 2.1)
> > - this is a red flag for me; particularly when there are just 3 features
> > being debated and active committers and contributors are confident of and
> > ready to stand by their work. All patches, I believe, are ready to be
> > merged in the the next few days per discussions on jira. This will,
> > clearly, not delay the other API work which everyone agrees is crucial.
> As
> > a result, I feel no recourse but to restart a new vote - all attempts at
> > calm, reasoned, civil discussion based on technical arguments have come
> to
> > naught - I apologize for the thrash caused to everyone's attention.
> >
> > To get past all of this confusion, I'd like to present an alternate,
> > specific proposal for consideration.
> >
> > I propose we continue the original plan and make a 2.0.5-beta release by
> > May end with the following content:
> > # HDFS-347
> > # HDFS Snapshots
> > # Windows support
> > # Necessary & final API/protocol changes such as:
> >  * Final YARN API changes: YARN-386
> >  * MR Binary Compatibility: MAPREDUCE-5108
> >  * Final RPC cleanup: HADOOP-8990
> >
> > People working on the above features have all expressed considerable
> > comfort with them and are ready to stand-by to help expedite any
> necessary
> > bug-fixes etc. to get to stabilization quickly. I'm confident we can get
> > this release out by end of May. This sets stage for a hadoop-2.x GA
> release
> > right after with some more testing - this means I think I can quickly
> turn
> > around and make bug-fix releases as necessary right after 2.0.5-beta.
> >
> > I request that people consider helping out with this plan and sign up to
> > help push hadoop-2.x to stability as outlined above. I believe this will
> > help achieve our shared goals of quickly stabilizing hadoop-2 and help
> > ensure we can support it for forseeable future in a compatible manner for
> > the benefit of our users and downstream projects.
> >
> > Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
> >
> > thanks,
> > Arun
> >
> > PS: To keep this discussion grounded in technical details I've moved this
> > to dev@ (bcc general@).
> >
> >
>



--
Alejandro
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Vinod Vavilapalli
In reply to this post by Arun Murthy

Thanks for laying out a very specific release plan, easy to vote on.

I am watching most of YARN and MAPREDUCE changes, glad that those are called out specifically. Apart from that, we have

 - RM restart which is mostly already committed but needs a couple more in
 - a couple of scheduling related APIs which fall under the protocol changes you mentioned, that are close to commit
 - a couple of security issues which aren't exactly features.

Just calling them out specifically so that there is no ambiguity.

+1 (binding for this)

Thanks,
+Vinod Kumar Vavilapalli

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

> Folks,
>
> A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc.
>
> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as "seizing the moment". There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention.
>
> To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration.
>
> I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content:
> # HDFS-347
> # HDFS Snapshots
> # Windows support
> # Necessary & final API/protocol changes such as:
> * Final YARN API changes: YARN-386
> * MR Binary Compatibility: MAPREDUCE-5108
> * Final RPC cleanup: HADOOP-8990
>
> People working on the above features have all expressed considerable comfort with them and are ready to stand-by to help expedite any necessary bug-fixes etc. to get to stabilization quickly. I'm confident we can get this release out by end of May. This sets stage for a hadoop-2.x GA release right after with some more testing - this means I think I can quickly turn around and make bug-fix releases as necessary right after 2.0.5-beta.
>
> I request that people consider helping out with this plan and sign up to help push hadoop-2.x to stability as outlined above. I believe this will help achieve our shared goals of quickly stabilizing hadoop-2 and help ensure we can support it for forseeable future in a compatible manner for the benefit of our users and downstream projects.
>
> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>
> thanks,
> Arun
>
> PS: To keep this discussion grounded in technical details I've moved this to dev@ (bcc general@).
>

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Vinod Vavilapalli


>  - RM restart which is mostly already committed but needs a couple more in
>  - a couple of scheduling related APIs which fall under the protocol changes you mentioned, that are close to commit
>  - a couple of security issues which aren't exactly features.

I should have been clearer:
 - RM restart stuff is tracked at YARN-128
 - scheduling APIs tracked at YARN-397
 - security stuff tracked at YARN-47

Thanks,
+Vinod

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Arun Murthy
Yes to all. As long as we are making timely and compatible progress, we don't need to debate individual issues here. Let's continue discussion on relevant jiras.

thanks,
Arun

On May 15, 2013, at 12:11 PM, Vinod Kumar Vavilapalli wrote:

>
>
>> - RM restart which is mostly already committed but needs a couple more in
>> - a couple of scheduling related APIs which fall under the protocol changes you mentioned, that are close to commit
>> - a couple of security issues which aren't exactly features.
>
> I should have been clearer:
> - RM restart stuff is tracked at YARN-128
> - scheduling APIs tracked at YARN-397
> - security stuff tracked at YARN-47
>
> Thanks,
> +Vinod
>


Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Vinod Vavilapalli
In reply to this post by Alejandro Abdelnur

I also feel that some of YARN-397 should go in. If you also feel so, please put in a +1 to state your intention.

Thanks,
+Vinod

On May 15, 2013, at 11:32 AM, Alejandro Abdelnur wrote:

> Do we need to add YARN-397?
>
> Thanks.
>
>
> On Wed, May 15, 2013 at 11:23 AM, Karthik Kambatla <[hidden email]>wrote:
>
>> Hi Arun,
>>
>> Can we add HADOOP-9517 to the list - having compatibility guidelines should
>> help us support users and downstream projects better?
>>
>> Thanks
>> Karthik
>>
>>
>> On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]>
>> wrote:
>>
>>> Folks,
>>>
>>> A considerable number of people have expressed confusion regarding the
>>> recent vote on 2.0.5, beta status etc. given lack of specifics, the
>> voting
>>> itself (validity of the vote itself, whose votes are binding) etc.
>>>
>>> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current
>> stability
>>> of 3 features under debate etc.) have been lost in the discussion in
>> favor
>>> of non-technical (almost dramatic) nuances such as "seizing the moment".
>>> There is now dangerous talk of tolerating incompatibility b/w 2.0 and
>> 2.1)
>>> - this is a red flag for me; particularly when there are just 3 features
>>> being debated and active committers and contributors are confident of and
>>> ready to stand by their work. All patches, I believe, are ready to be
>>> merged in the the next few days per discussions on jira. This will,
>>> clearly, not delay the other API work which everyone agrees is crucial.
>> As
>>> a result, I feel no recourse but to restart a new vote - all attempts at
>>> calm, reasoned, civil discussion based on technical arguments have come
>> to
>>> naught - I apologize for the thrash caused to everyone's attention.
>>>
>>> To get past all of this confusion, I'd like to present an alternate,
>>> specific proposal for consideration.
>>>
>>> I propose we continue the original plan and make a 2.0.5-beta release by
>>> May end with the following content:
>>> # HDFS-347
>>> # HDFS Snapshots
>>> # Windows support
>>> # Necessary & final API/protocol changes such as:
>>> * Final YARN API changes: YARN-386
>>> * MR Binary Compatibility: MAPREDUCE-5108
>>> * Final RPC cleanup: HADOOP-8990
>>>
>>> People working on the above features have all expressed considerable
>>> comfort with them and are ready to stand-by to help expedite any
>> necessary
>>> bug-fixes etc. to get to stabilization quickly. I'm confident we can get
>>> this release out by end of May. This sets stage for a hadoop-2.x GA
>> release
>>> right after with some more testing - this means I think I can quickly
>> turn
>>> around and make bug-fix releases as necessary right after 2.0.5-beta.
>>>
>>> I request that people consider helping out with this plan and sign up to
>>> help push hadoop-2.x to stability as outlined above. I believe this will
>>> help achieve our shared goals of quickly stabilizing hadoop-2 and help
>>> ensure we can support it for forseeable future in a compatible manner for
>>> the benefit of our users and downstream projects.
>>>
>>> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>>>
>>> thanks,
>>> Arun
>>>
>>> PS: To keep this discussion grounded in technical details I've moved this
>>> to dev@ (bcc general@).
>>>
>>>
>>
>
>
>
> --
> Alejandro

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Arpit Gupta
In reply to this post by Arun Murthy
+1

--
Arpit Gupta
Hortonworks Inc.
http://hortonworks.com/

On May 15, 2013, at 10:57 AM, Arun C Murthy <[hidden email]> wrote:

> Folks,
>
> A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc.
>
> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as "seizing the moment". There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention.
>
> To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration.
>
> I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content:
> # HDFS-347
> # HDFS Snapshots
> # Windows support
> # Necessary & final API/protocol changes such as:
> * Final YARN API changes: YARN-386
> * MR Binary Compatibility: MAPREDUCE-5108
> * Final RPC cleanup: HADOOP-8990
>
> People working on the above features have all expressed considerable comfort with them and are ready to stand-by to help expedite any necessary bug-fixes etc. to get to stabilization quickly. I'm confident we can get this release out by end of May. This sets stage for a hadoop-2.x GA release right after with some more testing - this means I think I can quickly turn around and make bug-fix releases as necessary right after 2.0.5-beta.
>
> I request that people consider helping out with this plan and sign up to help push hadoop-2.x to stability as outlined above. I believe this will help achieve our shared goals of quickly stabilizing hadoop-2 and help ensure we can support it for forseeable future in a compatible manner for the benefit of our users and downstream projects.
>
> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>
> thanks,
> Arun
>
> PS: To keep this discussion grounded in technical details I've moved this to dev@ (bcc general@).
>

Reply | Threaded
Open this post in threaded view
|

RE: [VOTE] - Release 2.0.5-beta

Bikas Saha
In reply to this post by Vinod Vavilapalli
I am +1 to the proposal because it maintains the original cadence a bunch
of us committers/contributors have been working with.

Windows related changes have been made in a conservative manner so as not
to destabilize the code base. The changes are being extensively tested and
validated by community members, especially those from Microsoft.

YARN-397 jiras are mainly enhancements that can be added in a backwards
compatible manner. Would be great if some of them make it but I would not
hold the release for them.

Let us all make the effort to get the release out with all the long
awaited and useful features as planned.
Bikas

-----Original Message-----
From: Vinod Kumar Vavilapalli [mailto:[hidden email]]
Sent: Wednesday, May 15, 2013 12:20 PM
To: [hidden email]
Subject: Re: [VOTE] - Release 2.0.5-beta


I also feel that some of YARN-397 should go in. If you also feel so,
please put in a +1 to state your intention.

Thanks,
+Vinod

On May 15, 2013, at 11:32 AM, Alejandro Abdelnur wrote:

> Do we need to add YARN-397?
>
> Thanks.
>
>
> On Wed, May 15, 2013 at 11:23 AM, Karthik Kambatla
<[hidden email]>wrote:

>
>> Hi Arun,
>>
>> Can we add HADOOP-9517 to the list - having compatibility guidelines
>> should help us support users and downstream projects better?
>>
>> Thanks
>> Karthik
>>
>>
>> On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]>
>> wrote:
>>
>>> Folks,
>>>
>>> A considerable number of people have expressed confusion regarding
>>> the recent vote on 2.0.5, beta status etc. given lack of specifics,
>>> the
>> voting
>>> itself (validity of the vote itself, whose votes are binding) etc.
>>>
>>> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current
>> stability
>>> of 3 features under debate etc.) have been lost in the discussion in
>> favor
>>> of non-technical (almost dramatic) nuances such as "seizing the
moment".
>>> There is now dangerous talk of tolerating incompatibility b/w 2.0
>>> and
>> 2.1)
>>> - this is a red flag for me; particularly when there are just 3
>>> features being debated and active committers and contributors are
>>> confident of and ready to stand by their work. All patches, I
>>> believe, are ready to be merged in the the next few days per
>>> discussions on jira. This will, clearly, not delay the other API work
which everyone agrees is crucial.

>> As
>>> a result, I feel no recourse but to restart a new vote - all
>>> attempts at calm, reasoned, civil discussion based on technical
>>> arguments have come
>> to
>>> naught - I apologize for the thrash caused to everyone's attention.
>>>
>>> To get past all of this confusion, I'd like to present an alternate,
>>> specific proposal for consideration.
>>>
>>> I propose we continue the original plan and make a 2.0.5-beta
>>> release by May end with the following content:
>>> # HDFS-347
>>> # HDFS Snapshots
>>> # Windows support
>>> # Necessary & final API/protocol changes such as:
>>> * Final YARN API changes: YARN-386
>>> * MR Binary Compatibility: MAPREDUCE-5108
>>> * Final RPC cleanup: HADOOP-8990
>>>
>>> People working on the above features have all expressed considerable
>>> comfort with them and are ready to stand-by to help expedite any
>> necessary
>>> bug-fixes etc. to get to stabilization quickly. I'm confident we can
>>> get this release out by end of May. This sets stage for a hadoop-2.x
>>> GA
>> release
>>> right after with some more testing - this means I think I can
>>> quickly
>> turn
>>> around and make bug-fix releases as necessary right after 2.0.5-beta.
>>>
>>> I request that people consider helping out with this plan and sign
>>> up to help push hadoop-2.x to stability as outlined above. I believe
>>> this will help achieve our shared goals of quickly stabilizing
>>> hadoop-2 and help ensure we can support it for forseeable future in
>>> a compatible manner for the benefit of our users and downstream
projects.

>>>
>>> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>>>
>>> thanks,
>>> Arun
>>>
>>> PS: To keep this discussion grounded in technical details I've moved
>>> this to dev@ (bcc general@).
>>>
>>>
>>
>
>
>
> --
> Alejandro
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Eric Baldeschwieler-2
In reply to this post by Arun Murthy
+1

On May 15, 2013, at 10:57 AM, Arun C Murthy <[hidden email]> wrote:

> Folks,
>
> A considerable number of people have expressed confusion regarding the recent vote on 2.0.5, beta status etc. given lack of specifics, the voting itself (validity of the vote itself, whose votes are binding) etc.
>
> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability of 3 features under debate etc.) have been lost in the discussion in favor of non-technical (almost dramatic) nuances such as "seizing the moment". There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1) - this is a red flag for me; particularly when there are just 3 features being debated and active committers and contributors are confident of and ready to stand by their work. All patches, I believe, are ready to be merged in the the next few days per discussions on jira. This will, clearly, not delay the other API work which everyone agrees is crucial. As a result, I feel no recourse but to restart a new vote - all attempts at calm, reasoned, civil discussion based on technical arguments have come to naught - I apologize for the thrash caused to everyone's attention.
>
> To get past all of this confusion, I'd like to present an alternate, specific proposal for consideration.
>
> I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content:
> # HDFS-347
> # HDFS Snapshots
> # Windows support
> # Necessary & final API/protocol changes such as:
> * Final YARN API changes: YARN-386
> * MR Binary Compatibility: MAPREDUCE-5108
> * Final RPC cleanup: HADOOP-8990
>
> People working on the above features have all expressed considerable comfort with them and are ready to stand-by to help expedite any necessary bug-fixes etc. to get to stabilization quickly. I'm confident we can get this release out by end of May. This sets stage for a hadoop-2.x GA release right after with some more testing - this means I think I can quickly turn around and make bug-fix releases as necessary right after 2.0.5-beta.
>
> I request that people consider helping out with this plan and sign up to help push hadoop-2.x to stability as outlined above. I believe this will help achieve our shared goals of quickly stabilizing hadoop-2 and help ensure we can support it for forseeable future in a compatible manner for the benefit of our users and downstream projects.
>
> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>
> thanks,
> Arun
>
> PS: To keep this discussion grounded in technical details I've moved this to dev@ (bcc general@).
>

Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Matt Foley-2
In reply to this post by Bikas Saha
+1 (binding).  I think it's important to maintain the release continuity,
otherwise we could end up with the 0.20.2 / 0.20.200 problem all over again
(parallel "stable" dev tracks without a parent-child relationship to each
other, ie with disjoint subsets of functionality).  I consider achieving a
stable basis for API backward compat very important.  And Arun is
committing to hit beta in the very near future.

--Matt


On Wed, May 15, 2013 at 1:16 PM, Bikas Saha <[hidden email]> wrote:

> I am +1 to the proposal because it maintains the original cadence a bunch
> of us committers/contributors have been working with.
>
> Windows related changes have been made in a conservative manner so as not
> to destabilize the code base. The changes are being extensively tested and
> validated by community members, especially those from Microsoft.
>
> YARN-397 jiras are mainly enhancements that can be added in a backwards
> compatible manner. Would be great if some of them make it but I would not
> hold the release for them.
>
> Let us all make the effort to get the release out with all the long
> awaited and useful features as planned.
> Bikas
>
> -----Original Message-----
> From: Vinod Kumar Vavilapalli [mailto:[hidden email]]
> Sent: Wednesday, May 15, 2013 12:20 PM
> To: [hidden email]
> Subject: Re: [VOTE] - Release 2.0.5-beta
>
>
> I also feel that some of YARN-397 should go in. If you also feel so,
> please put in a +1 to state your intention.
>
> Thanks,
> +Vinod
>
> On May 15, 2013, at 11:32 AM, Alejandro Abdelnur wrote:
>
> > Do we need to add YARN-397?
> >
> > Thanks.
> >
> >
> > On Wed, May 15, 2013 at 11:23 AM, Karthik Kambatla
> <[hidden email]>wrote:
> >
> >> Hi Arun,
> >>
> >> Can we add HADOOP-9517 to the list - having compatibility guidelines
> >> should help us support users and downstream projects better?
> >>
> >> Thanks
> >> Karthik
> >>
> >>
> >> On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]>
> >> wrote:
> >>
> >>> Folks,
> >>>
> >>> A considerable number of people have expressed confusion regarding
> >>> the recent vote on 2.0.5, beta status etc. given lack of specifics,
> >>> the
> >> voting
> >>> itself (validity of the vote itself, whose votes are binding) etc.
> >>>
> >>> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current
> >> stability
> >>> of 3 features under debate etc.) have been lost in the discussion in
> >> favor
> >>> of non-technical (almost dramatic) nuances such as "seizing the
> moment".
> >>> There is now dangerous talk of tolerating incompatibility b/w 2.0
> >>> and
> >> 2.1)
> >>> - this is a red flag for me; particularly when there are just 3
> >>> features being debated and active committers and contributors are
> >>> confident of and ready to stand by their work. All patches, I
> >>> believe, are ready to be merged in the the next few days per
> >>> discussions on jira. This will, clearly, not delay the other API work
> which everyone agrees is crucial.
> >> As
> >>> a result, I feel no recourse but to restart a new vote - all
> >>> attempts at calm, reasoned, civil discussion based on technical
> >>> arguments have come
> >> to
> >>> naught - I apologize for the thrash caused to everyone's attention.
> >>>
> >>> To get past all of this confusion, I'd like to present an alternate,
> >>> specific proposal for consideration.
> >>>
> >>> I propose we continue the original plan and make a 2.0.5-beta
> >>> release by May end with the following content:
> >>> # HDFS-347
> >>> # HDFS Snapshots
> >>> # Windows support
> >>> # Necessary & final API/protocol changes such as:
> >>> * Final YARN API changes: YARN-386
> >>> * MR Binary Compatibility: MAPREDUCE-5108
> >>> * Final RPC cleanup: HADOOP-8990
> >>>
> >>> People working on the above features have all expressed considerable
> >>> comfort with them and are ready to stand-by to help expedite any
> >> necessary
> >>> bug-fixes etc. to get to stabilization quickly. I'm confident we can
> >>> get this release out by end of May. This sets stage for a hadoop-2.x
> >>> GA
> >> release
> >>> right after with some more testing - this means I think I can
> >>> quickly
> >> turn
> >>> around and make bug-fix releases as necessary right after 2.0.5-beta.
> >>>
> >>> I request that people consider helping out with this plan and sign
> >>> up to help push hadoop-2.x to stability as outlined above. I believe
> >>> this will help achieve our shared goals of quickly stabilizing
> >>> hadoop-2 and help ensure we can support it for forseeable future in
> >>> a compatible manner for the benefit of our users and downstream
> projects.
> >>>
> >>> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
> >>>
> >>> thanks,
> >>> Arun
> >>>
> >>> PS: To keep this discussion grounded in technical details I've moved
> >>> this to dev@ (bcc general@).
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Alejandro
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Sandy Ryza
In reply to this post by Eric Baldeschwieler-2
+1 (non-binding)

Agreed with Bikas that we should get the scheduler API enhancements
(YARN-397) in we are able, but they don't need to be blockers because they
will be backwards compatible.

Arun, not sure whether your "Yes to all" already covered this, but I'd like
to throw in support for the compatibility guidelines being a blocker.


On Wed, May 15, 2013 at 1:20 PM, eric baldeschwieler <[hidden email]
> wrote:

> +1
>
> On May 15, 2013, at 10:57 AM, Arun C Murthy <[hidden email]> wrote:
>
> > Folks,
> >
> > A considerable number of people have expressed confusion regarding the
> recent vote on 2.0.5, beta status etc. given lack of specifics, the voting
> itself (validity of the vote itself, whose votes are binding) etc.
> >
> > IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current
> stability of 3 features under debate etc.) have been lost in the discussion
> in favor of non-technical (almost dramatic) nuances such as "seizing the
> moment". There is now dangerous talk of tolerating incompatibility b/w 2.0
> and 2.1) - this is a red flag for me; particularly when there are just 3
> features being debated and active committers and contributors are confident
> of and ready to stand by their work. All patches, I believe, are ready to
> be merged in the the next few days per discussions on jira. This will,
> clearly, not delay the other API work which everyone agrees is crucial. As
> a result, I feel no recourse but to restart a new vote - all attempts at
> calm, reasoned, civil discussion based on technical arguments have come to
> naught - I apologize for the thrash caused to everyone's attention.
> >
> > To get past all of this confusion, I'd like to present an alternate,
> specific proposal for consideration.
> >
> > I propose we continue the original plan and make a 2.0.5-beta release by
> May end with the following content:
> > # HDFS-347
> > # HDFS Snapshots
> > # Windows support
> > # Necessary & final API/protocol changes such as:
> > * Final YARN API changes: YARN-386
> > * MR Binary Compatibility: MAPREDUCE-5108
> > * Final RPC cleanup: HADOOP-8990
> >
> > People working on the above features have all expressed considerable
> comfort with them and are ready to stand-by to help expedite any necessary
> bug-fixes etc. to get to stabilization quickly. I'm confident we can get
> this release out by end of May. This sets stage for a hadoop-2.x GA release
> right after with some more testing - this means I think I can quickly turn
> around and make bug-fix releases as necessary right after 2.0.5-beta.
> >
> > I request that people consider helping out with this plan and sign up to
> help push hadoop-2.x to stability as outlined above. I believe this will
> help achieve our shared goals of quickly stabilizing hadoop-2 and help
> ensure we can support it for forseeable future in a compatible manner for
> the benefit of our users and downstream projects.
> >
> > Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
> >
> > thanks,
> > Arun
> >
> > PS: To keep this discussion grounded in technical details I've moved
> this to dev@ (bcc general@).
> >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Matt Foley
>> Arun, not sure whether your "Yes to all" already covered this, but I'd
like
>> to throw in support for the compatibility guidelines being a blocker.

+1 to that.  Definitely an overriding concern for me.


On Wed, May 15, 2013 at 1:25 PM, Sandy Ryza <[hidden email]> wrote:

> +1 (non-binding)
>
> Agreed with Bikas that we should get the scheduler API enhancements
> (YARN-397) in we are able, but they don't need to be blockers because they
> will be backwards compatible.
>
> Arun, not sure whether your "Yes to all" already covered this, but I'd like
> to throw in support for the compatibility guidelines being a blocker.
>
>
> On Wed, May 15, 2013 at 1:20 PM, eric baldeschwieler <
> [hidden email]
> > wrote:
>
> > +1
> >
> > On May 15, 2013, at 10:57 AM, Arun C Murthy <[hidden email]> wrote:
> >
> > > Folks,
> > >
> > > A considerable number of people have expressed confusion regarding the
> > recent vote on 2.0.5, beta status etc. given lack of specifics, the
> voting
> > itself (validity of the vote itself, whose votes are binding) etc.
> > >
> > > IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current
> > stability of 3 features under debate etc.) have been lost in the
> discussion
> > in favor of non-technical (almost dramatic) nuances such as "seizing the
> > moment". There is now dangerous talk of tolerating incompatibility b/w
> 2.0
> > and 2.1) - this is a red flag for me; particularly when there are just 3
> > features being debated and active committers and contributors are
> confident
> > of and ready to stand by their work. All patches, I believe, are ready to
> > be merged in the the next few days per discussions on jira. This will,
> > clearly, not delay the other API work which everyone agrees is crucial.
> As
> > a result, I feel no recourse but to restart a new vote - all attempts at
> > calm, reasoned, civil discussion based on technical arguments have come
> to
> > naught - I apologize for the thrash caused to everyone's attention.
> > >
> > > To get past all of this confusion, I'd like to present an alternate,
> > specific proposal for consideration.
> > >
> > > I propose we continue the original plan and make a 2.0.5-beta release
> by
> > May end with the following content:
> > > # HDFS-347
> > > # HDFS Snapshots
> > > # Windows support
> > > # Necessary & final API/protocol changes such as:
> > > * Final YARN API changes: YARN-386
> > > * MR Binary Compatibility: MAPREDUCE-5108
> > > * Final RPC cleanup: HADOOP-8990
> > >
> > > People working on the above features have all expressed considerable
> > comfort with them and are ready to stand-by to help expedite any
> necessary
> > bug-fixes etc. to get to stabilization quickly. I'm confident we can get
> > this release out by end of May. This sets stage for a hadoop-2.x GA
> release
> > right after with some more testing - this means I think I can quickly
> turn
> > around and make bug-fix releases as necessary right after 2.0.5-beta.
> > >
> > > I request that people consider helping out with this plan and sign up
> to
> > help push hadoop-2.x to stability as outlined above. I believe this will
> > help achieve our shared goals of quickly stabilizing hadoop-2 and help
> > ensure we can support it for forseeable future in a compatible manner for
> > the benefit of our users and downstream projects.
> > >
> > > Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
> > >
> > > thanks,
> > > Arun
> > >
> > > PS: To keep this discussion grounded in technical details I've moved
> > this to dev@ (bcc general@).
> > >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Roman Shaposhnik-2
In reply to this post by Arun Murthy
On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]> wrote:
> I propose we continue the original plan and make a 2.0.5-beta release by May end with the following content:

I have a very basic question: what are the steps that we, as a community,
are willing to undertake to ensure that our aggressive release schedule
(end of May is exactly two weeks away) and our intent of actually
calling this a beta release would be realistic?

Please tell me if my expectations are incorrect, but to me the -beta would
signify it being a 'safe' target for the downstream components. We're still
finding *very* basic and *very* disruptive issues (MAPREDUCE-5240 is
a good example) that essentially mean DOA for downstream that depends
on this functionality.

Are we comfortable with delivering 2.0.5-beta and later on starting
to discover things like MAPREDUCE-5240 more or less accidentally?

As I mentioned in a different thread -- there are a few things that
Apache Bigtop can help with in that regard -- but they can only
happen if we as a community agree that they need to happen
before we can call Hadoop 2.x a beta release.

If this sounds useful to the Hadoop community at large -- lets fork
this thread into the appropriate ML and discuss the practical, achievable
steps that can be included into the release criteria of Hadoop 2.0.5-beta
as it is being discussed here.

Thanks,
Roman.
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Matt Foley
>> lets fork this thread into the appropriate ML and discuss the practical,
achievable
>> steps that can be included into the release criteria of Hadoop 2.0.5-beta

Seems to me common-dev is the appropriate ML, and Arun has invited Jiras to
include.
Open a Jira with your suggested list, and we carry on the discussion from
there.  Does that work?


On Wed, May 15, 2013 at 1:29 PM, Roman Shaposhnik <[hidden email]> wrote:

> On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]>
> wrote:
> > I propose we continue the original plan and make a 2.0.5-beta release by
> May end with the following content:
>
> I have a very basic question: what are the steps that we, as a community,
> are willing to undertake to ensure that our aggressive release schedule
> (end of May is exactly two weeks away) and our intent of actually
> calling this a beta release would be realistic?
>
> Please tell me if my expectations are incorrect, but to me the -beta would
> signify it being a 'safe' target for the downstream components. We're still
> finding *very* basic and *very* disruptive issues (MAPREDUCE-5240 is
> a good example) that essentially mean DOA for downstream that depends
> on this functionality.
>
> Are we comfortable with delivering 2.0.5-beta and later on starting
> to discover things like MAPREDUCE-5240 more or less accidentally?
>
> As I mentioned in a different thread -- there are a few things that
> Apache Bigtop can help with in that regard -- but they can only
> happen if we as a community agree that they need to happen
> before we can call Hadoop 2.x a beta release.
>
> If this sounds useful to the Hadoop community at large -- lets fork
> this thread into the appropriate ML and discuss the practical, achievable
> steps that can be included into the release criteria of Hadoop 2.0.5-beta
> as it is being discussed here.
>
> Thanks,
> Roman.
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Devaraj Das-2
In reply to this post by Arun Murthy
+1 (binding) on the proposal. 2-3 weeks doesn't sound too long a time, and
we have many committers willing to be on-call to fix issues when they are
discovered.


On Wed, May 15, 2013 at 10:57 AM, Arun C Murthy <[hidden email]> wrote:

> Folks,
>
> A considerable number of people have expressed confusion regarding the
> recent vote on 2.0.5, beta status etc. given lack of specifics, the voting
> itself (validity of the vote itself, whose votes are binding) etc.
>
> IMHO technical arguments (incompatibility b/w 2.0 & 2.1, current stability
> of 3 features under debate etc.) have been lost in the discussion in favor
> of non-technical (almost dramatic) nuances such as "seizing the moment".
> There is now dangerous talk of tolerating incompatibility b/w 2.0 and 2.1)
> - this is a red flag for me; particularly when there are just 3 features
> being debated and active committers and contributors are confident of and
> ready to stand by their work. All patches, I believe, are ready to be
> merged in the the next few days per discussions on jira. This will,
> clearly, not delay the other API work which everyone agrees is crucial. As
> a result, I feel no recourse but to restart a new vote - all attempts at
> calm, reasoned, civil discussion based on technical arguments have come to
> naught - I apologize for the thrash caused to everyone's attention.
>
> To get past all of this confusion, I'd like to present an alternate,
> specific proposal for consideration.
>
> I propose we continue the original plan and make a 2.0.5-beta release by
> May end with the following content:
> # HDFS-347
> # HDFS Snapshots
> # Windows support
> # Necessary & final API/protocol changes such as:
>  * Final YARN API changes: YARN-386
>  * MR Binary Compatibility: MAPREDUCE-5108
>  * Final RPC cleanup: HADOOP-8990
>
> People working on the above features have all expressed considerable
> comfort with them and are ready to stand-by to help expedite any necessary
> bug-fixes etc. to get to stabilization quickly. I'm confident we can get
> this release out by end of May. This sets stage for a hadoop-2.x GA release
> right after with some more testing - this means I think I can quickly turn
> around and make bug-fix releases as necessary right after 2.0.5-beta.
>
> I request that people consider helping out with this plan and sign up to
> help push hadoop-2.x to stability as outlined above. I believe this will
> help achieve our shared goals of quickly stabilizing hadoop-2 and help
> ensure we can support it for forseeable future in a compatible manner for
> the benefit of our users and downstream projects.
>
> Please vote, the vote will run the normal 7 days. Obviously, I'm +1.
>
> thanks,
> Arun
>
> PS: To keep this discussion grounded in technical details I've moved this
> to dev@ (bcc general@).
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [VOTE] - Release 2.0.5-beta

Eli Collins
In reply to this post by Matt Foley
On Wed, May 15, 2013 at 1:29 PM, Matt Foley <[hidden email]> wrote:

> >> Arun, not sure whether your "Yes to all" already covered this, but I'd
> like
> >> to throw in support for the compatibility guidelines being a blocker.
>
> +1 to that.  Definitely an overriding concern for me.
>
>
+1  Likewise.   Would be great to get more eyeballs on Karthik's patch
on HADOOP-9517 if people haven't review it already.
1234