I agree to the goal. No regressions can be achieved either by cherry-picks or merges. Both requires developers to agree to it and has equal probability to miss.
The advantage in case of merge is, lets say you do a commit a1 to 4.5 branch and forget to merge to master. now, someone else did a2 and is trying to merge. He will see both the commits and can make choice either to ask about a1 or merge both. may be if the merge has conflicts or is not a clean merge, it can be done as PR which follows the usual process. with respect to refactoring, we can always do separate PRs on master and the release branch. The merge from release branch to master in this case would be an empty merge (git merge -s ours) The problem I see with the current approach is its not always backporting the fix to release. This works if the issue reported is already known and fixed on master or any forward releases. Usually, you work on a release branch only when an issue is reported on it. For a issue reported on 4.5, first thing I do is check if the issue really exists in 4.5 and would also find the solution around the same time. Its sounds natural to me to push to 4.5(get the load off your head whether it is customer issue or security issue) and then merge to forward releases. Now, with the new process, I will have to first verify if the bug exists in the current release+1, fix in it first, then go back to release branch, verify if it exists and fix it there. Obviously there would be exceptions in merging and you may have to cherry-pick once in a while. But, making it the process is what concerns me. In addition to the goal mentioned, I would also like to find which all versions the commit is present in. For example, If a security issue is reported on 4.5, I found that this is a regression from commit abcde. Now, I would like to find which all version this is present as this security patch should be delivered on all the versions. In the current situation and also in the new process suggested, the only way to find it is to go to each and every release and see if the commit is present. In the merge route, its simple git merge --contains abcde Merging is not easy. It requires discipline. But, it has benefits. If everyone follows it, its as easy as cherry-picking as the code diff will be exactly same. Maintaining a release is the second part of the story :) I do agree with you on the release process for 4.6. Lets start with it for 4.6 release and continue discussing on how we want to maintain 4.6.x(may be we would never need one ;)) I can volunteer to be the additional RM for 4.6. ~Rajani On Fri, Jul 3, 2015 at 1:36 PM, 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. > > 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 > >
