Thanks for reviving this thread.
The current blockers are:
By looking at them I don't see they are necessary blockers for a beta
* HADOOP-9688 & HADOOP-9698
They definitely have to be addressed before a GA
It should be addressed before a GA release.
Still, as it is this breaks unmanaged AMs and to me
that would be a blocker for the beta.
YARN-701 and the unmanaged AMs fix should be committed
It is a consequence of YARN-701 and depends on it.
It would be nice to have it addressed before GA release.
We could do a beta with what we have at the moment in branch-2 and have a
special release note indicating API changes coming in the next beta/GA
release as part of YARN-918 & YARN-926.
IMO, we should move forward with the beta release with the current state.
Else we'll continue delaying it and adding more things that break/change
On Wed, Jul 17, 2013 at 12:24 PM, Vinod Kumar Vavilapalli <
[EMAIL PROTECTED]> wrote:
> Looks like this RC has gone stale and lots of bug fixes went into 2.1 and
> 2.1.0 branches and there are 4-5 outstanding blockers. And from what I see
> in CHANGES.txt files there seems to be a confusion about which branch to
> get in what.
> I'm blowing off the current 2.1.0 release branch so that we can create a
> fresh release branch and call voting on that. I'll fix CHANGES.txt entries
> as well as JIRA fix version for bugs committed recently if there are
> Let me know if something is amiss while I do this.
> On Jul 3, 2013, at 11:06 AM, Vinod Kumar Vavilapalli wrote:
> > We should get these in, looking at them now.
> > Thanks,
> > +Vinod
> > On Jun 28, 2013, at 12:03 PM, Hitesh Shah wrote:
> >> Hi Arun,
> >> From a YARN perspective, YARN-791 and YARN-727 are 2 jiras that may
> potentially change the apis. They can implemented in a backward compat
> fashion if committed after 2.1.0. However, this will require adding of
> differently-named apis ( different urls in case of the webservices ) and
> make the current version of the api deprecated and/or obsolete. YARN-818
> which is currently patch available also changes behavior.
> >> Assuming that as soon as 2.1.0 is released, we are to follow a very
> strict backward-compat retaining approach to all user-facing layers (
> api/webservices/rpc/... ) in common/hdfs/yarn/mapreduce, does it make sense
> to try and pull them in and roll out a new RC after they are ready? Perhaps
> Vinod can chime in if he is aware of any other such jiras under YARN-386
> which should be considered compat-related blockers for a 2.1.0 RC.
> >> thanks
> >> -- Hitesh
> >> On Jun 26, 2013, at 1:17 AM, Arun C Murthy wrote:
> >>> Folks,
> >>> I've created a release candidate (rc0) for hadoop-2.1.0-beta that I
> would like to get released.
> >>> This release represents a *huge* amount of work done by the community
> (639 fixes) which includes several major advances including:
> >>> # HDFS Snapshots
> >>> # Windows support
> >>> # YARN API stabilization
> >>> # MapReduce Binary Compatibility with hadoop-1.x
> >>> # Substantial amount of integration testing with rest of projects in
> the ecosystem
> >>> The RC is available at:
> >>> The RC tag in svn is here:
> >>> The maven artifacts are available via repository.apache.org.
> >>> Please try the release and vote; the vote will run for the usual 7
> >>> thanks,
> >>> Arun
> >>> --
> >>> Arun C. Murthy