Mailing-List: contact general-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of harsh@cloudera.com designates
 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CC5D0607.6C67%evans@yahoo-inc.com>
References: 
 <CAGiCgd0rqs3tk=AeMDq97DqxaERff9_So3GEPV5motoPPVUA7w@mail.gmail.com>
 <CC5D0607.6C67%evans@yahoo-inc.com>
From: Harsh J <harsh@cloudera.com>
Date: Fri, 24 Aug 2012 21:36:15 +0530
Message-ID: 
 <CAOcnVr0HUQiS+Pveq=kyesVPm7sTGrNLoMLsY8_0RfOB+aVXOA@mail.gmail.com>
Subject: Re: 0.23.3 release coming soon
To: general@hadoop.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi Inder,

>From what I've seen of the development activity that came out of
choosing to stabilize the early 0.23 branch, I think there is great
value in what's being done here.

Given that, I personally have nothing against them making a release;
it helps them continue on their goal, and its pretty great that they
want others to share the stable/tested release of YARN, etc., instead
of keeping things private.

We were in a version mess and have already taken steps to fix that,
and this isn't making anything worse the way I see it. Feel free to
continue recommending 2.x and 1.x numbers as thats the numbering
scheme for the future, as the fixes done on this branch do make it to
those as well (or at least trunk, from where it can be cherry-picked),
its not a divergence/fork in any way.

P.s. We've already had 0.23 releases before, and I don't think we're
'diverging' from the version naming if we release a bug fixes drop
under the same line.

On Fri, Aug 24, 2012 at 8:56 PM, Robert Evans <evans@yahoo-inc.com> wrote:
> I respect your opinion, but I personally feel that there is a lot of value
> in having a release that has been stabilized, is being maintained, and
> tested on a large scale.  Even if there is confusion about the version
> numbers.  But I will leave the final decision up to the PMC.  If they feel
> the version numbering confusion is worth the value they can vote for an
> official release.  If they do not they can vote against it.
>
> --Bobby
>
> On 8/24/12 10:16 AM, "Inder.dev Java" <java.inder@gmail.com> wrote:
>
>>>We don't have a private git repo.  That was the whole point of this so we
>>>can do all of this in public.  What we run and build is purely what is on
>>>branch-0.23.
>>
>>  True, you can do this by simply sharing the build somewhere and publish
>>the link in list.
>>  whoever wants they may try.
>>
>>  Let's please don't deviate the release numberings by keeping this
>>releases somewhere in apache release folder along with Hadoop-2 and 1.
>>
>>Already we may have to answer to the people why we skipped 22 version.
>>
>>I know many people maintain the source code by cutting some branch. I
>>don't
>>think people will ask to make release of their branches to make sure no
>>private changes ;-) . They migrate to near latest version to make sure
>>they
>>are close with community and will have tests to run on it to make sure no
>>impacts.
>>
>>-thx
>>
>>
>>On Fri, Aug 24, 2012 at 4:33 AM, Robert Evans <evans@yahoo-inc.com> wrote:
>>
>>> We don't have a private git repo.  That was the whole point of this so
>>>we
>>> can do all of this in public.  What we run and build is purely what is
>>>on
>>> branch-0.23.
>>>
>>> > Note that, end of the day, ultimately community has to mark hadoop-2
>>>as
>>> >stable. but not 23.3..versions right.
>>>
>>> The community can do what ever they want following the Hadoop Project's
>>> bylaws http://hadoop.apache.org/bylaws.html.  An official release of
>>> hadoop requires a lazy majority vote of PMC members.  Marking a release
>>>as
>>> stable is not something that is voted on according to the bylaws.  We
>>>all
>>> want hadoop-2 to become stable, but it is up to individual users if it
>>>is
>>> stable enough for them.  The fact that hadoop-2.0.0 and hadoop-2.1.0 are
>>> marked as alpha is only to warn people that the release has not really
>>> been tested at scale.  There was a lot of discussion when the alpha was
>>> added to the name if that really was necessary.  The community decided
>>> that it was helpful so that is why we did it.
>>>
>>> 0.23.3 is very close to 2.0.0-aplha but without Name Node HA, and with
>>> more bug fixes.  You are correct that even if all of the bugs in 0.23
>>>are
>>> fixed it does not guarantee that all of the bugs in 2 will be fixed
>>> because of that.  But it does guarantee that someone else will not have
>>>to
>>> fix a bug in 2 that is also in 0.23.
>>>
>>> --Bobby Evans
>>>
>>> On 8/23/12 4:52 PM, "Inder.dev Java" <java.inder@gmail.com> wrote:
>>>
>>> >> We also wanted to do this out in the open so the community
>>> >could see what was happening, instead of in some private git
>>>repository.
>>> >
>>> >You mean, you have some different changes in 23.3,  which is not put
>>>into
>>> >hadoop-2 ?
>>> >
>>> >
>>> >alpha cuts already going on and ppl are testing. If you find any bug in
>>> >23.3, you may contribute to hadoop-2.
>>> >That changes will be tested in next alpha cut right. If you test with
>>>23.3
>>> >and say it is stable with out merging some things from hadoop-2, that
>>>will
>>> >not really give confidence on hadoop-2 releases right. If you are
>>>porting
>>> >everything from hadoop-2 to 23.3, then both releases are same. Need not
>>> >release it separately right? But I am not sure about it.
>>> >
>>> >IMO, having official releases like this may confuse ppl differently.
>>> >
>>> >-thx
>>> >
>>> >
>>> >On Fri, Aug 24, 2012 at 3:04 AM, Robert Evans <evans@yahoo-inc.com>
>>> wrote:
>>> >
>>> >> There was a discussion about this in April
>>> >>
>>> >>
>>> >>
>>>
>>>http://mail-archives.apache.org/mod_mbox/hadoop-general/201204.mbox/%3CCB
>>> >>9F
>>> >> 2CBB.37CD3%25evans@yahoo-inc.com%3E
>>> >>
>>> >> in which there was unanimous approval of the idea.  I realize that
>>>it is
>>> >> confusing and I feel your pain.  I hate having to explain to our
>>> >>customers
>>> >> why we are going "backwards" from 1.0 to 0.23.
>>> >>
>>> >> The community as a whole is working hard and is serious about
>>> >>stabilizing
>>> >> hadoop-2.  As I said in the original proposal everything that is in
>>> >>0.23.3
>>> >> has been merged first to branch-2.
>>> >>
>>> >> What is more, putting on my Yahoo hat, we have nightly builds and
>>>tests
>>> >>of
>>> >> branch-2.  We want to move to branch-2 as soon as possible, but to
>>>meet
>>> >> our goals to have YARN out in production by the end of this year we
>>>had
>>> >>to
>>> >> cut somewhere.  We also wanted to do this out in the open so the
>>> >>community
>>> >> could see what was happening, instead of in some private git
>>>repository.
>>> >>
>>> >> If the community has changed their mind and having an official
>>>release
>>> >> labeled 0.23 is too confusing to customers I am happy to not call a
>>> >>vote,
>>> >> but simply renumber the release and move on.
>>> >>
>>> >> --Bobby Evans
>>> >>
>>> >> On 8/23/12 4:09 PM, "Inder.dev Java" <java.inder@gmail.com> wrote:
>>> >>
>>> >> >Having releases like this kind of versions (back to 2x.x..) may
>>>confuse
>>> >> >people?
>>> >> >Hadoop-2 and 23.x may not have big difference right.
>>> >> >
>>> >> >already community decided to make the branches as 1, 2....etc.. So
>>> >>again
>>> >> >going back to 2x.x releases may really confuse people. I confused by
>>> >> >seeing
>>> >> >this release mail here.
>>> >> >
>>> >> >Why can't people put real effort on hadoop-2 itself and make it
>>>stable
>>> >>as
>>> >> >that is the version community wanted to make it stable from alpha?
>>>Why
>>> >> >this
>>> >> >effort split here.
>>> >> >
>>> >> >-thx
>>> >> >
>>> >> >On Fri, Aug 24, 2012 at 2:22 AM, Robert Evans <evans@yahoo-inc.com>
>>> >> wrote:
>>> >> >>
>>> >> >>
>>> >> >> I am planning to do cut a release candidate of 0.23.3 in the next
>>> >>week
>>> >> >>or
>>> >> >> so.  I am waiting for a few more JIRAs to go in (MAPREDUCE-3943
>>>and
>>> >> >> HDFS-3177), and a bit more testing before I call a vote.  I know
>>>not
>>> >>too
>>> >> >> many people have been putting things into branch-0.23 directly,
>>>but
>>> >>if
>>> >> >>you
>>> >> >> do want to please check with me first. After I cut the release I
>>>will
>>> >> >>open
>>> >> >> the branch up again for more bug fixes for a 23.4 release.  I
>>>expect
>>> >> >>0.23.4
>>> >> >> to come about a month after 0.23.3. This is to incorporate any bug
>>> >>fixes
>>> >> >> needed as Yahoo! and hopefully others do more testing on 0.23.3
>>>and
>>> >> >>start
>>> >> >> rolling it out to more clusters.
>>> >> >>
>>> >> >> --Bobby Evans
>>> >> >>
>>> >>
>>> >>
>>>
>>>
>


-- 
Harsh J