Historically, Elisa has used a workflow whereby merge requests/commits are landed on either the master branch or the stable branch, and if the target was the stable branch because it was a bugfix, that branch is merged forward into master. A few years ago, Plasma moved to a different workflow whereby all merge requests/commits are landed on the master branch, and cherry-picked backwards into the stable branch as needed. Having used both approaches for a few years, I find that overall the cherry-pick workflow seems to reduce friction: 1. No more asking the submitter to change the target branch of their MR if it's a bugfix 2. No more manual merging, which means no more annoying merge conflicts in the `CMakeLists.txt` file after every branching event 3. You can cherry-pick right form the GitLab web UI, which is nice and fast and you don't have to leave the website after merging using the website I'd like to formally propose that we adopt it in Elisa. Matthieu Gallien is Elisa's formal maintainer, but he has not been active recently so I'm also CCing the top five contributors by number of lines added over the past year according to GitHub (https://github.com/KDE/gwenview/graphs/contributors?from=2021-05-24&to=2022-05-24&type=c, which has better tools for visualizing this compared to GitLab): Me, Tranter Madi, Han Young, Friedrich Kossebau, and Laurent Montel. What say ye?
+1
As I got cc::ed I have at least to say: fix bugs in the current product version,. Only then integrate those changes also into the development version, by whatever way. Backports to the product version instead come with increased risks of regressions and thus lower quality. Not involved with Elisa otherwise, so unsubscribing
Ok, that sounds like a -1. +1 from me, for the reasons given in the description. Any other opinions?
No other responses. That's +2 and -1, which seems like a total of +1 to me, which means it's agreed-to.