hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arun C Murthy <...@hortonworks.com>
Subject Re: [VOTE] Release plan for Hadoop 2.0.5
Date Mon, 13 May 2013 20:41:36 GMT

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

> On Sat, May 11, 2013 at 7:03 AM, Arun C Murthy <acm@hortonworks.com> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message