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]> 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/
