Mike, Why have everybody work on the same branch. people can work on their own branch and when they are done they can rebase on the tip see ci success and then merge. The problem with forward branches is abandoned work or work that for some reason shouldn't go in 'this' release. it will remain there.
On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > Are we talking about something like what I drew up here?: > > http://i.imgur.com/UgPtJGY.png > > In this scheme, the -forward branches are the ones you can directly commit > to while their peers without the -forward are the ones that code gets > merged to from its corresponding -forward branch. > > CI is performed on the -forward branches before any merging takes place. > > The "merge recorded" concept I put in the diagram refers to the situation > where you have a commit on a branch like 4.5, but you do NOT want it to > move forward to master. > > I don't know if Git has such a concept, but SVN calls this kind of a > "merge" merge recording. Merge recording essentially means you do not want > those changes brought forward to the specified branch (not now and not with > future merges other people or yourself may do). > > > > On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi < > animesh.chaturv...@citrix.com> wrote: > >> >> >> > -----Original Message----- >> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] >> > Sent: Thursday, October 23, 2014 1:31 AM >> > To: dev >> > Subject: Re: [PROPOSAL] Move to github PR only during moratorium on >> > commit >> > >> > On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav >> > <rohit.ya...@shapeblue.com> wrote: >> > > Hi, >> > > >> > >> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi >> > <animesh.chaturv...@citrix.com> wrote: >> > ... >> > >> The approach for fixing issues in release branch first and master >> later is >> > not practical as we may miss out commits not made into master and future >> > release regressing without the fixes. >> > > >> > > By the same logic, if we fix by default on master only, the release >> branch >> > may miss out commits. >> > >> > I sttrongly disagree with Animesh here and think Rohit is overlooking a >> > simple fact. At the moment the branches are for 'stabalizing'. >> > Fixing on master first is in direct contradiction with that. >> > >> > We have not been stabalizing 4.4. it contains bug that have during the >> > release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't >> > have been allowed to happen. >> [Animesh] Clearly we have disagreement. To avoid the issue that you >> mention David had created forward branch for 4.2 and I found it useful and >> continued with that approach in 4.3. With forward branch which are really >> staging it was a simple merge of forward back to release branch. The other >> approach of merging release branch into master work as well but in my >> opinion keeping master as the default branch (with protection of course ) >> is simpler to understand and creates less confusion >> >> > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* -- Daan
