Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi,


The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.


Regards,

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Re: Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi,


I got the Jenkins builds for 0.23-PB.  They were cloned from 0.23.  Everything looks fine.  Please see the details at the end.

https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-Common-0.23-PB-Build/
https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-Hdfs-0.23-PB-Build/
https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-Mapreduce-0.23-PB-Build/

Regards,


Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/
---------------------------
Here is more details.  In Common, TestViewFsTrash occasionally fails and it also fails on trunk.  Filed HADOOP-8110.  I don't see any failure in HDFS.

For Mapreduce, there were two unit tests, TestNMAuditLogger and TestAuditLogger, failed.  TestNMAuditLogger was already fixed in trunk and then I merged MAPREDUCE-2942.  TestAuditLogger casued some compilation errors earlier in 0.23 since 0.23 did not have PB.  MAPREDUCE-3368 removed the PB related code from the TestAuditLogger.  I reverted the changes in 0.23-PB and then the test passed.  After fixed the two unit tests, a Jenkins build still failed although the maven build inside was success (see below).  I suspect the Jenkins configuration has some bugs.  Note that the Jenkins builds for 0.23 also fail quite frequently.  So the problem is not specific to 0.23-PB.

Below is copied from build #2 of 0.23-PB.
https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-Mapreduce-0.23-PB-Build/2/console
Note that build #204 of 0.23 has the same failure.
https://builds.apache.org/view/G-L/view/Hadoop/job/Hadoop-Mapreduce-0.23-Build/204/console

[INFO] hadoop-mapreduce .................................. SUCCESS [0.077s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 40:46.501s
[INFO] Finished at: Fri Feb 24 13:56:06 UTC 2012
[INFO] Final Memory: 78M/370M
[INFO] ------------------------------------------------------------------------
+ [[ 0 -ne 0 ]]
Build step 'Execute shell' marked build as failure



----- Original Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: "general@hadoop.apache.org" <ge...@hadoop.apache.org>
Cc: 
Sent: Thursday, February 23, 2012 1:00 PM
Subject: Re: Merging 0.23-PB to 0.23

I ran unit tests when I did the merges.  I will see if I could get a Jenkins build on 0.23-PB.


Nicholas



----- Original Message -----
From: Eli Collins <el...@cloudera.com>
To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
Cc: 
Sent: Thursday, February 23, 2012 12:41 PM
Subject: Re: Merging 0.23-PB to 0.23

Thanks Nicholas.

For sanity, Jenkins is clean on this branch? I didn't see a job on
builds.apache.org so assuming you've run it locally.

On Thu, Feb 23, 2012 at 12:31 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi Eli,
>
> You indeed did the checking very carefully.  The reason of HDFS-395 is that (1) as you mentioned, it is a significant improvement, and (2) it changes the protocols.  If it is not included, then there will be a lot of code rewrite in 0.23-PB.
>
> Sure, will update the fix version on JIRA.
>
> Thanks.
>
> Nicholas
>
>
> ________________________________
> From: Eli Collins <el...@cloudera.com>
> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
> Sent: Wednesday, February 22, 2012 7:41 PM
> Subject: Re: Merging 0.23-PB to 0.23
>
> Hey Nicholas,
>
> Thank you for doing this!   +1 for the merge.
>
> I went through the delta between 0.23-PB and branch-23, and they look
> good.  I noticed some other changes from trunk not-PB related (eg
> HDFS-395) were pulled in, and they were all stuff that were in my
> list:
> http://search-hadoop.com/m/pn6ea1EgPTc1&subj=Re+Merging+some+trunk+changes+to+23
> I'll merge the remainder to branch-23 (primarily the BR scalability
> changes) after you've merged this.
>
> Mind updating jira for the relevant changes to have a 0.23.2 fixVersion?
>
> Thanks,
> Eli
>
> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
> <s2...@yahoo.com> wrote:
>> Hi,
>>
>>
>> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of
> 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>>
>>
>> Regards,
>>
>> Tsz-Wo Nicholas Sze
>> Hortonworks Inc.
>> http://hortonworks.com/

Re: Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

I ran unit tests when I did the merges.  I will see if I could get a Jenkins build on 0.23-PB.


Nicholas



----- Original Message -----
From: Eli Collins <el...@cloudera.com>
To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
Cc: 
Sent: Thursday, February 23, 2012 12:41 PM
Subject: Re: Merging 0.23-PB to 0.23

Thanks Nicholas.

For sanity, Jenkins is clean on this branch? I didn't see a job on
builds.apache.org so assuming you've run it locally.

On Thu, Feb 23, 2012 at 12:31 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi Eli,
>
> You indeed did the checking very carefully.  The reason of HDFS-395 is that (1) as you mentioned, it is a significant improvement, and (2) it changes the protocols.  If it is not included, then there will be a lot of code rewrite in 0.23-PB.
>
> Sure, will update the fix version on JIRA.
>
> Thanks.
>
> Nicholas
>
>
> ________________________________
> From: Eli Collins <el...@cloudera.com>
> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
> Sent: Wednesday, February 22, 2012 7:41 PM
> Subject: Re: Merging 0.23-PB to 0.23
>
> Hey Nicholas,
>
> Thank you for doing this!   +1 for the merge.
>
> I went through the delta between 0.23-PB and branch-23, and they look
> good.  I noticed some other changes from trunk not-PB related (eg
> HDFS-395) were pulled in, and they were all stuff that were in my
> list:
> http://search-hadoop.com/m/pn6ea1EgPTc1&subj=Re+Merging+some+trunk+changes+to+23
> I'll merge the remainder to branch-23 (primarily the BR scalability
> changes) after you've merged this.
>
> Mind updating jira for the relevant changes to have a 0.23.2 fixVersion?
>
> Thanks,
> Eli
>
> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
> <s2...@yahoo.com> wrote:
>> Hi,
>>
>>
>> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of
> 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>>
>>
>> Regards,
>>
>> Tsz-Wo Nicholas Sze
>> Hortonworks Inc.
>> http://hortonworks.com/

Re: Merging 0.23-PB to 0.23

[Eli Collins <el...@cloudera.com>]

Thanks Nicholas.

For sanity, Jenkins is clean on this branch? I didn't see a job on
builds.apache.org so assuming you've run it locally.

On Thu, Feb 23, 2012 at 12:31 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi Eli,
>
> You indeed did the checking very carefully.  The reason of HDFS-395 is that (1) as you mentioned, it is a significant improvement, and (2) it changes the protocols.  If it is not included, then there will be a lot of code rewrite in 0.23-PB.
>
> Sure, will update the fix version on JIRA.
>
> Thanks.
>
> Nicholas
>
>
> ________________________________
> From: Eli Collins <el...@cloudera.com>
> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
> Sent: Wednesday, February 22, 2012 7:41 PM
> Subject: Re: Merging 0.23-PB to 0.23
>
> Hey Nicholas,
>
> Thank you for doing this!   +1 for the merge.
>
> I went through the delta between 0.23-PB and branch-23, and they look
> good.  I noticed some other changes from trunk not-PB related (eg
> HDFS-395) were pulled in, and they were all stuff that were in my
> list:
> http://search-hadoop.com/m/pn6ea1EgPTc1&subj=Re+Merging+some+trunk+changes+to+23
> I'll merge the remainder to branch-23 (primarily the BR scalability
> changes) after you've merged this.
>
> Mind updating jira for the relevant changes to have a 0.23.2 fixVersion?
>
> Thanks,
> Eli
>
> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
> <s2...@yahoo.com> wrote:
>> Hi,
>>
>>
>> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of
> 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>>
>>
>> Regards,
>>
>> Tsz-Wo Nicholas Sze
>> Hortonworks Inc.
>> http://hortonworks.com/

Re: Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi Eli,

You indeed did the checking very carefully.  The reason of HDFS-395 is that (1) as you mentioned, it is a significant improvement, and (2) it changes the protocols.  If it is not included, then there will be a lot of code rewrite in 0.23-PB.

Sure, will update the fix version on JIRA.

Thanks.

Nicholas


________________________________
From: Eli Collins <el...@cloudera.com>
To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com> 
Sent: Wednesday, February 22, 2012 7:41 PM
Subject: Re: Merging 0.23-PB to 0.23

Hey Nicholas,

Thank you for doing this!   +1 for the merge.

I went through the delta between 0.23-PB and branch-23, and they look
good.  I noticed some other changes from trunk not-PB related (eg
HDFS-395) were pulled in, and they were all stuff that were in my
list:
http://search-hadoop.com/m/pn6ea1EgPTc1&subj=Re+Merging+some+trunk+changes+to+23
I'll merge the remainder to branch-23 (primarily the BR scalability
changes) after you've merged this.

Mind updating jira for the relevant changes to have a 0.23.2 fixVersion?

Thanks,
Eli

On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi,
>
>
> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of
0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>
>
> Regards,
>
> Tsz-Wo Nicholas Sze
> Hortonworks Inc.
> http://hortonworks.com/

Re: Merging 0.23-PB to 0.23

[Eli Collins <el...@cloudera.com>]

Hey Nicholas,

Thank you for doing this!   +1 for the merge.

I went through the delta between 0.23-PB and branch-23, and they look
good.  I noticed some other changes from trunk not-PB related (eg
HDFS-395) were pulled in, and they were all stuff that were in my
list:
http://search-hadoop.com/m/pn6ea1EgPTc1&subj=Re+Merging+some+trunk+changes+to+23
I'll merge the remainder to branch-23 (primarily the BR scalability
changes) after you've merged this.

Mind updating jira for the relevant changes to have a 0.23.2 fixVersion?

Thanks,
Eli

On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi,
>
>
> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>
>
> Regards,
>
> Tsz-Wo Nicholas Sze
> Hortonworks Inc.
> http://hortonworks.com/

Re: [VOTE] Merging 0.23-PB to 0.23

[Tsz Wo Sze <sz...@yahoo.com>]

Hi Arun,

Sure, I will set the fix version to be 0.23.3.

Nicholas



----- Original Message -----
From: Arun C Murthy <ac...@hortonworks.com>
To: general@hadoop.apache.org
Cc: 
Sent: Wednesday, February 22, 2012 9:36 PM
Subject: Re: [VOTE] Merging 0.23-PB to 0.23

+1, nice to see this go in to branch-0.23.

Given the discussion on the hadoop-0.23.1 voting thread, can I request the fix-version for this to be 23.3? As I've mentioned there I'm thinking a 23.2 as a small bug-fix release in a week or so with some critical fixes/enhancements - this won't affect the PB merge at all.

Makes sense?

thanks,
Arun

On Feb 23, 2012, at 10:33 AM, Suresh Srinivas wrote:

> +1.
> 
> On Wed, Feb 22, 2012 at 4:02 PM, Tsz Wo (Nicholas), Sze <
> s29752-hadoopgeneral@yahoo.com> wrote:
> 
>> We actually require to have a vote according to the bylaws (Thanks Aaron
>> Myers for the kindly note.)  Please check the branch and vote.
>> 
>> Tsz-Wo Nicholas Sze
>> 
>> Hortonworks Inc.
>> http://hortonworks.com/
>> 
>> 
>> ________________________________
>> From: Mahadev Konar <ma...@hortonworks.com>
>> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <
>> s29752-hadoopgeneral@yahoo.com>
>> Sent: Wednesday, February 22, 2012 3:30 PM
>> Subject: Re: Merging 0.23-PB to 0.23
>> 
>> Sounds great! +1 for merging. Would be good to get this into 0.23
>> branch as soon as possible.
>> 
>> Mahadev Konar
>> Hortonworks Inc.
>> http://hortonworks.com/
>> 
>> 
>> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
>> <s2...@yahoo.com> wrote:
>>> Hi,
>>> 
>>> The IPC protocol buffer feature in trunk is complete.  It is time to
>> merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23
>> can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge
>> it tomorrow.  Please let me know if you have any concern.
>>> 
>>> Regards,
>>> 
>>> Tsz-Wo Nicholas Sze
>>> Hortonworks Inc.
>>> http://hortonworks.com/
>> 

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

Re: [VOTE] Merging 0.23-PB to 0.23

[Todd Papaioannou <dr...@gmail.com>]

Will do.

Thanks,

Todd

On Mar 17, 2012, at 8:19 PM, "Aaron T. Myers" <at...@cloudera.com> wrote:

> Hi ToddP,
> 
> Would you mind starting a new thread on general@ to discuss release
> renumbering? It seems to me that that issue is orthogonal to what's being
> discussed in this thread.
> 
> Thanks a lot,
> Aaron
> 
> --
> Aaron T. Myers
> Software Engineer, Cloudera
> 
> 
> 
> On Sat, Mar 17, 2012 at 8:10 PM, Todd Papaioannou <dr...@gmail.com>wrote:
> 
>> Isn't it about time that we started calling 0.23 "Hadoop 2.0" instead?
>> While the numbering system may make sense to everyone here, to the rest of
>> the world it's going to be hella confusing for 0.23 to come out after
>> Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would
>> make sense to call it 2.0. Also, I think would really help with the brand
>> awareness/perception of the project in the wider customer audience.
>> 
>> I know there are some other potential releases out there too, so my
>> overall suggestion would be:
>> 
>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
>> Current 0.23 -> Gets renamed to 2.0
>> 
>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to
>> make project progress more understandable to the rest of the world. We
>> should ensure we don't regress with the next major release.
>> 
>> Thoughts?
>> 
>> ToddP
>> 
>> 
>> On Mar 17, 2012, at 2:51 PM, Eli Collins wrote:
>> 
>>> On Wed, Feb 22, 2012 at 9:36 PM, Arun C Murthy <ac...@hortonworks.com>
>> wrote:
>>>> +1, nice to see this go in to branch-0.23.
>>>> 
>>>> Given the discussion on the hadoop-0.23.1 voting thread, can I request
>> the fix-version for this to be 23.3? As I've mentioned there I'm thinking a
>> 23.2 as a small bug-fix release in a week or so with some critical
>> fixes/enhancements - this won't affect the PB merge at all.
>>>> 
>>> 
>>> Arun,  are you still planning to do a quick 23.2 release? Given that
>>> it's been a month and PB and HA are in checked in we should cut a new
>>> 23.2 branch?
>>> 
>>> Thanks,
>>> Eli
>> 
>> 

Re: Naming of Hadoop releases

[Konstantin Boudnik <co...@apache.org>]

On Mon, Mar 19, 2012 at 12:04PM, Konstantin Shvachko wrote:
> Hadoop naming is definitely confusing. And having Hadoop-1 did not
> make it less confusing for users.
> 
> > Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
> 
> It was released on November 29, 2011.
> eBay is actively using it as of today.
> 
> If the goal of renaming branches is to make things less confusing
> about Hadoop, then I agree with people saying we should do a
> simultaneous rename of the branches. That is
> Current 0.22 -> 2
> Current 0.23 -> 3
> 
> It almost sounds like release .22 does not deserve a whole number,
> only a fraction. But having .22 renamed to 1.5 creates a confusion
> that it belongs to Hadoop-1 line, which is not exactly the message we
> want to send out.
> Also I don't know what the number of commits reflects, and whether it
> is good or not to have many for a particular release.
> 
> If the community decides to rename .22 to 2 I will be glad to work on it.

Count me in

Cos

> Thanks,
> --Konstantin
> 
> On Sun, Mar 18, 2012 at 11:04 AM, Todd Papaioannou
> <dr...@gmail.com> wrote:
> > On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:
> >
> >> 9.22 can't be considered as 1.5 because it is the major release from 1.0 (old
> >> 0.20.x). Besides, by declaring it as 1.5 we'll be planting future confusion of
> >> the same sort that happened around 0.20* line.
> >>
> >> And last but not least, the same ═discussion has happened in the past around
> >> 1.0 release time like http://is.gd/x1fVqu
> >
> > Yes I remember it well, but AFAIC there was no clear decision on 0.22 or 0.23. There were competing proposals and opinions and basically what happened was that we punted the decision on anything other than 0.20->1.0 until a later date. But, that later date is now approaching and we continue to call the current release in question 0.23. Hence my original email.
> >
> > Personally, I do not believe 0.22 is sufficiently major to call it 2.0 and push 0.23 to 3.0. But that's just my $0.02. I don't feel strongly enough to worry about what the outcome is.
> >
> > What I _do_ care strongly about is that we get some resolution and stop using 0.23 as a release name. It's confusing to the market and the customer base, and while we have made great progress in simplifying things with the 1.0 release moniker, we need to continue to make progress.
> >
> > ToddP
> >
> >
> >
> >>
> >> Cos
> >>
> >>
> >> On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
> >>> All,
> >>>
> >>> With the upcoming release of 0.23, isn't it about time that we started calling 0.23 "Hadoop 2.0" instead?
> >>>
> >>> While the numbering system may make sense to everyone here, to the rest of the world it's going to be hella confusing for 0.23 to come out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would make sense to call it 2.0. Also, I think would really help with the brand awareness/perception of the project in the wider customer audience.
> >>>
> >>> I know there are some other potential releases out there too, so my overall suggestion would be:
> >>>
> >>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
> >>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
> >>> Current 0.23 -> Gets renamed to 2.0
> >>>
> >>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to make project progress more understandable to the rest of the world. We should ensure we don't regress with the next major release.
> >>>
> >>> Thoughts?
> >>>
> >>> ToddP
> >>>
> >

Re: Naming of Hadoop releases

[Dhruba Borthakur <dh...@gmail.com>]

We vote would be to leave 0.22 as it is, and rename 0.23 as Hadoop 2.0.

-dhruba

On Sun, Mar 18, 2012 at 5:07 PM, Owen O'Malley <om...@apache.org> wrote:

> Without working security, I don't think 0.22 should be moved out of the
> 0.22.x release numbering. I see that branch-0.22 has 12 fixes since 0.22.0,
> which was 3 months ago. My read on those numbers is that there is some
> adoption and therefore bug fixes, but no one is making major changes in the
> branch.
>
> In the same period of time, branch-0.23 has had 3447 commits and has built
> up a community that is quickly pushing it forward. I'd support renaming the
> future 0.23 releases as 2.x.y.
>
> -- Owen
>



-- 
Subscribe to my posts at http://www.facebook.com/dhruba

Re: Naming of Hadoop releases

[Owen O'Malley <om...@apache.org>]

Without working security, I don't think 0.22 should be moved out of the
0.22.x release numbering. I see that branch-0.22 has 12 fixes since 0.22.0,
which was 3 months ago. My read on those numbers is that there is some
adoption and therefore bug fixes, but no one is making major changes in the
branch.

In the same period of time, branch-0.23 has had 3447 commits and has built
up a community that is quickly pushing it forward. I'd support renaming the
future 0.23 releases as 2.x.y.

-- Owen

Re: Naming of Hadoop releases

[Konstantin Shvachko <sh...@gmail.com>]

Hi everybody,

I think it is important that people vote on the Arun's proposal.
- Whether it is binding or not.
- Whether you think your vote does not effect the results.
- We have a huge user base,and should be hearing from you.
- It would be very useful to understand your opinions or confusions
about renaming of the branches, indicated by voting.
- I am particularly interested in the value of the 0.22 branch for the
user community.
I believe there is life on the outskirts of the Universe with the
restaurant at the End of it. It is good to now the actual scale.

Thanks,
--Konstantin

Re: Naming of Hadoop releases

[Konstantin Shvachko <sh...@gmail.com>]

Sanjay,

Yes I plan to continue fixing bugs as long as I use the branch, and
release it if the need arise. I hope there won't be many required with
0.23 progressing as planned.

Thanks,
--Konstantin

On Mon, Mar 19, 2012 at 4:24 PM, sanjay Radia <sa...@hortonworks.com> wrote:
>
> On Mar 19, 2012, at 12:04 PM, Konstantin Shvachko wrote:
>
> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
>
>
> It was released on November 29, 2011.
> eBay is actively using it as of today.
>
>
> Konstantine,
>
> For a release to be truly viable, it has to be deployed in production and
> followed on with
> bug fixes over time. Otherwise  the release may not stabilize and it becomes
> confusing for users.
>
> Is EBay already using it in *production* (you had used the words "actively"
> and perhaps you meant
> "production") and are you  planning to do bug fixes and periodic releases?
> On the other hand,  is EBay planning to instead fork 0.22 and maintain an
> internal release for custom improvements?
>
>
> sanjay
>

Re: Naming of Hadoop releases

[sanjay Radia <sa...@hortonworks.com>]

On Mar 19, 2012, at 12:04 PM, Konstantin Shvachko wrote:
> 
> 
>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
> 
> It was released on November 29, 2011.
> eBay is actively using it as of today.
> 

Konstantine,

For a release to be truly viable, it has to be deployed in production and followed on with
bug fixes over time. Otherwise  the release may not stabilize and it becomes confusing for users.

Is EBay already using it in *production* (you had used the words "actively" and perhaps you meant
"production") and are you  planning to do bug fixes and periodic releases? On the other hand,  is EBay planning to instead fork 0.22 and maintain an internal release for custom improvements?


sanjay

Re: Naming of Hadoop releases

[Konstantin Shvachko <sh...@gmail.com>]

> This is a long standing issue with branch-0.22 - are either of you planning on fixing this?

I personally do not have plans to fix security in .22. I don't think
we should target it. I hope 0.23 will be a replacement for it by
summer. Is it still in your roadmap, Arun?
I also don't think that this should be a requirement for renaming the
release, at least I haven't seen anything about it in the Apache
Hadoop policies.

> could you please share some roadmap/timelines?

I did discuss my roadmap with my managers. Sorry don't have anything to share.

Thanks,
--Konstantin

On Mon, Mar 19, 2012 at 2:47 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
> Konstantin and Milind,
>
>  As I've noted on the other thread (my bad):
>
>> However, the problem is that hadoop-0.22 has removed public and non-deprecated apis/features (i.e. security) which are present in branch-1 (previously branch-0.20.2xx).
>>
>> This is against the Apache Hadoop release policy on major releases i.e. only features deprecated for at least one release can be removed.
>
> This is a long standing issue with branch-0.22 - are either of you planning on fixing this? If so, could you please share some roadmap/timelines?
>
> thanks,
> Arun
>
> On Mar 19, 2012, at 12:34 PM, <Mi...@emc.com> <Mi...@emc.com> wrote:
>
>> I agree with Konstantin. In previous discussion, I had suggested
>> simultaneous renumbering, but for some reason it was not considered.
>>
>> (For history buffs: I upgraded from Windows 1.0 to Windows 3.1 straight.
>> Windows 2.0 did not have many features that made it compelling to upgrade.
>> It did not seem odd to skip a number then, and I don't see why it would
>> now. I also skipped Windows Vista and upgraded from XP to Windows 7, even
>> if Vista was touted as a major release.)
>>
>> - Milind
>>
>> ---
>> Milind Bhandarkar
>> Chief Architect, Greenplum Labs, Data Computing Division, EMC
>> +1-650-523-3858 (W)
>> +1-408-666-8483 (M)
>>
>>
>>
>> On 3/19/12 12:04 PM, "Konstantin Shvachko" <sh...@gmail.com> wrote:
>>
>>> Hadoop naming is definitely confusing. And having Hadoop-1 did not
>>> make it less confusing for users.
>>>
>>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>>> released)
>>>
>>> It was released on November 29, 2011.
>>> eBay is actively using it as of today.
>>>
>>> If the goal of renaming branches is to make things less confusing
>>> about Hadoop, then I agree with people saying we should do a
>>> simultaneous rename of the branches. That is
>>> Current 0.22 -> 2
>>> Current 0.23 -> 3
>>>
>>> It almost sounds like release .22 does not deserve a whole number,
>>> only a fraction. But having .22 renamed to 1.5 creates a confusion
>>> that it belongs to Hadoop-1 line, which is not exactly the message we
>>> want to send out.
>>> Also I don't know what the number of commits reflects, and whether it
>>> is good or not to have many for a particular release.
>>>
>>> If the community decides to rename .22 to 2 I will be glad to work on it.
>>>
>>> Thanks,
>>> --Konstantin
>>>
>>> On Sun, Mar 18, 2012 at 11:04 AM, Todd Papaioannou
>>> <dr...@gmail.com> wrote:
>>>> On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:
>>>>
>>>>> 9.22 can't be considered as 1.5 because it is the major release from
>>>>> 1.0 (old
>>>>> 0.20.x). Besides, by declaring it as 1.5 we'll be planting future
>>>>> confusion of
>>>>> the same sort that happened around 0.20* line.
>>>>>
>>>>> And last but not least, the same  discussion has happened in the past
>>>>> around
>>>>> 1.0 release time like http://is.gd/x1fVqu
>>>>
>>>> Yes I remember it well, but AFAIC there was no clear decision on 0.22
>>>> or 0.23. There were competing proposals and opinions and basically what
>>>> happened was that we punted the decision on anything other than
>>>> 0.20->1.0 until a later date. But, that later date is now approaching
>>>> and we continue to call the current release in question 0.23. Hence my
>>>> original email.
>>>>
>>>> Personally, I do not believe 0.22 is sufficiently major to call it 2.0
>>>> and push 0.23 to 3.0. But that's just my $0.02. I don't feel strongly
>>>> enough to worry about what the outcome is.
>>>>
>>>> What I _do_ care strongly about is that we get some resolution and stop
>>>> using 0.23 as a release name. It's confusing to the market and the
>>>> customer base, and while we have made great progress in simplifying
>>>> things with the 1.0 release moniker, we need to continue to make
>>>> progress.
>>>>
>>>> ToddP
>>>>
>>>>
>>>>
>>>>>
>>>>> Cos
>>>>>
>>>>>
>>>>> On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
>>>>>> All,
>>>>>>
>>>>>> With the upcoming release of 0.23, isn't it about time that we
>>>>>> started calling 0.23 "Hadoop 2.0" instead?
>>>>>>
>>>>>> While the numbering system may make sense to everyone here, to the
>>>>>> rest of the world it's going to be hella confusing for 0.23 to come
>>>>>> out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think
>>>>>> that it would make sense to call it 2.0. Also, I think would really
>>>>>> help with the brand awareness/perception of the project in the wider
>>>>>> customer audience.
>>>>>>
>>>>>> I know there are some other potential releases out there too, so my
>>>>>> overall suggestion would be:
>>>>>>
>>>>>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
>>>>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>>>>> released)
>>>>>> Current 0.23 -> Gets renamed to 2.0
>>>>>>
>>>>>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was
>>>>>> to make project progress more understandable to the rest of the world.
>>>>>> We should ensure we don't regress with the next major release.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> ToddP
>>>>>>
>>>>
>>>
>>
>
> --
> Arun C. Murthy
> Hortonworks Inc.
> http://hortonworks.com/
>
>

Re: Naming of Hadoop releases

[Todd Lipcon <to...@cloudera.com>]

On Mon, Mar 19, 2012 at 11:02 PM, Konstantin Shvachko
<sh...@gmail.com> wrote:
> Feature freeze has been broken so many times for the .20 branch, so
> that it became a norm for the entire project rather than an exception,
> which we had in the past.

I agree we should be stricter about what feature backports we allow
into "stable" branches. Security and hflush were both necessary evils
- I'm glad now that we have them, but we should try to stay out of
these types of situations in the future where we feel compelled to
backport (or re-do in the case of hflush/sync) such large items.

>
> I don't understand this constant segregation against Hadoop .22. It is
> a perfectly usable version of Hadoop. It would be waste not to have it
> released. Very glad that universities adopted it. If somebody needs
> security there is a number of choices, Hadoop-1 being the first. But
> if you cannot afford stand-alone HBase clusters or need to combine
> general Hadoop and HBase loads there is nothing else but Hadoop 0.22
> at this point.

I don't see what HBase has to do with it. In fact HBase runs way
better on 1.x compared to 0.22. The tests don't even pass on 0.22 due
to differences in the append semantics in 0.21+ compared to 0.20.
Every production HBase deploy I know about runs on an 1.x based
distribution. You could argue this is selection bias by nature of my
employer, but the same is true based on emails to the hbase-user
lists, etc. This is orthogonal to the discussion at hand, I just
wanted to correct this lest any users get the wrong perception and
migrate their HBase clusters to a version which is rarely used and
strictly inferior for this use case.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Naming of Hadoop releases

[Scott Carey <sc...@richrelevance.com>]

On 3/19/12 11:02 PM, "Konstantin Shvachko" <sh...@gmail.com> wrote:

><Doug>
>> to prevent such situations in the future might be that if you backport
>> something from branch n to n-2 then you ought to also be required to
>> backport it to branch n-1 and in general to all intervening branches.
>
>This is imo the most important topic in the discussion.
>I support Doug's proposal, because it provides forward-moving
>evolution of the project,
>with releases being driven by the necessity to introduce new features,
>so that we could avoid back- and forward-porting overhead, which
>exhausts the community resources.

I believe this is untenable.  You cannot guarantee that Hadoop 11.x will
have all the features as Hadoop 3.x.  As such, a backport from 11.x to 2.x
for some reason should not imply porting all the way down the chain.  One
cannot foresee which of those intermediate versions are still active or
live in advance.
When a major version number changes, all bets are off.  The release may
completely overhaul an API, or it may not.  Assumptions of linear progress
break down.

Perhaps such a rule for branches within a major release line make sense
where one can reasonably expect to be able to maintain some expectation of
linear progress.  However not all major versions will have such an
assumption, and the same issues will apply.

The more difficult you make it for an organization to share its work with
the community (i.e. create a branch) the more likely they will work on it
on the side and not in the community.


>
><Arun>
>> This is against the Apache Hadoop release policy on major releases i.e.
>> only features deprecated for at least one release can be removed.
>
>Not sure if this is the Apache Hadoop release policy, but
>we as PMC were inconsistent in allowing decisions to implement new
>features in old releases, namely the 0.20 series, instead of creating
>new releases with those new features. This is the reason why security
>and other good features are not in 0.22.
>Feature freeze has been broken so many times for the .20 branch, so
>that it became a norm for the entire project rather than an exception,
>which we had in the past.
>
>I don't understand this constant segregation against Hadoop .22. It is
>a perfectly usable version of Hadoop. It would be waste not to have it
>released. Very glad that universities adopted it. If somebody needs
>security there is a number of choices, Hadoop-1 being the first. But
>if you cannot afford stand-alone HBase clusters or need to combine
>general Hadoop and HBase loads there is nothing else but Hadoop 0.22
>at this point.
>
>When .23 is stable I will be glad to use it. But the steady stream of
>feature ports makes it hard to decide how stable it is and to predict
>when it is ready.
>I am advocating to stop porting features and start releasing them.
>If .23 is Federation + Yarn, then 0.23 + HA is 0.24; plus PB - going
>to 0.25, etc.
>
>Thought I should clarify what I mean by forward-going progress.
>Hope it makes sense.
>
>Thanks,
>--Konstantin
>
>
>On Mon, Mar 19, 2012 at 2:56 PM, Doug Cutting <cu...@apache.org> wrote:
>> On 03/19/2012 02:47 PM, Arun C Murthy wrote:
>>> This is against the Apache Hadoop release policy on major releases
>>>i.e. only features deprecated for at least one release can be removed.
>>
>> In many case the reason this happened was that features were backported
>> from trunk to 0.20 but not to 0.22.  In other words, its no fault of the
>> folks who were working on branch 0.22.  So a related policy we might add
>> to prevent such situations in the future might be that if you backport
>> something from branch n to n-2 then you ought to also be required to
>> backport it to branch n-1 and in general to all intervening branches.
>> Does that seem sensible?
>>
>> Doug

Re: Naming of Hadoop releases

[Konstantin Shvachko <sh...@gmail.com>]

<Doug>
> to prevent such situations in the future might be that if you backport
> something from branch n to n-2 then you ought to also be required to
> backport it to branch n-1 and in general to all intervening branches.

This is imo the most important topic in the discussion.
I support Doug's proposal, because it provides forward-moving
evolution of the project,
with releases being driven by the necessity to introduce new features,
so that we could avoid back- and forward-porting overhead, which
exhausts the community resources.

<Arun>
> This is against the Apache Hadoop release policy on major releases i.e.
> only features deprecated for at least one release can be removed.

Not sure if this is the Apache Hadoop release policy, but
we as PMC were inconsistent in allowing decisions to implement new
features in old releases, namely the 0.20 series, instead of creating
new releases with those new features. This is the reason why security
and other good features are not in 0.22.
Feature freeze has been broken so many times for the .20 branch, so
that it became a norm for the entire project rather than an exception,
which we had in the past.

I don't understand this constant segregation against Hadoop .22. It is
a perfectly usable version of Hadoop. It would be waste not to have it
released. Very glad that universities adopted it. If somebody needs
security there is a number of choices, Hadoop-1 being the first. But
if you cannot afford stand-alone HBase clusters or need to combine
general Hadoop and HBase loads there is nothing else but Hadoop 0.22
at this point.

When .23 is stable I will be glad to use it. But the steady stream of
feature ports makes it hard to decide how stable it is and to predict
when it is ready.
I am advocating to stop porting features and start releasing them.
If .23 is Federation + Yarn, then 0.23 + HA is 0.24; plus PB - going
to 0.25, etc.

Thought I should clarify what I mean by forward-going progress.
Hope it makes sense.

Thanks,
--Konstantin


On Mon, Mar 19, 2012 at 2:56 PM, Doug Cutting <cu...@apache.org> wrote:
> On 03/19/2012 02:47 PM, Arun C Murthy wrote:
>> This is against the Apache Hadoop release policy on major releases i.e. only features deprecated for at least one release can be removed.
>
> In many case the reason this happened was that features were backported
> from trunk to 0.20 but not to 0.22.  In other words, its no fault of the
> folks who were working on branch 0.22.  So a related policy we might add
> to prevent such situations in the future might be that if you backport
> something from branch n to n-2 then you ought to also be required to
> backport it to branch n-1 and in general to all intervening branches.
> Does that seem sensible?
>
> Doug

Re: Naming of Hadoop releases

[Eric Baldeschwieler <er...@hortonworks.com>]

Lots of good stuff on this thread.   Todd, Chris and Todd have made great points.  (+1)

Doug, I think you have misdiagnosed the problem (in your comment below).  IMO the problem at the time of the creation of the 0.20.2xx was that the Hadoop community had not produced a stable release for years and none of 0.21, 0.22 or 0.23 were converging quickly to a stable release.  At the time, we had a lot of debate and concluded that 0.20.2xx was very much in the spirit of Apache.  We concluded that any committer is free to create any branch and can call a vote to release it if they choose.

Looking back, this open process has allowed us to make a lot of progress!  We've created a bit of naming messiness for sure, but let's look at the gains. The 0.20.2xx release is good enough that the PMC chose to promote it to Hadoop 1.0.  Further the 0.22 line is now good enough that ebay runs it in production and 0.23 continues to make great forward progress.  By allowing different contributors to pursue different agendas within the community, we have successfully produced stable releases and collected a lot of work within Apache Hadoop that was previously forced to live in private patch sets and branches.  We now may (or may not) agree on new naming for the other releases.  In the end, the community is better off with more choices and more progress.  This seems like a perfect blend of meritocracy and democracy. 

Let's not discourage back porting and other contributions.  We have release masters, patch reviews and feedback to stop bad ideas and votes to choose between competing visions of what comes next.  Let's have fewer bylaws and allow messiness when needed.

E14


On Mar 19, 2012, at 4:18 PM, Doug Cutting wrote:

> On 03/19/2012 03:38 PM, Todd Lipcon wrote:
>> Unfortunately, I don't have a better solution in mind that resolves
>> the above problems - I just don't think it's tenable to combine a
>> policy like "anyone may make a release branch off trunk and claim a
>> major version number" with another policy like "you have to port a fix
>> to all intermediate versions in order to port a fix to any of them".
>> If a group of committers wants to make a release branch, then the
>> maintenance of that branch should be up to them.
> 
> I don't think it's the case that anyone can create a new major version
> number.  Creation of new release branches should be an activity of the
> PMC, not individuals.  As such, the majority of the PMC implicitly or
> explicitly approves such branches and the PMC must responsibly deal with
> the ensuing results.  We should not operate as a fragmented community
> creating a fragmented, overlapping set of products.
> 
> As I recall, when the 0.22 release branch was created it was intended by
> the PMC to be a release branch that followed 0.20 and preceded 0.23.
> Since then we as a PMC have acted inconsistently and now must deal with
> the consequences.
> 
> We've already made an exception to our policies in releasing 0.20.20x
> and 0.22 that regresses from it in some areas.  We now need to decide
> whether we want to continue that exception by renaming 0.22 to 2.0 or
> not.  It does not look like we'll reach consensus on this.  That's
> unfortunate, but we still need to answer it.
> 
> We also should decide whether we want to permit ourselves to get in this
> pinch again.  I think it's avoidable if in the future we only make
> releases that are consistent with our other policies.  Backports should
> be easier for intervening releases.  We might reasonably grandfather
> 0.22 as skippable for backports as it's too late to fix that now.
> 
> Doug

Re: Naming of Hadoop releases

[Roman Shaposhnik <rv...@apache.org>]

Arun, let me answer both of your questions in the same reply:

On Mon, Mar 19, 2012 at 4:38 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
> So, let me ask again - is there anyone willing to step up and fix security in branch-0.22?
>
> If not, and I haven't seen evidence to the contrary for a very long time now, IMHO this discussion is moot.

Which discussion? The one that I'm interested in is a very simple
issue -- should
we reserve the version slot 2.X.Y or not. That has very little to do
with the current
state of security.

> Roman & Milind: asking again - would you guys be willing to step up and fix 0.22 to be more
> reasonable as a hadoop-2 candidate i.e. fix/validate security?

Sure. I might end up doing some work on within the Bigtop framework.
That said, I can't
really give you the deadline as of now. Hence my desire to separate
these 2 discussions.

Thanks,
Roman.

Re: Naming of Hadoop releases

[Arun C Murthy <ac...@hortonworks.com>]

On Mar 19, 2012, at 4:18 PM, Doug Cutting wrote:
> 
> We also should decide whether we want to permit ourselves to get in this
> pinch again.  I think it's avoidable if in the future we only make
> releases that are consistent with our other policies.  Backports should
> be easier for intervening releases.  We might reasonably grandfather
> 0.22 as skippable for backports as it's too late to fix that now.

Agree. 

0.22 & security is somewhat of a special case:
# hadoop-0.20.203 (with security) was released in May 2011.
# Folks working on branch-0.22 abandoned security much later in-spite of advise against. Thus, there has been sufficient opportunity to fix security in branch-0.22 since it's been repeatedly pointed out. 

Again, as I mentioned previously, please note that none of this is meant to discourage folks on 0.22 or further releases off the branch. It's just hard to call it hadoop-2 given it's current state or known roadmap. 

So, let me ask again - is there anyone willing to step up and fix security in branch-0.22? 

If not, and I haven't seen evidence to the contrary for a very long time now, IMHO this discussion is moot.

IAC, at this point everyone is sufficiently entrenched and I don't expect that anyone will be swayed anymore, so we could just call a vote with the options discussed and decide.

thanks,
Arun

Re: Naming of Hadoop releases

[Doug Cutting <cu...@apache.org>]

On 03/19/2012 03:38 PM, Todd Lipcon wrote:
> Unfortunately, I don't have a better solution in mind that resolves
> the above problems - I just don't think it's tenable to combine a
> policy like "anyone may make a release branch off trunk and claim a
> major version number" with another policy like "you have to port a fix
> to all intermediate versions in order to port a fix to any of them".
> If a group of committers wants to make a release branch, then the
> maintenance of that branch should be up to them.

I don't think it's the case that anyone can create a new major version
number.  Creation of new release branches should be an activity of the
PMC, not individuals.  As such, the majority of the PMC implicitly or
explicitly approves such branches and the PMC must responsibly deal with
the ensuing results.  We should not operate as a fragmented community
creating a fragmented, overlapping set of products.

As I recall, when the 0.22 release branch was created it was intended by
the PMC to be a release branch that followed 0.20 and preceded 0.23.
Since then we as a PMC have acted inconsistently and now must deal with
the consequences.

We've already made an exception to our policies in releasing 0.20.20x
and 0.22 that regresses from it in some areas.  We now need to decide
whether we want to continue that exception by renaming 0.22 to 2.0 or
not.  It does not look like we'll reach consensus on this.  That's
unfortunate, but we still need to answer it.

We also should decide whether we want to permit ourselves to get in this
pinch again.  I think it's avoidable if in the future we only make
releases that are consistent with our other policies.  Backports should
be easier for intervening releases.  We might reasonably grandfather
0.22 as skippable for backports as it's too late to fix that now.

Doug

Re: Naming of Hadoop releases

[Arun C Murthy <ac...@hortonworks.com>]

Roman & Milind: asking again - would you guys be willing to step up and fix 0.22 to be more reasonable as a hadoop-2 candidate i.e. fix/validate security?


On Mar 19, 2012, at 4:29 PM, Roman Shaposhnik wrote:

> On Mon, Mar 19, 2012 at 3:38 PM, Todd Lipcon <to...@cloudera.com> wrote:
>> On the other hand, it does suck for users if they update from "1.x" to
>> "2.x" and they end up losing some bug fixes or features they
>> previously were running.
> 
> Keep in mind that nobody's proposing to rename .22 branch into 2 right
> away. This will be addressed at a later point during one of the (hopefully)
> regular releases off of that branch.
> 
> Reserving branch-2 version slot is cheap and IMHO doesn't complicate
> anything. It does, however, give .22 branch a right to mature.
> 
> Thanks,
> Roman.

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

Re: Naming of Hadoop releases

[Roman Shaposhnik <rv...@apache.org>]

On Mon, Mar 19, 2012 at 3:38 PM, Todd Lipcon <to...@cloudera.com> wrote:
> On the other hand, it does suck for users if they update from "1.x" to
> "2.x" and they end up losing some bug fixes or features they
> previously were running.

Keep in mind that nobody's proposing to rename .22 branch into 2 right
away. This will be addressed at a later point during one of the (hopefully)
regular releases off of that branch.

Reserving branch-2 version slot is cheap and IMHO doesn't complicate
anything. It does, however, give .22 branch a right to mature.

Thanks,
Roman.

Re: Naming of Hadoop releases

[Scott Carey <sc...@richrelevance.com>]

On 3/19/12 3:38 PM, "Todd Lipcon" <to...@cloudera.com> wrote:
>
>>  So a related policy we might add
>> to prevent such situations in the future might be that if you backport
>> something from branch n to n-2 then you ought to also be required to
>> backport it to branch n-1 and in general to all intervening branches.
>> Does that seem sensible?
>
>-1 on this requirement. Otherwise the cost of backporting something to
>the stable line becomes really high, and we'll end up with
>distributors just maintaining their own branches outside of Apache
>(the state we were in with 0.20.x).
>
>On the other hand, it does suck for users if they update from "1.x" to
>"2.x" and they end up losing some bug fixes or features they
>previously were running.

Users should not expect upgrades from one major version to another to be
trivial.  Documentation on feature differences and upgrade paths are
expected for major changes.
It would be really bad if you went from 1.0.1 to 1.0.2 and lost security.
Upgrading from 1.x to 2.x and gaining/losing features is a non-issue IMO.

A major version bump indicates major differences.  These will necessarily
mean dropping of old features over time.  Rules on major versions about
feature supersets or deprecate-first requirements end up being meaningless
over time (the former is not tenable, the latter easy to circumvent with a
short lived release).

It is saner to define what a major/minor/patch version meanings are for
releases by default and then for each specific release note if that
differs from the norm.

I propse:
* Major version increment:  significant API or backwards compatibility
affecting changes may be present.  See documentation for details.
* Minor version increment:  API changes likely.  New features typically
added.  Removed features documented.  Expectation of backwards
compatibility unless otherwise noted in the release.
* Patch version increment:  fully backwards compatible in API and
Operation.  Bug fixes and minor features that


I don't see any logic at all as to why 0.22 can't be 2.0 -- a major
version number change indicates major differences.  If one of those
differences is that security is not present, so what?  There cannot be any
restriction on what can change across major number bumps.  _Any
conceivable restriction_ to what can change in a major release is flawed.
At some point, that feature or API may need to expire.

Re: Naming of Hadoop releases

[Todd Lipcon <to...@cloudera.com>]

On Mon, Mar 19, 2012 at 2:56 PM, Doug Cutting <cu...@apache.org> wrote:
> On 03/19/2012 02:47 PM, Arun C Murthy wrote:
>> This is against the Apache Hadoop release policy on major releases i.e. only features deprecated for at least one release can be removed.
>
> In many case the reason this happened was that features were backported
> from trunk to 0.20 but not to 0.22.  In other words, its no fault of the
> folks who were working on branch 0.22.

I agree that it's no fault of the folks on 0.22.

>  So a related policy we might add
> to prevent such situations in the future might be that if you backport
> something from branch n to n-2 then you ought to also be required to
> backport it to branch n-1 and in general to all intervening branches.
> Does that seem sensible?

-1 on this requirement. Otherwise the cost of backporting something to
the stable line becomes really high, and we'll end up with
distributors just maintaining their own branches outside of Apache
(the state we were in with 0.20.x).

On the other hand, it does suck for users if they update from "1.x" to
"2.x" and they end up losing some bug fixes or features they
previously were running.

Unfortunately, I don't have a better solution in mind that resolves
the above problems - I just don't think it's tenable to combine a
policy like "anyone may make a release branch off trunk and claim a
major version number" with another policy like "you have to port a fix
to all intermediate versions in order to port a fix to any of them".
If a group of committers wants to make a release branch, then the
maintenance of that branch should be up to them.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: Naming of Hadoop releases

[Chris A Mattmann <ch...@gmail.com>]

On Mar 20, 2012, at 12:28 AM, Chris Douglas wrote:

> -1. I agree with Todd; we tried this policy before and the project
> didn't produce a usable release for two years. Its benefits are
> fiction and its harm is documented.
> 
> However 0.22 is (or isn't) released, no general policy is required and
> nobody should waste their time trying to define one. Releases-
> including versions- are by majority vote. Either the developers of the
> 0.22 series convince most of the PMC that the release series warrants
> a major version, they elect to continue development on the 0.22
> series, or they fork the code and create a new project. Those are
> always the only outcomes and the reasoning will be ad hoc by
> definition.
> 
> My opinion: version numbers are cheap. As long as 0.22 has
> contributors interested in pursuing that line of development,
> reserving a series for that work to be released is not unreasonable.
> Confining it to 0.22.xxx presumes it will fail, while a major version
> should give its maintainers sufficient flexibility to define
> compatibility, etc. -C

Well stated, Chris, +1 (non-binding) from me.

Cheers,
Chris

++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Re: Naming of Hadoop releases

[sanjay Radia <sa...@hortonworks.com>]

On Mar 19, 2012, at 4:28 PM, Chris Douglas wrote:

> However 0.22 is (or isn't) released, no general policy is required and
> nobody should waste their time trying to define one. Releases-
> including versions- are by majority vote. Either the developers of the
> 0.22 series convince most of the PMC that the release series warrants
> a major version, they elect to continue development on the 0.22
> series, or they fork the code and create a new project. Those are
> always the only outcomes and the reasoning will be ad hoc by
> definition.
> 
> My opinion: version numbers are cheap. As long as 0.22 has
> contributors interested in pursuing that line of development,
> reserving a series for that work to be released is not unreasonable.
> Confining it to 0.22.xxx presumes it will fail, while a major version
> should give its maintainers sufficient flexibility to define
> compatibility, etc. -C

Well put chris.

Re: Naming of Hadoop releases

[Chris Douglas <cd...@apache.org>]

-1. I agree with Todd; we tried this policy before and the project
didn't produce a usable release for two years. Its benefits are
fiction and its harm is documented.

However 0.22 is (or isn't) released, no general policy is required and
nobody should waste their time trying to define one. Releases-
including versions- are by majority vote. Either the developers of the
0.22 series convince most of the PMC that the release series warrants
a major version, they elect to continue development on the 0.22
series, or they fork the code and create a new project. Those are
always the only outcomes and the reasoning will be ad hoc by
definition.

My opinion: version numbers are cheap. As long as 0.22 has
contributors interested in pursuing that line of development,
reserving a series for that work to be released is not unreasonable.
Confining it to 0.22.xxx presumes it will fail, while a major version
should give its maintainers sufficient flexibility to define
compatibility, etc. -C

On Mon, Mar 19, 2012 at 2:56 PM, Doug Cutting <cu...@apache.org> wrote:
> On 03/19/2012 02:47 PM, Arun C Murthy wrote:
>> This is against the Apache Hadoop release policy on major releases i.e. only features deprecated for at least one release can be removed.
>
> In many case the reason this happened was that features were backported
> from trunk to 0.20 but not to 0.22.  In other words, its no fault of the
> folks who were working on branch 0.22.  So a related policy we might add
> to prevent such situations in the future might be that if you backport
> something from branch n to n-2 then you ought to also be required to
> backport it to branch n-1 and in general to all intervening branches.
> Does that seem sensible?
>
> Doug

Re: Naming of Hadoop releases

[Doug Cutting <cu...@apache.org>]

On 03/19/2012 02:47 PM, Arun C Murthy wrote:
> This is against the Apache Hadoop release policy on major releases i.e. only features deprecated for at least one release can be removed.

In many case the reason this happened was that features were backported
from trunk to 0.20 but not to 0.22.  In other words, its no fault of the
folks who were working on branch 0.22.  So a related policy we might add
to prevent such situations in the future might be that if you backport
something from branch n to n-2 then you ought to also be required to
backport it to branch n-1 and in general to all intervening branches.
Does that seem sensible?

Doug

Re: Naming of Hadoop releases

[Mi...@emc.com]

Arun,

As Konstantin has noted in the email below:

> If the community decides to rename .22 to 2 I will be glad to work on it.


My inclination (as I have communicated to several people at apachecon) is
to upgrade our clusters from 1.0 to 0.23 (whatever it is called when it
becomes stable). The reason for this is the pain of backporting patches to
0.22 from trunk (because of mavenization.)

This does not mean that 0.22 is abandoned. Other than eBay, I know of two
sizeable deployments of 0.22 in universities. And other than removing
LinuxTaskController (which those folks apparently do not care about),
there are many more features in 0.22 that they *do* care about.

- Milind

On 3/19/12 2:47 PM, "Arun C Murthy" <ac...@hortonworks.com> wrote:

>Konstantin and Milind,
>
> As I've noted on the other thread (my bad):
>
>> However, the problem is that hadoop-0.22 has removed public and
>>non-deprecated apis/features (i.e. security) which are present in
>>branch-1 (previously branch-0.20.2xx).
>> 
>> This is against the Apache Hadoop release policy on major releases i.e.
>>only features deprecated for at least one release can be removed.
>
>This is a long standing issue with branch-0.22 - are either of you
>planning on fixing this? If so, could you please share some
>roadmap/timelines?
>
>thanks,
>Arun
>
>On Mar 19, 2012, at 12:34 PM, <Mi...@emc.com>
><Mi...@emc.com> wrote:
>
>> I agree with Konstantin. In previous discussion, I had suggested
>> simultaneous renumbering, but for some reason it was not considered.
>> 
>> (For history buffs: I upgraded from Windows 1.0 to Windows 3.1 straight.
>> Windows 2.0 did not have many features that made it compelling to
>>upgrade.
>> It did not seem odd to skip a number then, and I don't see why it would
>> now. I also skipped Windows Vista and upgraded from XP to Windows 7,
>>even
>> if Vista was touted as a major release.)
>> 
>> - Milind
>> 
>> ---
>> Milind Bhandarkar
>> Chief Architect, Greenplum Labs, Data Computing Division, EMC
>> +1-650-523-3858 (W)
>> +1-408-666-8483 (M)
>> 
>> 
>> 
>> On 3/19/12 12:04 PM, "Konstantin Shvachko" <sh...@gmail.com> wrote:
>> 
>>> Hadoop naming is definitely confusing. And having Hadoop-1 did not
>>> make it less confusing for users.
>>> 
>>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>>> released)
>>> 
>>> It was released on November 29, 2011.
>>> eBay is actively using it as of today.
>>> 
>>> If the goal of renaming branches is to make things less confusing
>>> about Hadoop, then I agree with people saying we should do a
>>> simultaneous rename of the branches. That is
>>> Current 0.22 -> 2
>>> Current 0.23 -> 3
>>> 
>>> It almost sounds like release .22 does not deserve a whole number,
>>> only a fraction. But having .22 renamed to 1.5 creates a confusion
>>> that it belongs to Hadoop-1 line, which is not exactly the message we
>>> want to send out.
>>> Also I don't know what the number of commits reflects, and whether it
>>> is good or not to have many for a particular release.
>>> 
>>> If the community decides to rename .22 to 2 I will be glad to work on
>>>it.
>>> 
>>> Thanks,
>>> --Konstantin
>>> 
>>> On Sun, Mar 18, 2012 at 11:04 AM, Todd Papaioannou
>>> <dr...@gmail.com> wrote:
>>>> On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:
>>>> 
>>>>> 9.22 can't be considered as 1.5 because it is the major release from
>>>>> 1.0 (old
>>>>> 0.20.x). Besides, by declaring it as 1.5 we'll be planting future
>>>>> confusion of
>>>>> the same sort that happened around 0.20* line.
>>>>> 
>>>>> And last but not least, the same  discussion has happened in the past
>>>>> around
>>>>> 1.0 release time like http://is.gd/x1fVqu
>>>> 
>>>> Yes I remember it well, but AFAIC there was no clear decision on 0.22
>>>> or 0.23. There were competing proposals and opinions and basically
>>>>what
>>>> happened was that we punted the decision on anything other than
>>>> 0.20->1.0 until a later date. But, that later date is now approaching
>>>> and we continue to call the current release in question 0.23. Hence my
>>>> original email.
>>>> 
>>>> Personally, I do not believe 0.22 is sufficiently major to call it 2.0
>>>> and push 0.23 to 3.0. But that's just my $0.02. I don't feel strongly
>>>> enough to worry about what the outcome is.
>>>> 
>>>> What I _do_ care strongly about is that we get some resolution and
>>>>stop
>>>> using 0.23 as a release name. It's confusing to the market and the
>>>> customer base, and while we have made great progress in simplifying
>>>> things with the 1.0 release moniker, we need to continue to make
>>>> progress.
>>>> 
>>>> ToddP
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> Cos
>>>>> 
>>>>> 
>>>>> On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
>>>>>> All,
>>>>>> 
>>>>>> With the upcoming release of 0.23, isn't it about time that we
>>>>>> started calling 0.23 "Hadoop 2.0" instead?
>>>>>> 
>>>>>> While the numbering system may make sense to everyone here, to the
>>>>>> rest of the world it's going to be hella confusing for 0.23 to come
>>>>>> out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think
>>>>>> that it would make sense to call it 2.0. Also, I think would really
>>>>>> help with the brand awareness/perception of the project in the wider
>>>>>> customer audience.
>>>>>> 
>>>>>> I know there are some other potential releases out there too, so my
>>>>>> overall suggestion would be:
>>>>>> 
>>>>>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
>>>>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>>>>> released)
>>>>>> Current 0.23 -> Gets renamed to 2.0
>>>>>> 
>>>>>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was
>>>>>> to make project progress more understandable to the rest of the
>>>>>>world.
>>>>>> We should ensure we don't regress with the next major release.
>>>>>> 
>>>>>> Thoughts?
>>>>>> 
>>>>>> ToddP
>>>>>> 
>>>> 
>>> 
>> 
>
>--
>Arun C. Murthy
>Hortonworks Inc.
>http://hortonworks.com/
>
>

Re: Naming of Hadoop releases

[Arun C Murthy <ac...@hortonworks.com>]

Konstantin and Milind,

 As I've noted on the other thread (my bad):

> However, the problem is that hadoop-0.22 has removed public and non-deprecated apis/features (i.e. security) which are present in branch-1 (previously branch-0.20.2xx). 
> 
> This is against the Apache Hadoop release policy on major releases i.e. only features deprecated for at least one release can be removed.

This is a long standing issue with branch-0.22 - are either of you planning on fixing this? If so, could you please share some roadmap/timelines?

thanks,
Arun

On Mar 19, 2012, at 12:34 PM, <Mi...@emc.com> <Mi...@emc.com> wrote:

> I agree with Konstantin. In previous discussion, I had suggested
> simultaneous renumbering, but for some reason it was not considered.
> 
> (For history buffs: I upgraded from Windows 1.0 to Windows 3.1 straight.
> Windows 2.0 did not have many features that made it compelling to upgrade.
> It did not seem odd to skip a number then, and I don't see why it would
> now. I also skipped Windows Vista and upgraded from XP to Windows 7, even
> if Vista was touted as a major release.)
> 
> - Milind
> 
> ---
> Milind Bhandarkar
> Chief Architect, Greenplum Labs, Data Computing Division, EMC
> +1-650-523-3858 (W)
> +1-408-666-8483 (M)
> 
> 
> 
> On 3/19/12 12:04 PM, "Konstantin Shvachko" <sh...@gmail.com> wrote:
> 
>> Hadoop naming is definitely confusing. And having Hadoop-1 did not
>> make it less confusing for users.
>> 
>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>> released)
>> 
>> It was released on November 29, 2011.
>> eBay is actively using it as of today.
>> 
>> If the goal of renaming branches is to make things less confusing
>> about Hadoop, then I agree with people saying we should do a
>> simultaneous rename of the branches. That is
>> Current 0.22 -> 2
>> Current 0.23 -> 3
>> 
>> It almost sounds like release .22 does not deserve a whole number,
>> only a fraction. But having .22 renamed to 1.5 creates a confusion
>> that it belongs to Hadoop-1 line, which is not exactly the message we
>> want to send out.
>> Also I don't know what the number of commits reflects, and whether it
>> is good or not to have many for a particular release.
>> 
>> If the community decides to rename .22 to 2 I will be glad to work on it.
>> 
>> Thanks,
>> --Konstantin
>> 
>> On Sun, Mar 18, 2012 at 11:04 AM, Todd Papaioannou
>> <dr...@gmail.com> wrote:
>>> On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:
>>> 
>>>> 9.22 can't be considered as 1.5 because it is the major release from
>>>> 1.0 (old
>>>> 0.20.x). Besides, by declaring it as 1.5 we'll be planting future
>>>> confusion of
>>>> the same sort that happened around 0.20* line.
>>>> 
>>>> And last but not least, the same  discussion has happened in the past
>>>> around
>>>> 1.0 release time like http://is.gd/x1fVqu
>>> 
>>> Yes I remember it well, but AFAIC there was no clear decision on 0.22
>>> or 0.23. There were competing proposals and opinions and basically what
>>> happened was that we punted the decision on anything other than
>>> 0.20->1.0 until a later date. But, that later date is now approaching
>>> and we continue to call the current release in question 0.23. Hence my
>>> original email.
>>> 
>>> Personally, I do not believe 0.22 is sufficiently major to call it 2.0
>>> and push 0.23 to 3.0. But that's just my $0.02. I don't feel strongly
>>> enough to worry about what the outcome is.
>>> 
>>> What I _do_ care strongly about is that we get some resolution and stop
>>> using 0.23 as a release name. It's confusing to the market and the
>>> customer base, and while we have made great progress in simplifying
>>> things with the 1.0 release moniker, we need to continue to make
>>> progress.
>>> 
>>> ToddP
>>> 
>>> 
>>> 
>>>> 
>>>> Cos
>>>> 
>>>> 
>>>> On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
>>>>> All,
>>>>> 
>>>>> With the upcoming release of 0.23, isn't it about time that we
>>>>> started calling 0.23 "Hadoop 2.0" instead?
>>>>> 
>>>>> While the numbering system may make sense to everyone here, to the
>>>>> rest of the world it's going to be hella confusing for 0.23 to come
>>>>> out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think
>>>>> that it would make sense to call it 2.0. Also, I think would really
>>>>> help with the brand awareness/perception of the project in the wider
>>>>> customer audience.
>>>>> 
>>>>> I know there are some other potential releases out there too, so my
>>>>> overall suggestion would be:
>>>>> 
>>>>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
>>>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>>>> released)
>>>>> Current 0.23 -> Gets renamed to 2.0
>>>>> 
>>>>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was
>>>>> to make project progress more understandable to the rest of the world.
>>>>> We should ensure we don't regress with the next major release.
>>>>> 
>>>>> Thoughts?
>>>>> 
>>>>> ToddP
>>>>> 
>>> 
>> 
> 

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

Re: Naming of Hadoop releases

[Mi...@emc.com]

I agree with Konstantin. In previous discussion, I had suggested
simultaneous renumbering, but for some reason it was not considered.

(For history buffs: I upgraded from Windows 1.0 to Windows 3.1 straight.
Windows 2.0 did not have many features that made it compelling to upgrade.
It did not seem odd to skip a number then, and I don't see why it would
now. I also skipped Windows Vista and upgraded from XP to Windows 7, even
if Vista was touted as a major release.)

- Milind

---
Milind Bhandarkar
Chief Architect, Greenplum Labs, Data Computing Division, EMC
+1-650-523-3858 (W)
+1-408-666-8483 (M)



On 3/19/12 12:04 PM, "Konstantin Shvachko" <sh...@gmail.com> wrote:

>Hadoop naming is definitely confusing. And having Hadoop-1 did not
>make it less confusing for users.
>
>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>released)
>
>It was released on November 29, 2011.
>eBay is actively using it as of today.
>
>If the goal of renaming branches is to make things less confusing
>about Hadoop, then I agree with people saying we should do a
>simultaneous rename of the branches. That is
>Current 0.22 -> 2
>Current 0.23 -> 3
>
>It almost sounds like release .22 does not deserve a whole number,
>only a fraction. But having .22 renamed to 1.5 creates a confusion
>that it belongs to Hadoop-1 line, which is not exactly the message we
>want to send out.
>Also I don't know what the number of commits reflects, and whether it
>is good or not to have many for a particular release.
>
>If the community decides to rename .22 to 2 I will be glad to work on it.
>
>Thanks,
>--Konstantin
>
>On Sun, Mar 18, 2012 at 11:04 AM, Todd Papaioannou
><dr...@gmail.com> wrote:
>> On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:
>>
>>> 9.22 can't be considered as 1.5 because it is the major release from
>>>1.0 (old
>>> 0.20.x). Besides, by declaring it as 1.5 we'll be planting future
>>>confusion of
>>> the same sort that happened around 0.20* line.
>>>
>>> And last but not least, the same  discussion has happened in the past
>>>around
>>> 1.0 release time like http://is.gd/x1fVqu
>>
>> Yes I remember it well, but AFAIC there was no clear decision on 0.22
>>or 0.23. There were competing proposals and opinions and basically what
>>happened was that we punted the decision on anything other than
>>0.20->1.0 until a later date. But, that later date is now approaching
>>and we continue to call the current release in question 0.23. Hence my
>>original email.
>>
>> Personally, I do not believe 0.22 is sufficiently major to call it 2.0
>>and push 0.23 to 3.0. But that's just my $0.02. I don't feel strongly
>>enough to worry about what the outcome is.
>>
>> What I _do_ care strongly about is that we get some resolution and stop
>>using 0.23 as a release name. It's confusing to the market and the
>>customer base, and while we have made great progress in simplifying
>>things with the 1.0 release moniker, we need to continue to make
>>progress.
>>
>> ToddP
>>
>>
>>
>>>
>>> Cos
>>>
>>>
>>> On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
>>>> All,
>>>>
>>>> With the upcoming release of 0.23, isn't it about time that we
>>>>started calling 0.23 "Hadoop 2.0" instead?
>>>>
>>>> While the numbering system may make sense to everyone here, to the
>>>>rest of the world it's going to be hella confusing for 0.23 to come
>>>>out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think
>>>>that it would make sense to call it 2.0. Also, I think would really
>>>>help with the brand awareness/perception of the project in the wider
>>>>customer audience.
>>>>
>>>> I know there are some other potential releases out there too, so my
>>>>overall suggestion would be:
>>>>
>>>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
>>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and
>>>>released)
>>>> Current 0.23 -> Gets renamed to 2.0
>>>>
>>>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was
>>>>to make project progress more understandable to the rest of the world.
>>>>We should ensure we don't regress with the next major release.
>>>>
>>>> Thoughts?
>>>>
>>>> ToddP
>>>>
>>
>

Re: Naming of Hadoop releases

[Konstantin Shvachko <sh...@gmail.com>]

Hadoop naming is definitely confusing. And having Hadoop-1 did not
make it less confusing for users.

> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)

It was released on November 29, 2011.
eBay is actively using it as of today.

If the goal of renaming branches is to make things less confusing
about Hadoop, then I agree with people saying we should do a
simultaneous rename of the branches. That is
Current 0.22 -> 2
Current 0.23 -> 3

It almost sounds like release .22 does not deserve a whole number,
only a fraction. But having .22 renamed to 1.5 creates a confusion
that it belongs to Hadoop-1 line, which is not exactly the message we
want to send out.
Also I don't know what the number of commits reflects, and whether it
is good or not to have many for a particular release.

If the community decides to rename .22 to 2 I will be glad to work on it.

Thanks,
--Konstantin

On Sun, Mar 18, 2012 at 11:04 AM, Todd Papaioannou
<dr...@gmail.com> wrote:
> On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:
>
>> 9.22 can't be considered as 1.5 because it is the major release from 1.0 (old
>> 0.20.x). Besides, by declaring it as 1.5 we'll be planting future confusion of
>> the same sort that happened around 0.20* line.
>>
>> And last but not least, the same  discussion has happened in the past around
>> 1.0 release time like http://is.gd/x1fVqu
>
> Yes I remember it well, but AFAIC there was no clear decision on 0.22 or 0.23. There were competing proposals and opinions and basically what happened was that we punted the decision on anything other than 0.20->1.0 until a later date. But, that later date is now approaching and we continue to call the current release in question 0.23. Hence my original email.
>
> Personally, I do not believe 0.22 is sufficiently major to call it 2.0 and push 0.23 to 3.0. But that's just my $0.02. I don't feel strongly enough to worry about what the outcome is.
>
> What I _do_ care strongly about is that we get some resolution and stop using 0.23 as a release name. It's confusing to the market and the customer base, and while we have made great progress in simplifying things with the 1.0 release moniker, we need to continue to make progress.
>
> ToddP
>
>
>
>>
>> Cos
>>
>>
>> On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
>>> All,
>>>
>>> With the upcoming release of 0.23, isn't it about time that we started calling 0.23 "Hadoop 2.0" instead?
>>>
>>> While the numbering system may make sense to everyone here, to the rest of the world it's going to be hella confusing for 0.23 to come out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would make sense to call it 2.0. Also, I think would really help with the brand awareness/perception of the project in the wider customer audience.
>>>
>>> I know there are some other potential releases out there too, so my overall suggestion would be:
>>>
>>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
>>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
>>> Current 0.23 -> Gets renamed to 2.0
>>>
>>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to make project progress more understandable to the rest of the world. We should ensure we don't regress with the next major release.
>>>
>>> Thoughts?
>>>
>>> ToddP
>>>
>

Re: Naming of Hadoop releases

[Todd Papaioannou <dr...@gmail.com>]

On Mar 18, 2012, at 10:01 AM, Konstantin Boudnik wrote:

> 9.22 can't be considered as 1.5 because it is the major release from 1.0 (old
> 0.20.x). Besides, by declaring it as 1.5 we'll be planting future confusion of
> the same sort that happened around 0.20* line.
> 
> And last but not least, the same  discussion has happened in the past around
> 1.0 release time like http://is.gd/x1fVqu

Yes I remember it well, but AFAIC there was no clear decision on 0.22 or 0.23. There were competing proposals and opinions and basically what happened was that we punted the decision on anything other than 0.20->1.0 until a later date. But, that later date is now approaching and we continue to call the current release in question 0.23. Hence my original email.

Personally, I do not believe 0.22 is sufficiently major to call it 2.0 and push 0.23 to 3.0. But that's just my $0.02. I don't feel strongly enough to worry about what the outcome is. 

What I _do_ care strongly about is that we get some resolution and stop using 0.23 as a release name. It's confusing to the market and the customer base, and while we have made great progress in simplifying things with the 1.0 release moniker, we need to continue to make progress.

ToddP



> 
> Cos
> 
> 
> On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
>> All,
>> 
>> With the upcoming release of 0.23, isn't it about time that we started calling 0.23 "Hadoop 2.0" instead?
>> 
>> While the numbering system may make sense to everyone here, to the rest of the world it's going to be hella confusing for 0.23 to come out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would make sense to call it 2.0. Also, I think would really help with the brand awareness/perception of the project in the wider customer audience.
>> 
>> I know there are some other potential releases out there too, so my overall suggestion would be:
>> 
>> Current 1.X -> Remains 1.x (as new bug fix releases are released)
>> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
>> Current 0.23 -> Gets renamed to 2.0
>> 
>> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to make project progress more understandable to the rest of the world. We should ensure we don't regress with the next major release.
>> 
>> Thoughts?
>> 
>> ToddP
>> 

Re: Naming of Hadoop releases

[Konstantin Boudnik <co...@apache.org>]

9.22 can't be considered as 1.5 because it is the major release from 1.0 (old
0.20.x). Besides, by declaring it as 1.5 we'll be planting future confusion of
the same sort that happened around 0.20* line.

And last but not least, the same  discussion has happened in the past around
1.0 release time like http://is.gd/x1fVqu

Cos


On Sat, Mar 17, 2012 at 10:41PM, Todd Papaioannou wrote:
> All,
> 
> With the upcoming release of 0.23, isn't it about time that we started calling 0.23 "Hadoop 2.0" instead?
> 
> While the numbering system may make sense to everyone here, to the rest of the world it's going to be hella confusing for 0.23 to come out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would make sense to call it 2.0. Also, I think would really help with the brand awareness/perception of the project in the wider customer audience.
> 
> I know there are some other potential releases out there too, so my overall suggestion would be:
> 
> Current 1.X -> Remains 1.x (as new bug fix releases are released)
> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
> Current 0.23 -> Gets renamed to 2.0
> 
> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to make project progress more understandable to the rest of the world. We should ensure we don't regress with the next major release.
> 
> Thoughts?
> 
> ToddP
> 

Re: Naming of Hadoop releases

[Harsh J <ha...@cloudera.com>]

Hi,

Just one concern I wanted to expresss:

On Sun, Mar 18, 2012 at 11:11 AM, Todd Papaioannou
<dr...@gmail.com> wrote:
[Snip]
> Current 1.X -> Remains 1.x (as new bug fix releases are released)
> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
> Current 0.23 -> Gets renamed to 2.0
[Snip]

With 1.x (Like 1.1 is a release being planned, for instance, and am
not sure if that will ever be the last one), moving 0.22 to 1.5 may
cause confusion in future. Either we define a limit for the 1.x line,
or we renumber this proposal.

-- 
Harsh J

Naming of Hadoop releases

[Todd Papaioannou <dr...@gmail.com>]

All,

With the upcoming release of 0.23, isn't it about time that we started calling 0.23 "Hadoop 2.0" instead?

While the numbering system may make sense to everyone here, to the rest of the world it's going to be hella confusing for 0.23 to come out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would make sense to call it 2.0. Also, I think would really help with the brand awareness/perception of the project in the wider customer audience.

I know there are some other potential releases out there too, so my overall suggestion would be:

Current 1.X -> Remains 1.x (as new bug fix releases are released)
Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
Current 0.23 -> Gets renamed to 2.0

Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to make project progress more understandable to the rest of the world. We should ensure we don't regress with the next major release.

Thoughts?

ToddP

Re: [VOTE] Merging 0.23-PB to 0.23

["Aaron T. Myers" <at...@cloudera.com>]

Hi ToddP,

Would you mind starting a new thread on general@ to discuss release
renumbering? It seems to me that that issue is orthogonal to what's being
discussed in this thread.

Thanks a lot,
Aaron

--
Aaron T. Myers
Software Engineer, Cloudera



On Sat, Mar 17, 2012 at 8:10 PM, Todd Papaioannou <dr...@gmail.com>wrote:

> Isn't it about time that we started calling 0.23 "Hadoop 2.0" instead?
> While the numbering system may make sense to everyone here, to the rest of
> the world it's going to be hella confusing for 0.23 to come out after
> Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would
> make sense to call it 2.0. Also, I think would really help with the brand
> awareness/perception of the project in the wider customer audience.
>
> I know there are some other potential releases out there too, so my
> overall suggestion would be:
>
> Current 1.X -> Remains 1.x (as new bug fix releases are released)
> Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
> Current 0.23 -> Gets renamed to 2.0
>
> Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to
> make project progress more understandable to the rest of the world. We
> should ensure we don't regress with the next major release.
>
> Thoughts?
>
> ToddP
>
>
> On Mar 17, 2012, at 2:51 PM, Eli Collins wrote:
>
> > On Wed, Feb 22, 2012 at 9:36 PM, Arun C Murthy <ac...@hortonworks.com>
> wrote:
> >> +1, nice to see this go in to branch-0.23.
> >>
> >> Given the discussion on the hadoop-0.23.1 voting thread, can I request
> the fix-version for this to be 23.3? As I've mentioned there I'm thinking a
> 23.2 as a small bug-fix release in a week or so with some critical
> fixes/enhancements - this won't affect the PB merge at all.
> >>
> >
> > Arun,  are you still planning to do a quick 23.2 release? Given that
> > it's been a month and PB and HA are in checked in we should cut a new
> > 23.2 branch?
> >
> > Thanks,
> > Eli
>
>

Re: [VOTE] Merging 0.23-PB to 0.23

[Todd Papaioannou <dr...@gmail.com>]

Isn't it about time that we started calling 0.23 "Hadoop 2.0" instead? While the numbering system may make sense to everyone here, to the rest of the world it's going to be hella confusing for 0.23 to come out after Hadoop 1.0 was released. Since 0.23 has MR2 in it I think that it would make sense to call it 2.0. Also, I think would really help with the brand awareness/perception of the project in the wider customer audience.

I know there are some other potential releases out there too, so my overall suggestion would be:

Current 1.X -> Remains 1.x (as new bug fix releases are released)
Current 0.22 -> Gets renamed to 1.5 (if it ever gets tested and released)
Current 0.23 -> Gets renamed to 2.0

Remember, a large part of the reason for renaming 0.20.xx to 1.0 was to make project progress more understandable to the rest of the world. We should ensure we don't regress with the next major release.

Thoughts?

ToddP


On Mar 17, 2012, at 2:51 PM, Eli Collins wrote:

> On Wed, Feb 22, 2012 at 9:36 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
>> +1, nice to see this go in to branch-0.23.
>> 
>> Given the discussion on the hadoop-0.23.1 voting thread, can I request the fix-version for this to be 23.3? As I've mentioned there I'm thinking a 23.2 as a small bug-fix release in a week or so with some critical fixes/enhancements - this won't affect the PB merge at all.
>> 
> 
> Arun,  are you still planning to do a quick 23.2 release? Given that
> it's been a month and PB and HA are in checked in we should cut a new
> 23.2 branch?
> 
> Thanks,
> Eli

Re: [VOTE] Merging 0.23-PB to 0.23

[Konstantin Boudnik <co...@apache.org>]

On Sun, Mar 18, 2012 at 08:25PM, Todd Papaioannou wrote:
> On Mar 18, 2012, at 7:18 PM, Roman Shaposhnik wrote:
> > Personally, I'm for branch-3. Regardless of the potential of .22 I'd
> > rather keep a slot for it. Worse case -- we don't have Hadoop 2 ever.
> 
> Well, that would just be silly ;)  The whole point of renaming releases was

Bravo! Well formulated and grown up argument at last!

> to present a better face to the rest of the world. I don't think it's going
> to be that fun having to try to explain why there was a Hadoop 1.0 and a
> Hadoop 3.0 but Hadoop 2.0 never came out.
> 
> ToddP
> 
> 
> 

Re: [VOTE] Merging 0.23-PB to 0.23

[Roman Shaposhnik <rv...@apache.org>]

On Sun, Mar 18, 2012 at 8:25 PM, Todd Papaioannou <dr...@gmail.com> wrote:
> On Mar 18, 2012, at 7:18 PM, Roman Shaposhnik wrote:
>> Personally, I'm for branch-3. Regardless of the potential of .22 I'd
>> rather keep a slot for it. Worse case -- we don't have Hadoop 2 ever.
>
> Well, that would just be silly ;)

Well, then Microsoft, Sun, RedHat, Novell were all just plain silly.
They all had platforms in the market that skipped versions and
that was ok. Where's my Windows 6? Nobody seems to be
obsessing over it much.

> The whole point of renaming releases was to present a better face to the
> rest of the world. I don't think it's going to be that fun having to try to explain
> why there was a Hadoop 1.0 and a Hadoop 3.0 but Hadoop 2.0 never came out.

I don't think the above paragraph makes much sense. But you're entitled to
your opinion. Which means, when time comes to voting you are going
to vote according to it. I'm not sure there's much need for any extra leadership
here.

Thanks,
Roman.

Re: [VOTE] Merging 0.23-PB to 0.23

[Todd Papaioannou <dr...@gmail.com>]

On Mar 18, 2012, at 7:18 PM, Roman Shaposhnik wrote:
> Personally, I'm for branch-3. Regardless of the potential of .22 I'd
> rather keep a slot for it. Worse case -- we don't have Hadoop 2 ever.

Well, that would just be silly ;)  The whole point of renaming releases was to present a better face to the rest of the world. I don't think it's going to be that fun having to try to explain why there was a Hadoop 1.0 and a Hadoop 3.0 but Hadoop 2.0 never came out.

ToddP

Re: [VOTE] Merging 0.23-PB to 0.23

[Arun C Murthy <ac...@hortonworks.com>]

On Mar 18, 2012, at 7:18 PM, Roman Shaposhnik wrote:

> On Sun, Mar 18, 2012 at 6:31 PM, Arun Murthy <ac...@hortonworks.com> wrote:
>>  Agree. In fact, I'm happy to rename branch-0.23 to branch-Y (Y > 1),
>> if we can agree on the other thread, & create the RC.
>> 
>>  I agree with Todd (P) that its time to call it some thing other than
>> 0.23, particularly with HDFS Wire-Compat and HA. Thoughts?
> 
> It might be useful to put various options up for the community vote.
> We don't have too many of them, really:
>   branch-2
>   branch-3
> 
> Personally, I'm for branch-3. Regardless of the potential of .22 I'd
> rather keep a slot for it. Worse case -- we don't have Hadoop 2 ever.

That seems reasonable at first glance.

However, the problem is that hadoop-0.22 has removed public and non-deprecated apis/features (i.e. security) which are present in branch-1 (previously branch-0.20.2xx). 

This is against the Apache Hadoop release policy on major releases i.e. only features deprecated for at least one release can be removed.

To their credit, the folks driving branch-0.22 (Konstantin et al) have always been clear that they do not plan to support security in branch-0.22 - but, it still is a blocker for renaming hadoop-0.22 to hadoop-2. 

Given that
# It's been ~16 months since we branched 0.22
# It's been ~12 months since we released hadoop-0.20.203 which eventually became branch-1
# It's been ~9 months since security was removed from branch-0.22
# The vast majority of the contributors have moved on to trunk/branch-0.23 (#patches & #commits for past several months).
it's unlikely that branch-0.22 will ever be a super-set of branch-1 and support security.

To be clear, this isn't to discourage folks from working on branch-0.22. As always, people are welcome to 'scratch the itch' and Konstantin has done a great job pushing branch-0.22. Folks are welcome to continue to push for future releases off branch-0.22 called hadoop-0.22.xxx.

In summary, unless we can find someone to step up and fix/validate security in branch-0.22 in very short order, say next month or so (given it's long history), I don't think it makes sense to rename branch-0.22 to branch-2. 

Roman - Would you like to step up and fix & validate security in branch-0.22? 
If so, can you let us know how soon? 
If not, I don't think it makes sense to 'leave a hole' for branch-0.22 forever since branch-0.23 is a super-set of branch-1 and branch-0.22 anyway.

Arun

Re: [VOTE] Merging 0.23-PB to 0.23

[Roman Shaposhnik <rv...@apache.org>]

On Sun, Mar 18, 2012 at 6:31 PM, Arun Murthy <ac...@hortonworks.com> wrote:
>  Agree. In fact, I'm happy to rename branch-0.23 to branch-Y (Y > 1),
> if we can agree on the other thread, & create the RC.
>
>  I agree with Todd (P) that its time to call it some thing other than
> 0.23, particularly with HDFS Wire-Compat and HA. Thoughts?

It might be useful to put various options up for the community vote.
We don't have too many of them, really:
   branch-2
   branch-3

Personally, I'm for branch-3. Regardless of the potential of .22 I'd
rather keep a slot for it. Worse case -- we don't have Hadoop 2 ever.

Thanks,
Roman.

Re: [VOTE] Merging 0.23-PB to 0.23

[Arun Murthy <ac...@hortonworks.com>]

 Agree. In fact, I'm happy to rename branch-0.23 to branch-Y (Y > 1),
if we can agree on the other thread, & create the RC.

 I agree with Todd (P) that its time to call it some thing other than
0.23, particularly with HDFS Wire-Compat and HA. Thoughts?

Sent from my iPhone

On Mar 17, 2012, at 2:51 PM, Eli Collins <el...@cloudera.com> wrote:

> On Wed, Feb 22, 2012 at 9:36 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
>> +1, nice to see this go in to branch-0.23.
>>
>> Given the discussion on the hadoop-0.23.1 voting thread, can I request the fix-version for this to be 23.3? As I've mentioned there I'm thinking a 23.2 as a small bug-fix release in a week or so with some critical fixes/enhancements - this won't affect the PB merge at all.
>>
>
> Arun,  are you still planning to do a quick 23.2 release? Given that
> it's been a month and PB and HA are in checked in we should cut a new
> 23.2 branch?
>
> Thanks,
> Eli

Re: [VOTE] Merging 0.23-PB to 0.23

[Eli Collins <el...@cloudera.com>]

On Wed, Feb 22, 2012 at 9:36 PM, Arun C Murthy <ac...@hortonworks.com> wrote:
> +1, nice to see this go in to branch-0.23.
>
> Given the discussion on the hadoop-0.23.1 voting thread, can I request the fix-version for this to be 23.3? As I've mentioned there I'm thinking a 23.2 as a small bug-fix release in a week or so with some critical fixes/enhancements - this won't affect the PB merge at all.
>

Arun,  are you still planning to do a quick 23.2 release? Given that
it's been a month and PB and HA are in checked in we should cut a new
23.2 branch?

Thanks,
Eli

Re: [VOTE] Merging 0.23-PB to 0.23

[Arun C Murthy <ac...@hortonworks.com>]

+1, nice to see this go in to branch-0.23.

Given the discussion on the hadoop-0.23.1 voting thread, can I request the fix-version for this to be 23.3? As I've mentioned there I'm thinking a 23.2 as a small bug-fix release in a week or so with some critical fixes/enhancements - this won't affect the PB merge at all.

Makes sense?

thanks,
Arun

On Feb 23, 2012, at 10:33 AM, Suresh Srinivas wrote:

> +1.
> 
> On Wed, Feb 22, 2012 at 4:02 PM, Tsz Wo (Nicholas), Sze <
> s29752-hadoopgeneral@yahoo.com> wrote:
> 
>> We actually require to have a vote according to the bylaws (Thanks Aaron
>> Myers for the kindly note.)  Please check the branch and vote.
>> 
>> Tsz-Wo Nicholas Sze
>> 
>> Hortonworks Inc.
>> http://hortonworks.com/
>> 
>> 
>> ________________________________
>> From: Mahadev Konar <ma...@hortonworks.com>
>> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <
>> s29752-hadoopgeneral@yahoo.com>
>> Sent: Wednesday, February 22, 2012 3:30 PM
>> Subject: Re: Merging 0.23-PB to 0.23
>> 
>> Sounds great! +1 for merging. Would be good to get this into 0.23
>> branch as soon as possible.
>> 
>> Mahadev Konar
>> Hortonworks Inc.
>> http://hortonworks.com/
>> 
>> 
>> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
>> <s2...@yahoo.com> wrote:
>>> Hi,
>>> 
>>> The IPC protocol buffer feature in trunk is complete.  It is time to
>> merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23
>> can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge
>> it tomorrow.  Please let me know if you have any concern.
>>> 
>>> Regards,
>>> 
>>> Tsz-Wo Nicholas Sze
>>> Hortonworks Inc.
>>> http://hortonworks.com/
>> 

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

Re: [VOTE] Merging 0.23-PB to 0.23

[Suresh Srinivas <su...@hortonworks.com>]

+1.

On Wed, Feb 22, 2012 at 4:02 PM, Tsz Wo (Nicholas), Sze <
s29752-hadoopgeneral@yahoo.com> wrote:

> We actually require to have a vote according to the bylaws (Thanks Aaron
> Myers for the kindly note.)  Please check the branch and vote.
>
> Tsz-Wo Nicholas Sze
>
> Hortonworks Inc.
> http://hortonworks.com/
>
>
> ________________________________
> From: Mahadev Konar <ma...@hortonworks.com>
> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <
> s29752-hadoopgeneral@yahoo.com>
> Sent: Wednesday, February 22, 2012 3:30 PM
> Subject: Re: Merging 0.23-PB to 0.23
>
> Sounds great! +1 for merging. Would be good to get this into 0.23
> branch as soon as possible.
>
> Mahadev Konar
> Hortonworks Inc.
> http://hortonworks.com/
>
>
> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
> <s2...@yahoo.com> wrote:
> > Hi,
> >
> > The IPC protocol buffer feature in trunk is complete.  It is time to
> merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23
> can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge
> it tomorrow.  Please let me know if you have any concern.
> >
> > Regards,
> >
> > Tsz-Wo Nicholas Sze
> > Hortonworks Inc.
> > http://hortonworks.com/
>

Re: [VOTE] Merging 0.23-PB to 0.23

[Jitendra Pandey <ji...@hortonworks.com>]

+1

On Wed, Feb 22, 2012 at 4:02 PM, Tsz Wo (Nicholas), Sze <
s29752-hadoopgeneral@yahoo.com> wrote:

> We actually require to have a vote according to the bylaws (Thanks Aaron
> Myers for the kindly note.)  Please check the branch and vote.
>
> Tsz-Wo Nicholas Sze
>
> Hortonworks Inc.
> http://hortonworks.com/
>
>
> ________________________________
> From: Mahadev Konar <ma...@hortonworks.com>
> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <
> s29752-hadoopgeneral@yahoo.com>
> Sent: Wednesday, February 22, 2012 3:30 PM
> Subject: Re: Merging 0.23-PB to 0.23
>
> Sounds great! +1 for merging. Would be good to get this into 0.23
> branch as soon as possible.
>
> Mahadev Konar
> Hortonworks Inc.
> http://hortonworks.com/
>
>
> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
> <s2...@yahoo.com> wrote:
> > Hi,
> >
> > The IPC protocol buffer feature in trunk is complete.  It is time to
> merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23
> can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge
> it tomorrow.  Please let me know if you have any concern.
> >
> > Regards,
> >
> > Tsz-Wo Nicholas Sze
> > Hortonworks Inc.
> > http://hortonworks.com/
>



--

Re: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,

The merging is done.  You may resume your commit as usual.  Thank you.


Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/




----- Original Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: common dev <co...@hadoop.apache.org>; hdfs dev <hd...@hadoop.apache.org>; mapreduce-dev hadoop <ma...@hadoop.apache.org>
Cc: 
Sent: Sunday, February 26, 2012 8:39 PM
Subject: Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

Hi dev,

I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Re: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,

The merging is done.  You may resume your commit as usual.  Thank you.


Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/




----- Original Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: common dev <co...@hadoop.apache.org>; hdfs dev <hd...@hadoop.apache.org>; mapreduce-dev hadoop <ma...@hadoop.apache.org>
Cc: 
Sent: Sunday, February 26, 2012 8:39 PM
Subject: Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

Hi dev,

I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Re: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,

The merging is done.  You may resume your commit as usual.  Thank you.


Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/




----- Original Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: common dev <co...@hadoop.apache.org>; hdfs dev <hd...@hadoop.apache.org>; mapreduce-dev hadoop <ma...@hadoop.apache.org>
Cc: 
Sent: Sunday, February 26, 2012 8:39 PM
Subject: Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

Hi dev,

I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,


I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,


I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,


I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,

I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.


Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,

I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.


Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Fw: [RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

Hi dev,

I am merging 0.23-PB back to 0.23.  Please hold on your commit to 0.23 for a moment.  Thanks.


Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


----- Forwarded Message -----
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Friday, February 24, 2012 4:01 PM
Subject: [RESULT][VOTE] Merging 0.23-PB to 0.23

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/

Re: [RESULT][VOTE] Merging 0.23-PB to 0.23

[Steve Loughran <st...@apache.org>]

On 25/02/12 02:01, Arun C Murthy wrote:
> Neat.
>
> Based on the previous discussion, I've created a branch-0.23.2 and set version on branch-0.23 to be 0.23.3. You are good to go there.

OK, there are also JIRA version numbers for 0.23.3; I added a couple & 
someone had already stuck one in for MAPREDUCE

Re: [RESULT][VOTE] Merging 0.23-PB to 0.23

[Steve Loughran <st...@apache.org>]

On 25/02/12 02:01, Arun C Murthy wrote:
> Neat.
>
> Based on the previous discussion, I've created a branch-0.23.2 and set version on branch-0.23 to be 0.23.3. You are good to go there.
>

to clarify this, anything I do on trunk that I want to get into the 
0.23.x release should still be on branch-0.23? The 0.23.2 is 
specifically for the followup to the 0.23.1 release that's just been 
voted through, and is locked down for all changes except by the release 
manager -you- ?

Re: [RESULT][VOTE] Merging 0.23-PB to 0.23

[Arun C Murthy <ac...@hortonworks.com>]

Neat.

Based on the previous discussion, I've created a branch-0.23.2 and set version on branch-0.23 to be 0.23.3. You are good to go there.

thanks,
Arun

On Feb 24, 2012, at 4:01 PM, Tsz Wo (Nicholas), Sze wrote:

> There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.
> 
> I will send out emails to the dev mailing lists right before the merging.
> 
> Thanks everyone!
> 
> Tsz-Wo Nicholas Sze
> Hortonworks Inc.
> http://hortonworks.com/
> 
> 
> ________________________________
> From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
> To: general hadoop <ge...@hadoop.apache.org> 
> Sent: Wednesday, February 22, 2012 4:02 PM
> Subject: [VOTE] Merging 0.23-PB to 0.23
> 
> We actually require to have a vote according to the bylaws (Thanks Aaron Myers for the kindly note.)  Please check the branch and vote.
> 
> Tsz-Wo Nicholas Sze
> Hortonworks Inc.
> http://hortonworks.com/
> 
> 
> ________________________________
> From: Mahadev Konar <ma...@hortonworks.com>
> To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com> 
> Sent: Wednesday, February 22, 2012 3:30 PM
> Subject: Re: Merging 0.23-PB to 0.23
> 
> Sounds great! +1 for merging. Would be good to get this into 0.23
> branch as soon as possible.
> 
> Mahadev Konar
> Hortonworks Inc.
> http://hortonworks.com/
> 
> 
> On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
> <s2...@yahoo.com> wrote:
>> Hi,
>> 
>> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>> 
>> Regards,
>> 
>> Tsz-Wo Nicholas Sze
>> Hortonworks Inc.
>> http://hortonworks.com/

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

[RESULT][VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

There are six +1s (Mahadev, Eli, Suresh, Arun, Jitendra and myself) and no -1s.  The vote passed.

I will send out emails to the dev mailing lists right before the merging.

Thanks everyone!

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


________________________________
From: "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>
To: general hadoop <ge...@hadoop.apache.org> 
Sent: Wednesday, February 22, 2012 4:02 PM
Subject: [VOTE] Merging 0.23-PB to 0.23

We actually require to have a vote according to the bylaws (Thanks Aaron Myers for the kindly note.)  Please check the branch and vote.

Tsz-Wo Nicholas Sze
Hortonworks Inc.
http://hortonworks.com/


________________________________
From: Mahadev Konar <ma...@hortonworks.com>
To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com> 
Sent: Wednesday, February 22, 2012 3:30 PM
Subject: Re: Merging 0.23-PB to 0.23

Sounds great! +1 for merging. Would be good to get this into 0.23
branch as soon as possible.

Mahadev Konar
Hortonworks Inc.
http://hortonworks.com/


On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi,
>
> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>
> Regards,
>
> Tsz-Wo Nicholas Sze
> Hortonworks Inc.
> http://hortonworks.com/

[VOTE] Merging 0.23-PB to 0.23

["Tsz Wo (Nicholas), Sze" <s2...@yahoo.com>]

We actually require to have a vote according to the bylaws (Thanks Aaron Myers for the kindly note.)  Please check the branch and vote.

Tsz-Wo Nicholas Sze

Hortonworks Inc.
http://hortonworks.com/


________________________________
From: Mahadev Konar <ma...@hortonworks.com>
To: general@hadoop.apache.org; "Tsz Wo (Nicholas), Sze" <s2...@yahoo.com> 
Sent: Wednesday, February 22, 2012 3:30 PM
Subject: Re: Merging 0.23-PB to 0.23

Sounds great! +1 for merging. Would be good to get this into 0.23
branch as soon as possible.

Mahadev Konar
Hortonworks Inc.
http://hortonworks.com/


On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi,
>
> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>
> Regards,
>
> Tsz-Wo Nicholas Sze
> Hortonworks Inc.
> http://hortonworks.com/

Re: Merging 0.23-PB to 0.23

[Mahadev Konar <ma...@hortonworks.com>]

Sounds great! +1 for merging. Would be good to get this into 0.23
branch as soon as possible.

Mahadev Konar
Hortonworks Inc.
http://hortonworks.com/



On Wed, Feb 22, 2012 at 12:20 PM, Tsz Wo (Nicholas), Sze
<s2...@yahoo.com> wrote:
> Hi,
>
>
> The IPC protocol buffer feature in trunk is complete.  It is time to merge 0.23-PB back to 0.23.  Lists of 0.23-PB issues which are not in 0.23 can be found in the CHANGES.txt files in the 0.23-PB branch.  I will merge it tomorrow.  Please let me know if you have any concern.
>
>
> Regards,
>
> Tsz-Wo Nicholas Sze
> Hortonworks Inc.
> http://hortonworks.com/