Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - [VOTE] Release plan for Hadoop 2.0.5

Copy link to this message
Re: [VOTE] Release plan for Hadoop 2.0.5
Arun C Murthy 2013-05-13, 20:41

On May 13, 2013, at 8:33 AM, Chris Douglas wrote:

> On Sat, May 11, 2013 at 7:03 AM, Arun C Murthy <[EMAIL PROTECTED]> wrote:
>> In the ASF, the RM *does not* have the power to choose bits and pieces of code from SVN. He can remove bits from SVN - only by veto'ing the changes. [ample quotation of Roy]
> A committer can create a branch, push changes to it, and invite others
> to work on it. He may subsequently propose the contents of that branch
> as a release, begging, convincing, etc. others in the context of a
> "release manager". Whether the branching, coding, and testing is done
> in an "RM context" doesn't seem particularly important to its
> feasibility. But your point is well taken, and it's important to
> identify this path as developers forking the branch, not an RM
> curating a release. And few would disagree: it's better for developers
> to collaborate, rather than working at cross purposes in related
> branches.

Glad we are on the same page.
> However, the course Andrew (and others) have advocated, where recently
> committed features go into a 2.1.x release series instead of 2.0.x, is
> not disallowed by any rule.

First up - agree 110%

We seem to have an outstanding ability to replay discussions every couple of months here. Pardon me as my frustration bubbles over.

I originally proposed something along the same lines in Feb 2012 i.e. 2.1.x as alpha series, 2.2.x as beta series etc.

In the long, windy discussion that (invariably) ensued it was shot down in favor of the current plan - I wasn't thrilled, but I just moved on:

I pointed this out in the other thread on *-dev@ too; this keeps getting ignored as we pass each other on the concentric circles we currently route on.

Again, I don't care whether beta is 2.1.x or 2.2.x or 2.100.x. All I care is to have a set of well-known series of releases (history shows we'll need at least two or more) to whet APIs and compatibility *before* we declare them to be done.

So, yes, I'm more than happy to re-number 2.0.5 to 2.1 or 2.100 and abandon the 2.0.x series.

However, I want to make sure it's clear to everyone that by doing so, there will be incompatibilities between 2.0.x and 2.1.x; hence 2.0.x will continue along a path where it won't be feasible to support in a stable/compatible manner for the long term i.e. continue to be called 'alpha' in terms of API/protocol compatibility - that's it.

As others (Suresh, Nic, Eli) have pointed out, declaring APIs/protocols done while we are days away from merging major features such as Snapshots is a fool's errand - we are better off taking them in. That is even more so given the importance of the feature and the number of who people stand by it, please look at the test plans (if anyone disagrees comment on the jira, not on this thread).

Todd claims HDFS-347 is stable (see recent discussion on jira), I believe him.

I know the Windows stuff is low risk - I've looked at the changes to the core of MR/YARN; they are isolated and well outside risk perimeters which concern me. Among the biggest changes was to add WindowsContainerExecutor for crying out loud - to those unfamiliar, this plugin will *not* be used in other platforms. So, yes, call me skeptical when people fret over this. I believe HDFS changes are similarly low-risk and have been already verified on branch-1/trunk - again, please, comment on jira if it concerns you.