I'm in favor of merging to master first. It's just easier for me to work that way because the cherry picking is something I can just add on top of my normal git workflow instead of having to remember a different git workflow for situations where we may want to patch a stable branch.
On Thu, Jun 25, 2020 at 10:46 AM 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 > > # 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 > > 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? > > -- > Bhushan Shah > http://blog.bshah.in > IRC Nick : bshah on Freenode > GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
