FAQ
I'll do the needful after midnight tonight. It should take less than half-an-hour, and I'll send out the all clear after.

thanks,
Arun

Begin forwarded message:
From: Arun C Murthy <acm@hortonworks.com>
Date: March 26, 2012 7:31:21 PM PDT
To: general@hadoop.apache.org
Subject: [RESULT] - [VOTE] Rename hadoop branches post hadoop-1.x

Thanks to all who voted.

Here are the counts:
# Community (62 votes): {1 -> 14, 2 -> 4, 3 -> 38, 4 -> 5, 5 -> 1}
# Binding (22 votes): {1 -> 2, 2 -> 1, 3 -> 15, 4 -> 4, 5 -> 0}

As a result, we seem to converge on option #3 with 15/22 binding votes (38/62 overall).

thanks,
Arun
On Mar 19, 2012, at 6:06 PM, Arun C Murthy wrote:

We've discussed several options:

(1) Rename branch-0.22 to branch-2, rename branch-0.23 to branch-3.
(2) Rename branch-0.23 to branch-3, keep branch-0.22 as-is i.e. leave a hole.
(3) Rename branch-0.23 to branch-2, keep branch-0.22 as-is.
(4) If security is fixed in branch-0.22 within a short time-frame i.e. 2 months then we get option 1, else we get option 3. Effectively postpone discussion by 2 months, start a timer now.
(5) Do nothing, keep branch-0.22 and branch-0.23 as-is.

Let's do a STV [1] to get reach consensus.

Please vote by listing the options above in order of your preferences.

My vote is 3, 4, 2, 1, 5 in order (binding).

The vote will run the normal 7 days.

thanks,
Arun

[1] http://en.wikipedia.org/wiki/Single_transferable_vote
--
Arun C. Murthy
Hortonworks Inc.
http://hortonworks.com/

Search Discussions

  • Arun C Murthy at Mar 28, 2012 at 7:28 am

    On Mar 27, 2012, at 10:31 PM, Arun C Murthy wrote:

    I'll do the needful after midnight tonight. It should take less than half-an-hour, and I'll send out the all clear after.
    Done, all clear; I've also created jira revisions. Please let me know if you find any issues.

    thanks,
    Arun

    --
    Arun C. Murthy
    Hortonworks Inc.
    http://hortonworks.com/
  • Aaron T. Myers at Mar 28, 2012 at 7:49 am
    Hey Arun,
    On Wed, Mar 28, 2012 at 12:28 AM, Arun C Murthy wrote:

    Done, all clear; I've also created jira revisions. Please let me know if
    you find any issues.
    Thanks a lot for making these changes. Two questions:

    - Now that we've renamed branch-0.23 to branch-2, and since there is as yet
    no branch-0.23.3, what should be done with JIRAs marked with the 0.23.3
    version? Perhaps all of these should be updated to 2.0.0?

    - We still have the JIRA version 0.24.0, which is presumably still
    representative of trunk. Given that we will likely never release an 0.24.0,
    should we rename this version in JIRA as well?

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Arun C Murthy at Mar 28, 2012 at 8:04 am

    On Mar 28, 2012, at 12:48 AM, Aaron T. Myers wrote:

    Hey Arun,
    On Wed, Mar 28, 2012 at 12:28 AM, Arun C Murthy wrote:

    Done, all clear; I've also created jira revisions. Please let me know if
    you find any issues.
    Thanks a lot for making these changes. Two questions:

    - Now that we've renamed branch-0.23 to branch-2, and since there is as yet
    no branch-0.23.3, what should be done with JIRAs marked with the 0.23.3
    version? Perhaps all of these should be updated to 2.0.0?
    Yep, in the process of doing it.
    - We still have the JIRA version 0.24.0, which is presumably still
    representative of trunk. Given that we will likely never release an 0.24.0,
    should we rename this version in JIRA as well?
    I've created a 3.0.0 version in jira too. I'll update all jiras to point to that instead of 0.24.0.

    thanks,
    Arun

    --
    Arun C. Murthy
    Hortonworks Inc.
    http://hortonworks.com/
  • Todd Lipcon at Mar 28, 2012 at 6:54 pm

    On Wed, Mar 28, 2012 at 1:03 AM, Arun C Murthy wrote:
    On Mar 28, 2012, at 12:48 AM, Aaron T. Myers wrote:

    Hey Arun,
    On Wed, Mar 28, 2012 at 12:28 AM, Arun C Murthy wrote:

    Done, all clear; I've also created jira revisions. Please let me know if
    you find any issues.
    Thanks a lot for making these changes. Two questions:

    - Now that we've renamed branch-0.23 to branch-2, and since there is as yet
    no branch-0.23.3, what should be done with JIRAs marked with the 0.23.3
    version? Perhaps all of these should be updated to 2.0.0?
    Yep, in the process of doing it.
    - We still have the JIRA version 0.24.0, which is presumably still
    representative of trunk. Given that we will likely never release an 0.24.0,
    should we rename this version in JIRA as well?
    I've created a 3.0.0 version in jira too. I'll update all jiras to point to that instead of 0.24.0.
    Is trunk/24 definitely 3.0.0? Given that we don't have any major new
    features targeted at it (but not targeted at 2.x) yet, I've been
    thinking of it more like 2.1. I also think, given we have PB in place
    in both branches, it's likely we can maintain client compatibility
    between 23 and 24 in the absence of anything major coming down the
    pipe.

    Proposal: is it possible to call the JIRA fixVersion "trunk", and then
    when we branch off trunk to make a release, rename it at that point to
    "2.1" or "3.0" or whatever it gets called?

    Todd
    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Aaron T. Myers at Mar 28, 2012 at 7:00 pm

    On Wed, Mar 28, 2012 at 11:53 AM, Todd Lipcon wrote:

    Proposal: is it possible to call the JIRA fixVersion "trunk", and then
    when we branch off trunk to make a release, rename it at that point to
    "2.1" or "3.0" or whatever it gets called?
    I like this idea. Just to be clear, I think the exact workflow would be:

    1. Set the version fields to "trunk" if you're not committing the JIRA to
    any current versioned branch.
    2. When a new release branch is made off of trunk, rename the "trunk" JIRA
    version to whatever the appropriate version number is.
    3. At the same time as (2), create a new JIRA version also called "trunk".
    4. Go to 1.

    Is this what you were thinking, Todd?

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Todd Lipcon at Mar 28, 2012 at 7:03 pm

    On Wed, Mar 28, 2012 at 11:59 AM, Aaron T. Myers wrote:
    On Wed, Mar 28, 2012 at 11:53 AM, Todd Lipcon wrote:

    Proposal: is it possible to call the JIRA fixVersion "trunk", and then
    when we branch off trunk to make a release, rename it at that point to
    "2.1" or "3.0" or whatever it gets called?
    I like this idea. Just to be clear, I think the exact workflow would be:

    1. Set the version fields to "trunk" if you're not committing the JIRA to
    any current versioned branch.
    2. When a new release branch is made off of trunk, rename the "trunk" JIRA
    version to whatever the appropriate version number is.
    3. At the same time as (2), create a new JIRA version also called "trunk".
    4. Go to 1.

    Is this what you were thinking, Todd?
    Yep, that's right.

    -Todd
    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Owen O'Malley at Mar 28, 2012 at 7:25 pm
    I disagree. Trunk should become branch-3 once someone wants to start
    stabilizing it. Arun is going to need the minor versions for when he adds
    features.

    X.Y.Z

    Z = bug fixes
    Y = minor release (compatible, adds features)
    X = major release (incompatible)

    So from branch-2 will come branch-2.0 with tags for 2.0.0, 2.0.1. New
    features will go into branch-2, which will become branch-2.1, branch-2.2,
    and so on.

    -- Owen
  • Todd Lipcon at Mar 28, 2012 at 7:33 pm

    On Wed, Mar 28, 2012 at 12:25 PM, Owen O'Malley wrote:
    I disagree. Trunk should become branch-3 once someone wants to start
    stabilizing it. Arun is going to need the minor versions for when he adds
    features.

    X.Y.Z

    Z = bug fixes
    Y = minor release (compatible, adds features)
    X = major release (incompatible)
    I agree with this classification.
    So from branch-2 will come branch-2.0 with tags for 2.0.0, 2.0.1. New
    features will go into branch-2, which will become branch-2.1, branch-2.2,
    and so on.
    But new features also go to trunk. And if none of our new features are
    incompatible, why do we anticipate that trunk is 3.0?

    Basically trunk is almost identical to branch-2 right now... I guess
    my proposal is basically to not bother having a trunk separate from a
    branch-2, and use a branch-2.0 for continued stabilization of what we
    currently call branch-23. When someone has something incompatible to
    propose, then we can bother splitting it off..

    Todd
    --
    Todd Lipcon
    Software Engineer, Cloudera
  • Owen O'Malley at Mar 28, 2012 at 7:39 pm
    On Wed, Mar 28, 2012 at 12:32 PM, Todd Lipcon wrote:

    But new features also go to trunk. And if none of our new features are
    incompatible, why do we anticipate that trunk is 3.0?
    Let's imagine that we already had a 2.0.0 release. Now we want to add
    features like HA. The only place to put that is in 2.1.0. On the other
    hand, you don't want to pull *ALL* of the changes from trunk. That is way
    too much scope. So the RM of the 2 branch needs to make the call of what
    should be 2.1 vs 3.0.

    -- Owen
  • Aaron T. Myers at Mar 28, 2012 at 11:12 pm
    Hi Owen,
    On Wed, Mar 28, 2012 at 12:39 PM, Owen O'Malley wrote:

    Let's imagine that we already had a 2.0.0 release. Now we want to add
    features like HA. The only place to put that is in 2.1.0. On the other
    hand, you don't want to pull *ALL* of the changes from trunk. That is way
    too much scope. So the RM of the 2 branch needs to make the call of what
    should be 2.1 vs 3.0.
    I don't think anyone disagrees with this line of reasoning. It's certainly
    up to the RM what gets included in branch-2 and hence what gets put up for
    release votes under the "2.y.z" version numbers. I don't think Todd was
    suggesting we rename the JIRA version "0.24.0" to "2.1.0".

    But, the question still remains of how to refer to the branch "trunk" in
    JIRA. I don't think it should be called 3.0.0, as that's not necessarily
    the next release that will come off of it, and using a version number for
    trunk that changes from time to time has other downsides as I described in
    my response to Arun. Given this, do you object to renaming the JIRA fix
    version that refers to the branch trunk to "trunk" ?

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Doug Cutting at Mar 29, 2012 at 12:11 am

    On 03/28/2012 12:39 PM, Owen O'Malley wrote:
    [ ... ] So the RM of the 2 branch needs to make the call of what
    should be 2.1 vs 3.0.
    I thought these were community decisions, not RM decisions, no?

    http://s.apache.org/rm

    Doug
  • Owen O'Malley at Mar 29, 2012 at 3:00 pm

    On Wed, Mar 28, 2012 at 5:11 PM, Doug Cutting wrote:
    On 03/28/2012 12:39 PM, Owen O'Malley wrote:
    [ ... ] So the RM of the 2 branch needs to make the call of what
    should be 2.1 vs 3.0.
    I thought these were community decisions, not RM decisions, no?
    What to release is the RM's decision and then voted on by the community.
    We tried voting on which features to include and it led to no releases for
    two years. I think our users are better served by having good usable
    releases.

    -- Owen
  • Eli Collins at Mar 29, 2012 at 3:07 pm

    On Thu, Mar 29, 2012 at 8:00 AM, Owen O'Malley wrote:
    On Wed, Mar 28, 2012 at 5:11 PM, Doug Cutting wrote:
    On 03/28/2012 12:39 PM, Owen O'Malley wrote:
    [ ... ] So the RM of the 2 branch needs to make the call of what
    should be 2.1 vs 3.0.
    I thought these were community decisions, not RM decisions, no?
    What to release is the RM's decision and then voted on by the community.
    We tried voting on which features to include and it led to no releases for
    two years. I think our users are better served by having good usable
    releases.
    Roy was pointing out that there is an RM for a given release, but
    there is not a RM for a branch. The RM does not decide what goes into
    branch-2, that's happening on a patch by patch basis, and the RM
    decides what to release based on what branch they pick and what they
    merge to it. So far it has been working well. Kudos to Arun.

    Thanks,
    Eli
  • Arun C Murthy at Mar 28, 2012 at 8:57 pm

    On Mar 28, 2012, at 12:32 PM, Todd Lipcon wrote:

    But new features also go to trunk. And if none of our new features are
    incompatible, why do we anticipate that trunk is 3.0?

    Essentially 'trunk' is where incompatible changes *may* be committed (in future). We should allow for that.

    I'm ambivalent about the 'version string' for trunk being either trunk-SNAPSHOT or 3.0.0-SNAPSHOT.

    On on hand, we've historically bumped the version number for trunk (i.e. 3.0.0-SNAPSHOT). This has the nice property that when we do cut a release branch off trunk we don't have to scramble to change fix-versions on all the jiras committed to trunk from 'trunk' to X.0.0. Since I've done my fair share of jira manipulation for releases as the RM, as recently as last night, it's nice to not force the burden on the RM for branch-3.

    OTOH, having a constant trunk-SNAPSHOT version string helps devs working on trunk since they don't have to deal with version bumps on trunk (albeit, once in a while). (Credit to Scott Carey for this idea.)

    Given the above I'd stick with 3.0.0 since it means lesser confusion and lesser work for the RM on future major releases.

    On a related note: as I noted last night, I'd again urge committers to not set the 'fix-version' to trunk's version if it's committed to other branches (branch-1, branch-2 etc.)

    thanks,
    Arun

    --
    Arun C. Murthy
    Hortonworks Inc.
    http://hortonworks.com/
  • Aaron T. Myers at Mar 28, 2012 at 9:15 pm

    On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy wrote:

    On on hand, we've historically bumped the version number for trunk (i.e.
    3.0.0-SNAPSHOT). This has the nice property that when we do cut a release
    branch off trunk we don't have to scramble to change fix-versions on all
    the jiras committed to trunk from 'trunk' to X.0.0. Since I've done my fair
    share of jira manipulation for releases as the RM, as recently as last
    night, it's nice to not force the burden on the RM for branch-3.
    I don't think you'd have to change all the JIRAs. You'd just have to change
    the name of the "trunk" JIRA version to whatever the right number is, and
    then create a new version in JIRA also named "trunk." This would serve the
    same purpose, without having to update any individual JIRAs.

    OTOH, having a constant trunk-SNAPSHOT version string helps devs working
    on trunk since they don't have to deal with version bumps on trunk (albeit,
    once in a while). (Credit to Scott Carey for this idea.)
    This is a nice benefit of Todd's (and Scott's?) proposal. Whenever we do
    change the trunk version number, I have to update a bunch of scripts,
    environment files, and configuration XML files. Not the end of the world,
    but annoying nonetheless.

    I'd also add to this benefit that users who are new to the project will
    more easily be able to determine what version to put for a JIRA they want
    to get committed to trunk. I've seen plenty of users who are confused by
    having to set "0.24.0" as the version indicating trunk.

    There's also a nice symmetry in having the branch in svn/git (named trunk)
    have the same name as the JIRA version indicator.

    Given the above I'd stick with 3.0.0 since it means lesser confusion and
    lesser work for the RM on future major releases.
    I honestly believe that this scheme is more confusing for devs and users,
    and almost no different for RMs given what I described above with JIRA
    version renaming. But, I don't feel super strongly about it. If this makes
    sense to you, then I'll stop pushing.

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Arun C Murthy at Mar 28, 2012 at 11:00 pm

    On Mar 28, 2012, at 2:14 PM, Aaron T. Myers wrote:
    On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy wrote:

    On on hand, we've historically bumped the version number for trunk (i.e.
    3.0.0-SNAPSHOT). This has the nice property that when we do cut a release
    branch off trunk we don't have to scramble to change fix-versions on all
    the jiras committed to trunk from 'trunk' to X.0.0. Since I've done my fair
    share of jira manipulation for releases as the RM, as recently as last
    night, it's nice to not force the burden on the RM for branch-3.
    I don't think you'd have to change all the JIRAs. You'd just have to change
    the name of the "trunk" JIRA version to whatever the right number is, and
    then create a new version in JIRA also named "trunk." This would serve the
    same purpose, without having to update any individual JIRAs.

    Ah, I didn't know that, thanks for the tip. That alleviates my concerns.

    Arun

    --
    Arun C. Murthy
    Hortonworks Inc.
    http://hortonworks.com/
  • Scott Carey at Mar 29, 2012 at 7:46 pm

    On 3/28/12 2:14 PM, "Aaron T. Myers" wrote:
    On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy wrote:

    On on hand, we've historically bumped the version number for trunk (i.e.
    3.0.0-SNAPSHOT). This has the nice property that when we do cut a
    release
    branch off trunk we don't have to scramble to change fix-versions on all
    the jiras committed to trunk from 'trunk' to X.0.0. Since I've done my
    fair
    share of jira manipulation for releases as the RM, as recently as last
    night, it's nice to not force the burden on the RM for branch-3.
    I don't think you'd have to change all the JIRAs. You'd just have to
    change
    the name of the "trunk" JIRA version to whatever the right number is, and
    then create a new version in JIRA also named "trunk." This would serve the
    same purpose, without having to update any individual JIRAs.

    OTOH, having a constant trunk-SNAPSHOT version string helps devs working
    on trunk since they don't have to deal with version bumps on trunk
    (albeit,
    once in a while). (Credit to Scott Carey for this idea.)
    This is a nice benefit of Todd's (and Scott's?) proposal. Whenever we do
    change the trunk version number, I have to update a bunch of scripts,
    environment files, and configuration XML files. Not the end of the world,
    but annoying nonetheless.

    I'd also add to this benefit that users who are new to the project will
    more easily be able to determine what version to put for a JIRA they want
    to get committed to trunk. I've seen plenty of users who are confused by
    having to set "0.24.0" as the version indicating trunk.

    There's also a nice symmetry in having the branch in svn/git (named trunk)
    have the same name as the JIRA version indicator.
    My proposal was from a few months back related to the naming of versions
    in maven.
    It boils down to 'laziness is a virtue' + 'the maven version should match
    the branch'.
    Pick a name for a branch when you actually branch, not months before.
    'trunk' in svn == 'trunk-SNAPSHOT' in maven == 'trunk' in JIRA.

    The creation of a branch should avoid impacting the place branched from
    (i.e. cause work for people on trunk because of a branch, or cause work
    for a branch due to a tag, etc).
    If the version in 'branch/2.0.x' has maven version '2.0.x-SNAPSHOT' and
    JIRA tag '2.0.0' then tagging 2.0.0 has the following steps:

    $> svn cp branch/2.0.x tags/2.0.0
    $> cd tags/2.0.0
    $> mvn versoins:set -DnewVersion=2.0.0
    $> svn diff (spot check pom changes that versions:set did)
    $> mvn versions:commit
    $> svn commit

    The result is a new tag with the version set, and no changes to the branch
    that was tagged from.
    When the decision is made to have a 2.0.1, a jira tag can be made (or a
    2.0.x tag renamed to 2.0.1, and a new 2.0.x tag made as Todd suggests).
    Being lazy here helps because maybe instead after some development on the
    2.0.x branch it is decided to branch 2.1.x from it.

    When the decision to branch 2.1 occurs, a new branch 'branch/2.1.x' is
    made in svn, its version becomes '2.1.x-SNAPSHOT' and a JIRA tag for
    '2.1.x' is made or renamed from an old one. The old 2.0.x branch is
    unchanged (and available for more minor bugfix releases).

    Once trunk or a branch is set up for build scripts or hudson, etc, it
    works without modification no matter how many times a branch or tag occurs
    off of it.

    Given the above I'd stick with 3.0.0 since it means lesser confusion and
    lesser work for the RM on future major releases.
    I honestly believe that this scheme is more confusing for devs and users,
    and almost no different for RMs given what I described above with JIRA
    version renaming. But, I don't feel super strongly about it. If this makes
    sense to you, then I'll stop pushing.

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Aaron T. Myers at Mar 29, 2012 at 10:07 pm
    Thanks a lot, Scott, for bringing the discussion back to what to call
    "trunk" in JIRA and elsewhere. The proposal you describe to me makes a lot
    of sense.

    Owen, does this (and the JIRA proposal) make sense to you?

    --
    Aaron T. Myers
    Software Engineer, Cloudera


    On Thu, Mar 29, 2012 at 12:45 PM, Scott Carey wrote:


    On 3/28/12 2:14 PM, "Aaron T. Myers" wrote:

    On Wed, Mar 28, 2012 at 1:57 PM, Arun C Murthy <acm@hortonworks.com>
    wrote:
    On on hand, we've historically bumped the version number for trunk (i.e.
    3.0.0-SNAPSHOT). This has the nice property that when we do cut a
    release
    branch off trunk we don't have to scramble to change fix-versions on all
    the jiras committed to trunk from 'trunk' to X.0.0. Since I've done my
    fair
    share of jira manipulation for releases as the RM, as recently as last
    night, it's nice to not force the burden on the RM for branch-3.
    I don't think you'd have to change all the JIRAs. You'd just have to
    change
    the name of the "trunk" JIRA version to whatever the right number is, and
    then create a new version in JIRA also named "trunk." This would serve the
    same purpose, without having to update any individual JIRAs.

    OTOH, having a constant trunk-SNAPSHOT version string helps devs working
    on trunk since they don't have to deal with version bumps on trunk
    (albeit,
    once in a while). (Credit to Scott Carey for this idea.)
    This is a nice benefit of Todd's (and Scott's?) proposal. Whenever we do
    change the trunk version number, I have to update a bunch of scripts,
    environment files, and configuration XML files. Not the end of the world,
    but annoying nonetheless.

    I'd also add to this benefit that users who are new to the project will
    more easily be able to determine what version to put for a JIRA they want
    to get committed to trunk. I've seen plenty of users who are confused by
    having to set "0.24.0" as the version indicating trunk.

    There's also a nice symmetry in having the branch in svn/git (named trunk)
    have the same name as the JIRA version indicator.
    My proposal was from a few months back related to the naming of versions
    in maven.
    It boils down to 'laziness is a virtue' + 'the maven version should match
    the branch'.
    Pick a name for a branch when you actually branch, not months before.
    'trunk' in svn == 'trunk-SNAPSHOT' in maven == 'trunk' in JIRA.

    The creation of a branch should avoid impacting the place branched from
    (i.e. cause work for people on trunk because of a branch, or cause work
    for a branch due to a tag, etc).
    If the version in 'branch/2.0.x' has maven version '2.0.x-SNAPSHOT' and
    JIRA tag '2.0.0' then tagging 2.0.0 has the following steps:

    $> svn cp branch/2.0.x tags/2.0.0
    $> cd tags/2.0.0
    $> mvn versoins:set -DnewVersion=2.0.0
    $> svn diff (spot check pom changes that versions:set did)
    $> mvn versions:commit
    $> svn commit

    The result is a new tag with the version set, and no changes to the branch
    that was tagged from.
    When the decision is made to have a 2.0.1, a jira tag can be made (or a
    2.0.x tag renamed to 2.0.1, and a new 2.0.x tag made as Todd suggests).
    Being lazy here helps because maybe instead after some development on the
    2.0.x branch it is decided to branch 2.1.x from it.

    When the decision to branch 2.1 occurs, a new branch 'branch/2.1.x' is
    made in svn, its version becomes '2.1.x-SNAPSHOT' and a JIRA tag for
    '2.1.x' is made or renamed from an old one. The old 2.0.x branch is
    unchanged (and available for more minor bugfix releases).

    Once trunk or a branch is set up for build scripts or hudson, etc, it
    works without modification no matter how many times a branch or tag occurs
    off of it.

    Given the above I'd stick with 3.0.0 since it means lesser confusion and
    lesser work for the RM on future major releases.
    I honestly believe that this scheme is more confusing for devs and users,
    and almost no different for RMs given what I described above with JIRA
    version renaming. But, I don't feel super strongly about it. If this makes
    sense to you, then I'll stop pushing.

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Milind Bhandarkar at Apr 3, 2012 at 6:28 pm
    Arun,

    I am even more confused now than I was before:

    Here you say:

    Essentially 'trunk' is where incompatible changes *may* be committed (in
    future). We should allow for that.
    On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
    We do expect 'new features' to make it to trunk before we can commit to
    either branch-1 or branch-2.

    Which one is it ?

    Do you expect that "new features" will always remain compatible ?

    - Milind

    ---
    Milind Bhandarkar
    Greenplum Labs, EMC
    (Disclaimer: Opinions expressed in this email are those of the author, and
    do not necessarily represent the views of any organization, past or
    present, the author might be affiliated with.)
  • Aaron T. Myers at Apr 3, 2012 at 8:59 pm
    Hi Milind,
    On Tue, Apr 3, 2012 at 11:27 AM, wrote:

    Here you say:

    Essentially 'trunk' is where incompatible changes *may* be committed (in
    future). We should allow for that.
    What I believe Arun is alluding to here is that we expect for compatibility
    to be maintained for the lifetime of a major release branch.

    On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
    We do expect 'new features' to make it to trunk before we can commit to
    either branch-1 or branch-2.

    Which one is it ?
    These two statements aren't mutually exclusive. We require that all new
    features go to trunk first so as to ensure that future releases are
    supersets of the functionality of previous releases, except in the case of
    explicit deprecation. Only once it's committed to trunk may it be
    back-ported to an earlier branch.

    Do you expect that "new features" will always remain compatible ?
    Not necessarily, but only if a feature is compatible may it be back-ported
    to major release branches.

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Milind Bhandarkar at Apr 3, 2012 at 9:38 pm
    Thanks ATM.

    I guess the "*may*" emphasis confused me.

    Just to get some more clarity:

    What would be guideline for a new feature, such as
    https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
    compatibility for 1.x, but is not relevant to trunk, because the codebases
    have completely diverged, so cannot be committed to trunk ?

    - Milind

    ---
    Milind Bhandarkar
    Greenplum Labs, EMC
    (Disclaimer: Opinions expressed in this email are those of the author, and
    do not necessarily represent the views of any organization, past or
    present, the author might be affiliated with.)

    On 4/3/12 1:58 PM, "Aaron T. Myers" wrote:

    Hi Milind,
    On Tue, Apr 3, 2012 at 11:27 AM, wrote:

    Here you say:

    Essentially 'trunk' is where incompatible changes *may* be committed (in
    future). We should allow for that.
    What I believe Arun is alluding to here is that we expect for
    compatibility
    to be maintained for the lifetime of a major release branch.

    On another thread, responding to Avner (re: MAPREDUCE-4049?) you say,
    We do expect 'new features' to make it to trunk before we can commit to
    either branch-1 or branch-2.

    Which one is it ?
    These two statements aren't mutually exclusive. We require that all new
    features go to trunk first so as to ensure that future releases are
    supersets of the functionality of previous releases, except in the case of
    explicit deprecation. Only once it's committed to trunk may it be
    back-ported to an earlier branch.

    Do you expect that "new features" will always remain compatible ?
    Not necessarily, but only if a feature is compatible may it be back-ported
    to major release branches.

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Aaron T. Myers at Apr 3, 2012 at 9:45 pm

    On Tue, Apr 3, 2012 at 2:37 PM, wrote:

    What would be guideline for a new feature, such as
    https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
    compatibility for 1.x, but is not relevant to trunk, because the codebases
    have completely diverged, so cannot be committed to trunk ?
    Are you sure this isn't relevant to trunk? The "target versions" field of
    that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
    that JIRA, the author appears to intend to do this work for both trunk and
    1.0:

    "I want to have the described plugin-ability (desired with same interface)
    for all future versions of Hadoop (as mentioned in the Target Version/s
    field). <snip> On the first phase, I am focusing on the existing 1.0 branch
    as I know it. In parallel, I'll try to learn what exists in 0.23"

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Milind Bhandarkar at Apr 3, 2012 at 10:16 pm
    To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
    it is used only by mapreduce framework.

    That's why Avner says : "In parallel, I'll try to *learn what exists* in
    0.23". (Emphasize my own.)

    That's why I was wondering about the insistence of committing to trunk
    first.

    - Milind

    ---
    Milind Bhandarkar
    Greenplum Labs, EMC
    (Disclaimer: Opinions expressed in this email are those of the author, and
    do not necessarily represent the views of any organization, past or
    present, the author might be affiliated with.)


    On 4/3/12 2:44 PM, "Aaron T. Myers" wrote:
    On Tue, Apr 3, 2012 at 2:37 PM, wrote:

    What would be guideline for a new feature, such as
    https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
    compatibility for 1.x, but is not relevant to trunk, because the
    codebases
    have completely diverged, so cannot be committed to trunk ?
    Are you sure this isn't relevant to trunk? The "target versions" field of
    that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
    that JIRA, the author appears to intend to do this work for both trunk and
    1.0:

    "I want to have the described plugin-ability (desired with same interface)
    for all future versions of Hadoop (as mentioned in the Target Version/s
    field). <snip> On the first phase, I am focusing on the existing 1.0
    branch
    as I know it. In parallel, I'll try to learn what exists in 0.23"

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Aaron T. Myers at Apr 3, 2012 at 10:22 pm
    If that's the case then there doesn't seem to be any question here. The
    feature is in trunk, and an implementation could be done for an older
    release branch that would be compatible with that branch. Sure, the code to
    implement the feature is quite different between the two branches, but
    trunk will remain a superset of the functionality of the past release, so
    no issue.

    --
    Aaron T. Myers
    Software Engineer, Cloudera


    On Tue, Apr 3, 2012 at 3:14 PM, wrote:

    To my knowledge, shuffle is already pluggable in 0.23 onwards, as long as
    it is used only by mapreduce framework.

    That's why Avner says : "In parallel, I'll try to *learn what exists* in
    0.23". (Emphasize my own.)

    That's why I was wondering about the insistence of committing to trunk
    first.

    - Milind

    ---
    Milind Bhandarkar
    Greenplum Labs, EMC
    (Disclaimer: Opinions expressed in this email are those of the author, and
    do not necessarily represent the views of any organization, past or
    present, the author might be affiliated with.)


    On 4/3/12 2:44 PM, "Aaron T. Myers" wrote:
    On Tue, Apr 3, 2012 at 2:37 PM, wrote:

    What would be guideline for a new feature, such as
    https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
    compatibility for 1.x, but is not relevant to trunk, because the
    codebases
    have completely diverged, so cannot be committed to trunk ?
    Are you sure this isn't relevant to trunk? The "target versions" field of
    that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
    that JIRA, the author appears to intend to do this work for both trunk and
    1.0:

    "I want to have the described plugin-ability (desired with same interface)
    for all future versions of Hadoop (as mentioned in the Target Version/s
    field). <snip> On the first phase, I am focusing on the existing 1.0
    branch
    as I know it. In parallel, I'll try to learn what exists in 0.23"

    --
    Aaron T. Myers
    Software Engineer, Cloudera
  • Milind Bhandarkar at Apr 3, 2012 at 10:25 pm
    Great !

    Thanks @atm,

    - milind
    On 4/3/12 3:21 PM, "Aaron T. Myers" wrote:

    If that's the case then there doesn't seem to be any question here. The
    feature is in trunk, and an implementation could be done for an older
    release branch that would be compatible with that branch. Sure, the code
    to
    implement the feature is quite different between the two branches, but
    trunk will remain a superset of the functionality of the past release, so
    no issue.

    --
    Aaron T. Myers
    Software Engineer, Cloudera


    On Tue, Apr 3, 2012 at 3:14 PM, wrote:

    To my knowledge, shuffle is already pluggable in 0.23 onwards, as long
    as
    it is used only by mapreduce framework.

    That's why Avner says : "In parallel, I'll try to *learn what exists* in
    0.23". (Emphasize my own.)

    That's why I was wondering about the insistence of committing to trunk
    first.

    - Milind

    ---
    Milind Bhandarkar
    Greenplum Labs, EMC
    (Disclaimer: Opinions expressed in this email are those of the author,
    and
    do not necessarily represent the views of any organization, past or
    present, the author might be affiliated with.)


    On 4/3/12 2:44 PM, "Aaron T. Myers" wrote:
    On Tue, Apr 3, 2012 at 2:37 PM, wrote:

    What would be guideline for a new feature, such as
    https://issues.apache.org/jira/browse/MAPREDUCE-4049, which maintains
    compatibility for 1.x, but is not relevant to trunk, because the
    codebases
    have completely diverged, so cannot be committed to trunk ?
    Are you sure this isn't relevant to trunk? The "target versions" field of
    that JIRA lists both 1.0.x and 0.24.0 (trunk.) In the latest comment on
    that JIRA, the author appears to intend to do this work for both trunk and
    1.0:

    "I want to have the described plugin-ability (desired with same
    interface)
    for all future versions of Hadoop (as mentioned in the Target Version/s
    field). <snip> On the first phase, I am focusing on the existing 1.0
    branch
    as I know it. In parallel, I'll try to learn what exists in 0.23"

    --
    Aaron T. Myers
    Software Engineer, Cloudera

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcommon-dev @
categorieshadoop
postedMar 28, '12 at 5:32a
activeApr 3, '12 at 10:25p
posts26
users8
websitehadoop.apache.org...
irc#hadoop

People

Translate

site design / logo © 2022 Grokbase