Brock, Yes, I think we should branch off from Flume-1.3.0, since trunk has some local commits(non-RTC - though the code is the same) in addition to the merge commits. Please branch off from flume-1.3.0 when you are ready.
Thanks Hari -- Hari Shreedharan On Tuesday, October 16, 2012 at 12:48 PM, Brock Noland wrote: > Hi, > > OK, I am working on the RC and I had this question, should the > flume-1.4.0 branch be based off trunk or 1.3.0? Normally I would say > trunk, but it was my understanding we didn't want the release branches > to have merge commits, which trunk has. > > Brock > > On Fri, Aug 24, 2012 at 3:57 PM, Hari Shreedharan > <[email protected] (mailto:[email protected])> wrote: > > To be clear, all commits should go to flume-1.3.0(till of course, > > flume-1.3.0 is finalized) as of now. By current release branch, I meant the > > branch which will be released (as opposed to the ones already released, > > which should not be touched). > > > > Hari > > > > -- > > Hari Shreedharan > > > > > > On Friday, August 24, 2012 at 1:27 PM, Hari Shreedharan wrote: > > > > > Please read this page for some more details: > > > http://flume.apache.org/source.html > > > > > > > > > Thanks > > > Hari > > > > > > -- > > > Hari Shreedharan > > > > > > > > > On Friday, August 24, 2012 at 12:52 PM, Hari Shreedharan wrote: > > > > > > > Also note that I have cherry picked all commits till this morning. Any > > > > further commits will have to be handled by the committer who commits it > > > > to trunk. > > > > > > > > Thanks > > > > Hari > > > > > > > > -- > > > > Hari Shreedharan > > > > > > > > > > > > On Friday, August 24, 2012 at 12:50 PM, Hari Shreedharan wrote: > > > > > > > > > Fellow developers, > > > > > > > > > > The Flume PMC has decided to keep an active release branch along with > > > > > trunk. All commits that go into trunk will also have to be committed > > > > > using git cherry-pick and pushed to the current release branch. > > > > > > > > > > This does not change anything for contributors, but changes the > > > > > workflow for committers. > > > > > > > > > > Committers should first commit the patch to trunk on your local repo: > > > > > git commit (Enter commit message). > > > > > git log > > > > > > > > > > Copy the commit hash of the commit you just made. Then: > > > > > git checkout flume-1.2.0 (or the current release branch) > > > > > git cherry-pick <commit hash of the commit you made> (This should get > > > > > committed immediately). > > > > > > > > > > Now push to both trunk and the release branch: > > > > > git push -u origin trunk > > > > > git push -u origin flume-1.2.0 > > > > > > > > > > > > > > > > > > > > > > > > > The committer should make sure the commits are pushed to both > > > > > branches. Please make sure all commits to the release branch are fast > > > > > forward commits and there are no merge commits on the release branch. > > > > > > > > > > This process requires a little more work, but this guarantees that > > > > > our release tags will not have accidental and local commits in its > > > > > history, as we can force push to the release branches to remove these > > > > > from history. Ideally we should try to keep the history on release > > > > > branches linear, but if at some point we decide to start using > > > > > feature branches, we might end up having merge commits on these > > > > > branches too, but that is expected and required - since that would > > > > > represent the list of commits for that feature. > > > > > > > > > > I will update the website soon with this information. Please let me > > > > > know if you have any questions - which I expect many would have. > > > > > > > > > > > > > > > Thanks, > > > > > Hari > > > > > > > > > > > > > > > -- > > > > > Hari Shreedharan > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Apache MRUnit - Unit testing MapReduce - http://incubator.apache.org/mrunit/ > >
