On Fri, Jul 3, 2015 at 10:06 AM, Remi Bergsma <r...@remi.nl> wrote: > Hi Rajani, all, > > I do think we have the same goal in mind: no regression and no cherry-pick > mess. > > Just did some reading on "tofu scale" and see two issues: > - if it doesn't happen / isn't completed we'll have regression as we've > seen before. I want a working model that prevents regression by default or > else we will not reach smooth upgrades without introducing old bugs again. > - we are doing lots of refactoring work (probably will be doing even more) > where this model also will not work because the merge fails to apply > cleanly (this is what Erik mentioned yesterday). Fixing that conflict is > invisible on the dev-list (as we have no PR) and error prone (not tested > before commit, no LGTMs). > > Don’t get me wrong, I don’t want the cherry-pick mess we experienced > before. > > What will be different: > - master is stable instead of unstable > - we’ll branch off x.y (say 4.6 which is up next) only after a vote on a > RC passes. Instead of branching it off first, then make it stable and > release it and cherry-pick stuff around. So, no cherry-picking here. > - once the x.y branch is there, we should do no back ports of features. > Only (critical?) bug fixes. > > Those bug fixes (that went to master first through PR and got 2x LGTM) > could now also be applied to the x.y. branch (and become x.y.1 or similar) > Instead of cherry-picking, I’d apply the same PR to x.y (if possible, or > else a new PR that reimplements the fix for x.y in which case it would need > its own 2x LGTM). In any bug fix PR we should mention the jira bug id (and > PR id) in the commit message. This, you could argue, is like cherry-picking > as it makes a new commit id. As the amount of bug fix commits should me > minimal, I think this is ok. > > We should make sure upgrades are so smooth that our users can upgrade > easily and we don’t have to maintain previous releases for a long time. > > I clarified some more things on the wiki and also updated the diagrams. > >
I'm no hardcore dev, so take my opinions with a grain of salt, but this looks reasonable to me and a step in the right direction. +1 -- Erik
