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