cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [PROPOSAL] LTS Release Cycle
Date Wed, 20 Jan 2016 11:56:00 GMT
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.yadav@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.yadav@shapeblue.com | t: *
> <rohit.yadav@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message