> All the bug fixes are deferred to release manager cherry-picking to bug fix > branches. Since master and branches are quickly diverged with changes, > it is very painful for cherry-picks later and there is no clear process for > cherry-pick and labelling.
What is painful here? If it's the conflict resolution, this pain would just be spread out, with it being felt by whomever is merging, but then it would also be worse, because cherry-picks would happen out of order. In the past I've had more success with processes which keep day to day development on master 100% of the time. If and when you want to cut a release branch, at that point, you go through the commits in master since the last release, and select those that should make the bugfix release. Once you have the list, cherry-picking, in-order, can occur. This creates more work for the release manager, but it removes the need to think about the releases from the developer in their day-to-day. > Shall we consider following the process what BookKeeper is using, having a > merge script to handle labelling issues/milestones and also cherry-picks? That script turns a 5 second task into a 5 minute task. It also creates a decision point for the developer where the answer is not always clear. If no bugfix releases are currently planned, should I still cherry-pick in branch-1.22? -Ivan
