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
