All, LTS branches will be maintained for 20 months. In that time, some defects will be fixed in an LTS branch and forward merged. Some defects will be identified in master, and we will need to determine whether or not they should be pulled back to one or more of the active LTS branches. As master evolves, there will not always be a straight line from LTS to master. Requiring a direct path between LTS branches and master would either severely constrain the development of master or compromise the stability expected by LTS users. We should also not assume that all backports will be merges/cherry picks — some will be re-implementations due to divergence over time. Like the Ubuntu and Red Hat maintenance cycles, the proposal places the burden of determining the best approach to defect backporting on LTS maintainers to avoid impacting the velocity of feature development. While we should prefer fixing in LTS merging forward, the reality is that maintaining long running maintenance branches will require some cherry picking and re-implementation of defects due to the length of the support window.
It’s also important to note I propose only pulling back blockers and critical severity defects within the scope of the LTS’ functionality from master. The goal of LTS is not to fix every defect. It is to fix those defects that impact system stability or severely degrade functionality. Previously, we conflated feature development and maintenance into a single set of release branches using the same release cycle. With the monthly releases, users have a path to acquire new functionality independent of bug fix/maintenance efforts — removing potential justification to pull back new features or enhancements. As we have discussed this proposal, I think it should be amended to require that all PRs to an LTS branch include an LGTM from the LTS branch RM to ensure that only defects that fit within the narrowly defined constraints. Based on our history, I share your concerns about cherry picking abuse, and have attempt to design the proposal to address them. I believe that the tighter constraints on the defects that are allowed to be backported, a clearly defined policy about the LTS release cycle schedule, and monthly releases will allow us to avoid the mistakes of the past. Thanks, -John > [ShapeBlue]<http://www.shapeblue.com> John Burwell ShapeBlue d: +44 (20) 3603 0542 | s: +1 (571) 403-2411 <tel:+44%20(20)%203603%200542%20|%20s:%20+1%20(571)%20403-2411> e: john.burw...@shapeblue.com | t: <mailto:john.burw...@shapeblue.com%20|%20t:> | w: www.shapeblue.com<http://www.shapeblue.com> a: 53 Chandos Place, Covent Garden London WC2N 4HS UK [cid:imagefafe75.png@d43a0b58.41a20f1c] 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. 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. On Jan 19, 2016, at 6:14 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > > Jeff, That we did before. I don't think that's good enough. It must be the > same commit as far as I'm concerned. Any conflict will be made explicit in > a merge commit that way. > > On Tue, Jan 19, 2016 at 12:08 PM, Jeff Hair <j...@greenqloud.com> wrote: > >> Maybe require all cherry-picks to use the -x option, which puts the >> original commit hash in the cherry-picked commit message? >> >> On Tue, Jan 19, 2016 at 10:53 AM, Remi Bergsma < >> rberg...@schubergphilis.com> >> wrote: >> >>> On a certain night when a release had been cut and there was some worry >>> about a security fix not being included. The root cause was that we >>> cherry-picked that fix and as a result its commit hash had changed. Hence >>> we couldn’t find it. >>> >>> I’d recommend using forward merging instead of back porting aka >>> cherry-picking, so the commit hashes stay the same and fixes are easily >>> traceable. >>> >>> Just my $0.02. >>> >>> Regards, >>> Remi >>> >>> >>> >>> >>> >>> On 19/01/16 08:45, "Daan Hoogland" <daan.hoogl...@gmail.com> wrote: >>> >>>> On Tue, Jan 19, 2016 at 4:20 AM, John Burwell < >> john.burw...@shapeblue.com >>>> >>>> wrote: >>>> >>>>> In terms of the merge strategy, nothing about the current process >> would >>>>> change. Defects would be fixed on the branch where they occurred and >>> then >>>>> forward ported to master. For each maintained LTS branch less than 14 >>>>> months old, only blocker and critical defects that fall within the >> LTS’ >>>>> branch scope would be pulled back from master. Therefore, the number >> of >>>>> defects backported should be relatively small. Any defects found and >>> fixed >>>>> in an LTS branch would be forward ported to master. I will clarify the >>>>> proposal to establish this merge pattern to ensure that LTS does not >>>>> violate or impede the flow of defect fixes on master and maintained >>> monthly >>>>> releases. >>>>> >>>> >>>> John, Any backporting should be avoided. Any fix review should include >>> the >>>> contemplation of the question, 'Is this on the right branch?'. That is >> my >>>> point. I am not against LTS. I want fixes to be traceable by their >> commit >>>> id over all branches. Backporting is killing in that respect. >>>> >>>> I am not the release manager so rest assured I will not make an issue >> of >>>> this any more. I won't hold my peace either, though. >>>> >>>> >>>> -- >>>> Daan >>> >> >> >> >> -- >> *Jeff Hair* >> Technical Lead and Software Developer >> >> Tel: (+354) 415 0200 >> j...@greenqloud.com >> www.greenqloud.com >> > > > > -- > Daan 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 Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
