On Mon, Aug 3, 2020 at 11:50 PM Albert Astals Cid <aa...@kde.org> wrote: > > El dimecres, 29 de juliol de 2020, a les 14:01:07 CEST, Bhushan Shah va > escriure: > > At plasma, we are experimenting with new workflow regarding how bugfixes > > are put on the stable branch [1]. > > > > # 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. > > > > The conflicts are still going to be there, if your change has conflicts going > up, it'll have conflicts going down. >
I guess it's mostly about who is doing the merging and committing in this: the hopefully more seasoned people who know the code well because they've been maintaining it for a while or the casual contributor who might not be fully aware of what master might have moved away from that is still in stable (or the reverse). It might also be slightly easier to realise that it turns out you have to backport a bit more, than it is to future proof your code coming from the deep past to minimise the merge conflicts, as it were. > > One improvement I think you didn't mention is: > - "Non-core" people don't know what's the stable branch. I see that in > Okular, most drive-by Merge Requests are against master, because that's the > easy thing to do, for a "newbie" it's hard to figure out if something should > go to the stable branch or not (is it a bugfix? a feature?), and if so, which > is the stable branch if there's one, etc. > I think this one thing alone is the main reason to just do it. People who maintain stable branches know what they signed up for and generally have a pretty good understanding of what they're doing. Even seasoned KDE contributors are going to find a workflow with a single target branch (always master) to be slightly easier to remember than "whatever the stable branch happens to be". > > Proposal is to probably adapt this policy kde-wise if people feel that > > advantages are worth it. I'd lean towards +1 Regards, - Johan
