On 3/12/21 21:21, Glen Ditchfield wrote:
I have almost always merged stable to master, following the
documentation at https://community.kde.org/Infrastructure/
GitLab#Switching_the_target_branch_of_a_Merge_Request
Most of what I do is fixing bugs or warts in PIM, so I debug on the
release/* branch, and commit there to get the changes out to the users
in the next release. I think bug-fixing on master and cherry-picking
back to release wouldn't work so well.
It should; that's how KF works, it doesn't have a stable branches, so any fix is "backported" from
master to stable, it may need some rebasing, but usually it works.
Merging stable to master will need rebasing too, right? so if you're rebasing a commit anyway,
taking from master to fix stable makes more sense, and also means master is the source of all
changes in 99% of the cases.
The same goes with e.g. Konsole, usually it's fixed on master then backported
to stable.
So, give it a shot the next time you're fixing something in PIM? (a practical proof is the best
kind). :)
--
Ahmad Samir
