Rohit, I don't see any reasons beyond lack of discipline, ignorance, and laziness in your description. Not of an RM or other individual btw but of the community as a whole. In point 1 and 2 you are describing how cherry-pick and forward merge are actually the same amount of work. In the case of forward merge however we will have a merge commit describing what that work was and still a link in later branches to the commit.
Point 3 is actually where we should be proactive. If they don't care we should tell them to create a branch against the offending commit and work from there. On Wed, Jan 20, 2016 at 11:32 AM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > Based on my long-time experience with maintaining and doing release work > on 4.3 and later 4.5, there are many reasons where backporting is needed > and forward merge won’t work; > > 1. Due to high codebase changes mostly due to major refactorings, it is > not possible to simply cherry-pick a commit; backporting many times > involved writing the fix manually based on the commit diff that I wanted to > backport. Cherry-picking becomes impossible if anyone has changed package > names, file/directory paths, removed code etc. > > 2. Forward merging will also start failing (due to same reason as above) > as time progress the codebase diverges due to refactoring, new code and any > design/architectural changes. The other issue with forward merging is that > it would require merging from the oldest branch to the newest, with time > there would be several branches (given the monthly pace) between the LTS > branch and the future master branch. So, in my experience backporting may > become necessary. > > 3. The bugfix author may not send their fix/PR against old branches, as > time progresses developers won’t care much about the older LTS branch(es). > Wrt 4.3/4.5 at times I had to backport changes myself after failing to get > the original author send the fix against 4.3/4.5 branch. This is expected > of developers, as they contribute in our own *free* time and they may not > have the time, bandwidth or interest in seeing those fixes in older > branches. > > For example, we’ve 4.7 and 4.8 (upcoming) where forwarding merging will > work for sometime, but in 14-20 months the developers may not send > bugfix/PRs against 4.7 and expect future RMs to merge them forward as that > would require both merge-conflict fixing and testing for all intermediate > branches 4.8 to 4.20 (assuming, monthly releases we’ll at least reach 4.20 > in 14-20 months and I’m not sure if RMs will have time and dedication to > test all 12+ releases/branches ). For non-LTS branches, it may not make > sense to even have those bugfixes. > > In my experience (with pseudo LTS branches, 4.3/4.5) and opinion, LTS > branches are going to diverge wrt master with time but they are going to > have a dead-end. > > About cherry-picking, the way we’re going git commits/merge at least I’m > not able to follow the git history at all, it looks like a mess to me. We > talk about ability to trace commits through branches, but I cannot even > follow changes in the same branch now (say master). I personally use git > diff and git log -p to trace changes using differences now (in files or > paths/folders). Cherry-picking is not bad, if done right (always include > the git commit ID from where it was picked using -x -s) you can trace it. > > Regards. > > [image: ShapeBlue] <http://www.shapeblue.com> > Rohit Yadav > Software Architect , ShapeBlue > d: * | s: +44 203 603 0540* <%7C%20s:%20+44%20203%20603%200540> | m: > *+91 8826230892* <+91%208826230892> > e: *rohit.ya...@shapeblue.com | t: * > <rohit.ya...@shapeblue.com%20%7C%20t:> | w: *www.shapeblue.com* > <http://www.shapeblue.com> > a: 53 Chandos Place, Covent Garden London WC2N 4HS UK > 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. > > > 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/> > -- Daan
