Right - we need to decide as a community what a forward branch really means.
On Monday, June 9, 2014, Koushik Das <koushik....@citrix.com> wrote: > > On 09-Jun-2014, at 12:56 PM, sebgoa <run...@gmail.com <javascript:;>> > wrote: > > > > > On Jun 8, 2014, at 7:25 PM, Mike Tutkowski <mike.tutkow...@solidfire.com > <javascript:;>> wrote: > > > >> Yes, there appears to be at least two lines of thought on x.y-forward > >> branches (specifically using 4.4-forward as an example here). > >> > >> 1) 4.4-forward and 4.4 should eventually be the same. Once the 4.4 > release > >> goes out the door, 4.4-forward should be removed and changes for 4.4.1, > >> should such a release ever be made, should go into 4.4. > > > > That's what I tried to say. I you commit to 4.4-forward that means that > you want it in 4.4.0, otherwise go to master. > > > > [Koushik] What if the fix is not that critical for 4.4 but would be good > to have in 4.4.1 and above apart from master. I would be concerned if the > fix is in 4.4-forward but not in master. > > > >> > >> 2) 4.4-forward contains changes that might go into 4.4 (if a cherry > pick is > >> requested) and changes that would go into 4.4.1, should such a release > ever > >> be made. > >> > >> In both cases: Most all changes that go into 4.4-forward would need to > go > >> into master (unless that part of the codebase in master has been > modified > >> in such a way as to no longer make this 4.4-forward change relevant for > >> master). > >> > >> We should gain some consensus on what x.y-forward means. > >> > >> > >> On Sun, Jun 8, 2014 at 10:51 AM, Daan Hoogland <daan.hoogl...@gmail.com > > > >> wrote: > >> > >>> As I read your comments you actually don't agree with Sebastien, > >>> Sudha. 4.4-forward was cut of at code freeze. Since then fixes are > >>> committed there and cherry-pick are done by the RM. It seems that this > >>> is exactly what Sebastien meant it to be for. > >>> > >>> @Sebastien: in Shengs words I read that some of the things in > >>> 4.4-forward would only go in 4.4 after the release (thing with lower > >>> priority then critical) > >>> > >>> We all don't agree, let's agree on that.;} > >>> > >>> On Sun, Jun 8, 2014 at 2:27 PM, Sudha Ponnaganti > >>> <sudha.ponnaga...@citrix.com> wrote: > >>>> Agree with Sebastien. 4.4 is cut too early. By cherry picking and > >>> missing some of the critical fixes in to 4.4, isn't it safe to baseline > >>> with 4.4-forward which has majority of the fixes. It is not like new > >>> features are added to 4.4 forward. Looks like most of them are fixes to > >>> existing functionality on 4.4. > >>>> > >>>> Thanks > >>>> /Sudha > >>>> > >>>> -----Original Message----- > >>>> From: sebgoa [mailto:run...@gmail.com] > >>>> Sent: Sunday, June 08, 2014 4:52 AM > >>>> To: dev@cloudstack.apache.org > >>>> Subject: Re: [ACS44] 112 unpicked cherries in 4.4-forward. why? > >>>> > >>>> > >>>> On Jun 8, 2014, at 5:31 AM, Sheng Yang <sh...@yasker.org> wrote: > >>>> > >>>>> To my understanding 4.4-forward is a staging tree for 4.4.1 release > >>>>> currently, and only issues critical enough would go for 4.4 branch, > >>>> > >>>> I disagree. That makes things messy, 4.4-forward should only exist > till > >>> 4.4 is out, really everything in 4.4-forward should go in 4.4.0. > >>>> then folks commit to 4.4 for future bug fix releases... > >>>> > >>>> -sebastien > >>>> > >>>> > >>>>> and > >>>>> author would ask for pick up in that case. I think that's what's > >>>>> happened with 4.3-forward branch. > >>>>> > >>>>> --Sheng > >>>>> > >>>>> > >>>>> On Sat, Jun 7, 2014 at 3:05 PM, Sudha Ponnaganti < > >>>>> sudha.ponnaga...@citrix.com> wrote: > >>>>> > >>>>>> Wondering why not baseline with 4.4-forward branch. > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > >>>>>> Sent: Saturday, June 07, 2014 2:53 AM > >>>>>> To: dev > >>>>>> Subject: [ACS44] 112 unpicked cherries in 4.4-forward. why? > >>>>>> > >>>>>> H, > >>>>>> > >>>>>> To start with my personal finger pointing: especially test authors > >>>>>> and UI devs seem to be to blame for the difference (and me of > course). > >>>>>> please take a moment to make sure your important work is not going > to > >>>>>> be lost for future generations. > >>>>>>< -- *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>*™*
