trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandhya Sundaresan <>
Subject RE: Please note Trafodion changes - 2.1 Vs Master
Date Mon, 27 Feb 2017 18:13:23 GMT
Hi folks,
   A merge inadvertently caused the 2.1 branch to get a bunch of unintended changes. These
changes were supposed to go into the master branch only but got merged into 2.1 as well and
pulled in 6 changes from master into 2.1.
  This caused the minor version of the 2.1 branch to changes to 2  as a result of the merge
 pulling in a version change intended only for the master branch.

So a note to developers.
•       If your change is absolutely needed for 2.1 please create your branch against release/2.1
and create the PR against the 2.1 branch. Committers please merge these PRs to branch  release2.1
as opposed to master. (See instructions in the email chain 2 emails below)
•       2.1 changes will ultimately get pulled into 2.2 (master) so you don't really have
to merge changes intended for 2.1 into master by yourself.
•       If your change is NOT intended for 2.1, please create your PR against master and
do not merge from that workspace into 2.1. We don't want to add any more changes at this point
into 2.1 other than some known python installer changes and some documentation changes.  If
you're unsure please check with me.


-----Original Message-----
From: Steve Varnau []
Sent: Wednesday, February 22, 2017 9:42 AM
Subject: RE: Help committing a PR

The author also chooses by where they base their change. At this point, release branch and
master are close to same, but they will start to diverge.  merging in a pull request to 2.1
branch that was based on master may pull in unintended content.


> -----Original Message-----
> From: Sandhya Sundaresan []
> Sent: Wednesday, February 22, 2017 9:24 AM
> To:<>
> Subject: RE: Help committing a PR
> Hi Suresh,
>   The 2.1 branch was branched off at a stable point when all the regressions
> were running clean. We'd like to keep it as stable as possible and not add any
> new commits to it.
> So unless it's feature like the Python installer which is part of the planned
> content for 2.1 and we know has a couple of issues, we don't need to commit
> to 2.1.   The author can make that determination in most cases and if not
> check on this dev list or me.
> Yes the instructions on this link are valid :
> Make note of the following that is already documented in it :
> "Target Branch
> Before beginning, make careful note of what branch you are merging to. At
> the top of the pull request, you'll see words like, "So-and-so wants to merge
> n commits into apache:target_branch from
> github_user:some_other_branch. Most of the time, target_branch will be
> "master", but occasionally you'll see a release branch instead, e.g.,
> "release1.3". In the instructions below, if the target_branch is not "master",
> replace "master" with the name of the target branch."
> Sandhya
> -----Original Message-----
> From: Suresh Subbiah []
> Sent: Wednesday, February 22, 2017 9:18 AM
> To:<>
> Subject: Help committing a PR
> Hi,
> I am trying to merge Zalo's PR 958 to the incubator-trafodion branch. I use
> Hans' myapachecommit script to merge PRs. Today I find that it does not
> work and gives this error message.
> "unable to determine target branch of pull request"
> I can see that the grep/sed command used by myapachecommit script may
> be thrown off by the creation of the 2.1 branch. I can try to fix that.
> However I am not sure if I should be merging new PRs to the release2.1
> branch or to master. I can see that Ming merged to master a few hours ago.
> Steve's PR 974 is slated for release2.1. My questions are
> 1) Does the author of the code make the determination on which branch to
> merge to? Does the committer have any guidelines or checks to do before
> merging the change (regarding target branch)
> 2) I suppose the commit procedure described here is still valid to push to
> master. How should they be modified to push to release 2.1?
> Thank you.
> Suresh

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