On Thu, Jun 25, 2020 at 3:46 PM Bhushan Shah <bs...@mykolab.com> wrote:
> Hello everyone! > > This is a proposal to change our workflow regarding release branches and > our merge workflow, > > # Current workflow > > - Current workflow is that we commit to stable branch and then merge it > upwords until master branch > - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then > master > > # Proposed workflow > > - Proposed workflow is to instead commit all changes in master, and > cherry-pick related changes in the stable branch as needed > > Gitlab supposedly has a magic button for it just after a commit has landed in master. https://docs.gitlab.com/ee/user/project/merge_requests/cherry_pick_changes.html Though I don't know how to trigger that in our UI. > # Why? > > We occasionally hit several issues with current workflow, > > - Merge conflicts when merging changes upwords > - Changes which are valid only for stable branch needs to be reverted in > master branches > - Accidential merges from the master branch to stable branch which needs > to be force-pushed > > It's worth noting that Qt also recently changed to merge to dev, cherry-pick backwards. In principle I completely agree. I have a few fears, which I hope are all addressable. - we need some reference to the real commit. Qt adds " (cherry picked from commit 6de0287d7c3aa4251fe6eb4f970d73ce11cf07fc)" to the commit message automagically somehow in their workflow. - without making people commit locally into stable, could it encourage people to not test as much? > For now I am proposing this change only for Plasma repositories if we > like it, we can propose this workflow for rest of KDE repositories, but > that needs discussions in kde-devel/kde-core-devel separately. > > Thoughts? > I like consistency across KDE, otherwise it's very difficult for people who contribute in N places. We should at least email before we change, though we can still discuss things here first. David
