On 29/07/20 14:01, Bhushan Shah wrote:
> Hello everyone!
Hi Bhushan
>
> 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.
IMHO the workflow choice should be left to each project. I can see why
you may want to use it in Plasma, but for the apps I maintain it would
probably double the work for no practical gain.
I'd be ok with a global policy "if unsure always send a MR against
master" (newcomers already do that anyway), but then it should be up to
the maintainer to choose how to handle the MR.
>
> Thanks
>
> [1] https://mail.kde.org/pipermail/plasma-devel/2020-June/117887.html
>
Cheers,
Elvis
