Hi,
can we get an update on this?
Plasma is full on cherry-pick now but in KDE Gear it's inconsistent and
frustrating when some projects use cherry-pick (e.g. Kate) and some
don't (e.g. Dolphin).
I don't really mind what the outcome is but I need it to be consistent
and predictable where to target my MRs, at least for every domain
(Plasma, Gear, ..).
Cheers
Kai Uwe
PS: Since I can never remember: it's git rebase --onto newbase oldbase
branch
Am 29.07.20 um 14:01 schrieb Bhushan Shah:
Hello everyone!
At plasma, we are experimenting with new workflow regarding how bugfixes
are put on the stable branch [1].
# Previous 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
# Current workflow
- Proposed workflow is to instead commit all changes in master, and
cherry-pick related changes in the stable branch as needed
- We had been using this workflow for about 1 month now and I'd say it
is working nicely for us.
# Why?
We occasionally hit several issues with previous workflow,
- Merge conflicts when merging changes upwords
- Changes which are valid only for stable branch needs to be reverted in
master branches. So you end-up with, stable-fix, revert of stable fix
and then different fix and overall weird history.
- Accidential merges from the master branch to stable branch which
needs to be force-resetted.
- It's worth noting that Qt also recently changed to merge to dev,
cherry-pick backwards.
- This also allows for workflows where we want to commit some bugfix in
the master branch for few days/weeks and if it works fine in general
testing then, cherry-pick it in stable branches.
Proposal is to probably adapt this policy kde-wise if people feel that
advantages are worth it.
Thanks
[1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html
