Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Flume >> mail # dev >> [IMPORTANT] Flume development and release branches.


Copy link to this message
-
Re: [IMPORTANT] Flume development and release branches.
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
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB