Yeah, Daan, the approach you describe sounds like a reasonable substitute for what I have in that diagram.
My main concern was CI running before the code was checked into the "real" branch from the staging branch. On Fri, Oct 24, 2014 at 1:12 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > 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 > -- *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>*™*
