4.4-forward should be removed. I have let it be as for a cooldown period. It has conflicts with 4.4 and I want to have a branch per fix/backport to merge. Leo's advice was to merge them as --no-ff. I haven't which has resulted in no merge commits in some cases. For single commits this is allright.
At the moment I would not want any features for 4.4.1 on 4.4. We are effectively in a code freeze now. In general I am not against this practice. Let's not be to generous with this. features are our measure of moving forward. As for contacting RMs: In older branches you should only have to when a release is planned/announced. If not there is no reason to wait for anyone else. On Wed, Aug 13, 2014 at 10:25 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Hey, > > On 13-Aug-2014, at 5:12 am, David Nalley <da...@gnsa.us> wrote: > >> On Tue, Aug 12, 2014 at 6:04 PM, Rohit Yadav <rohit.ya...@shapeblue.com> >> wrote: >>> I remember we agreed to not use the -forward branches, so can we get rid of >>> them please? >>> >>> I was reviewing someone’s patch and they had targeted that for >>> 4.3.0-forward, though this branch is far behind than 4.3 branch; so does >>> not make sense to merge their work on the forward branch. I’m going ahead >>> with the main branches as I see they are already ahead of the forward >>> branches. >>> >> >> I think Sebastien was working on a 4.3.1 release. (and acting as its >> release manager) Perhaps worth asking him. > > I think no one is using the forward branches and all of them are behind the > main release/support branches (you may check yourself), so let’s get rid of > them? > > Few questions around support branches such as 4.3, 4.2 etc: > - Do we have any norm on backporting changes, or we do it already? If we > don’t should we discuss doing something like this as many opensource project > do it? > - While backporting should it be only bugfixes or we can backport useful > features? > - To backport any bugfix or change, how do we commit them on old > release/support branches such as 4.2, 4.3 etc.? Do we directly commit on them > or ask present RMs? > > Regards, > Rohit Yadav > Software Architect, ShapeBlue > M. +41 779015219 | rohit.ya...@shapeblue.com > Blog: bhaisaab.org | Twitter: @_bhaisaab > > > > Find out more about ShapeBlue and our range of CloudStack related services > > IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > CloudStack Infrastructure > Support<http://shapeblue.com/cloudstack-infrastructure-support/> > CloudStack Bootcamp Training > Courses<http://shapeblue.com/cloudstack-training/> > > This email and any attachments to it may be confidential and are intended > solely for the use of the individual to whom it is addressed. Any views or > opinions expressed are solely those of the author and do not necessarily > represent those of Shape Blue Ltd or related companies. If you are not the > intended recipient of this email, you must neither take any action based upon > its contents, nor copy or show it to anyone. Please contact the sender if you > believe you have received this email in error. Shape Blue Ltd is a company > incorporated in England & Wales. ShapeBlue Services India LLP is a company > incorporated in India and is operated under license from Shape Blue Ltd. > Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is > operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company > registered by The Republic of South Africa and is traded under license from > Shape Blue Ltd. ShapeBlue is a registered trademark. -- Daan
