On Thu, Aug 7, 2014 at 4:39 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hi, > > I think the following can solve the cherry-picking problem but it needs > everyone’s support to work: > > - Once a release branch is cut out, all the committers and contributors > “should” only work on the release branch. It can be discussed if we want to > work on it directly or branch out on it and work in that branch and have RMs > to merge that branch on the release branch. IMO if we work directly on the > release branch we potentially reduce a lot of RM’s work. > > - Only (new) feature development and related enhancements/bugfixes can land > on master directly or merged from their respective branches. > > - The RMs or anyone would keep merging the release branch with fast forward > only on regular basis: > git checkout master > git merge --ff <release-branch> > <fix any conflicts and git commit -as etc.> > > This way ‘master' gets all the good stuff from release branch and the release > branch gets “more attention”. > > If we somehow can reduce the release cycle timeline/length, the divergence > between master and release branches can be potentially less causing less > conflicts/issues when following the above. > > Thoughts, flames?
Hi Rohit: Help me understand some of the dynamics here: Folks focus on the release branch while trying to get a release out. Does that prohibit work being done on release+1 (e.g. pushing work to develop that didn't make it in to a release by feature freeze?) --David
