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. Regards, Remi > On 3 jul. 2015, at 04:29, Rajani Karuturi <raj...@apache.org> wrote: > > I do not agree to backporting aka cherry picking. I prefer forward > merges(tofu scale) 4.4 to 4.5 to master etc. > That way, none of the changes will be missed and git branch --contains > gives a nice view of where all the changes went. > > > On Thu, Jul 2, 2015 at 23:16 PM, Remi Bergsma <r...@remi.nl > <mailto:r...@remi.nl>> wrote: > > Hi Daan, > > Indeed. I prefer committing to master first, as it will ensure everything > ends up there (unless some specific use cases). Currently, we have the risk > of forgetting to include a fix to a release branch back to master. > > When we reverse it, some bug fix that should end up in the x.y branch, is > committed to master, then also applied (or reimplemented) to x.y. If you > then only take one of the two steps, there is no issue as it will be in > master only (and people will notice). In the other situation, when we > accept a PR to x.y and forget to merge back, we possibly introduce > regression bugs. > > I will update the diagram and wiki later tonight. > > While reviewing PRs, let’s be alert to see PRs not pointed towards master > and at least discuss it. > > Regards, > Remi > > >> On 2 jul. 2015, at 16:54, Daan Hoogland <daan.hoogl...@gmail.com > <javascript:;>> wrote: >> >> On Thu, Jul 2, 2015 at 2:29 PM, Remi Bergsma <r...@remi.nl >> <mailto:r...@remi.nl> <javascript:;>> > wrote: >>> Since the goal is a stable master, I’d say the bug fix should go to > master first. >> >> >> Remi, this means that merge back of the branch makes no sense anymore. >> >> -- >> Daan > > > > -- > - > Sent from Windows Phone > ~Rajani
