What's the correct process for adding a dozen or more commits from master to a release branch? Do they have to be done as individual patches? Or is it common to squash them? Or something else? Or should one just not let release branches get that far behind? :)
Topic on Talk:Gerrit/Advanced usage/Archive 2
Release branches here don't normally have that much backported to them, mainly just security fixes and fixes for major bugs. When they do get backports, it's done by cherry-picking the individual patches.
I suppose it's possible some extension or the like follows a different model.
Ok, cool, good to know I'm not missing anything obvious. :)
And yeah, it's mostly for extensions that I'm thinking — where they're following a release branch policy, it seems like it's a good idea to ensure all commits are backported unless they're not compatible, because we recommend people checkout e.g. REL1_31 but they mightn't actually get any updates on that branch ever, and so are left further behind than they could be.
The benefit of cherry-picking is mostly that it integrates well with Gerrit. Specifically that 1) Clicking on or searching for the Change-Id reveals the change in all branches, 2) Using the "Included in" interface correctly shows the branches the change is a part of.
I'd expect cherry-picks for MediaWiki core. But individual extensions may do it differently if maintainers agree.
So the workflow could just be to merge a bunch of commits from master to REL1_31 locally, and then push all at once? But that requires particular permissions on Gerrit doesn't it? Normally, it'd just result in a separate patch being created for each commit, I think. I'm not sure how CI would work in that scenario anyway, because it'd still want to be testing each commit...
Sounds like the single-commit cherry-pick way is best, if a bit slower.