Merge stable to master vs cherry-picking

[Ahmad Samir]

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