Define and document our backporting workflow with GitLab

Currently it is a bit unclear how that should happen, in gst-editing-services!5 (comment 75953) I just accepted to merge a MR targetting 1.14 and then forward ported it on master right away (which I guess is fine as soon as it is done with caution), but we should have a clear policy about that.

Once we have CI I would definitely want all commits go though it before merging, meaning also backports, we should define our worflow to make it as painless as possible.

IMHO we should always target master (unless it does not apply to master) first, and then do a backport MR with one or more changes to be backported. Things that are candidates for backporting should get a tag/label for that (then we could in theory even automate the backporting to a bot!).

We also need to document usage of the target milestone field.

Maybe we could have a regression label for such fixes that should be backported ? Or would that already be covered by Blocker ?

It might be a bit trickier to "automate" the backporting though. The code could have changed quite a bit.

Once we have CI I would definitely want all commits go though it before merging, meaning also backports, we should define our worflow to make it as painless as possible.

That part is easy. All code needs to go through MR (including backports), CI runs on MR :)

Maybe we could have a regression label for such fixes that should be backported ? Or would that already be covered by

Not all backports are regressions or blockers (blockers could also only affect master) though, that's why I thought of a new label

It might be a bit trickier to "automate" the backporting though. The code could have changed quite a bit.

In Rust there's a script that collects all these things, and then for conflicts you have to either opt-out of that specific change or manually fix the merge conflicts. And then you submit a MR.

In any case, something for the future (automation / semi-automation) :)

Once we have CI I would definitely want all commits go though it before merging, meaning also backports, we should define our worflow to make it as painless as possible.

That part is easy. All code needs to go through MR (including backports), CI runs on MR :)

Well, should we ask the proposer to do it or the person who merges? - also I was more thinking about making it more automatic but...

In any case, something for the future (automation / semi-automation) :)

:-)

Well, should we ask the proposer to do it or the person who merges? - also I was more thinking about making it more automatic but...

Whoever gets to it first IMHO. We didn't have problems with this in the past, no need to complicate things.

Well, should we ask the proposer to do it or the person who merges? - also I was more thinking about making it more automatic but...

Whoever gets to it first IMHO. We didn't have problems with this in the past, no need to complicate things.

Right, just mention it is a backport with the link of the original MR I guess :-)

I would like to keep the blocker label for release management purposes.

I think a new regression label makes sense, and also a backport label perhaps. Not so sure about the latter yet, how it would be used - only makes sense if we can somehow query things that still need to be backported.

You would keep a needs-backport label on the MR until it happened, then remove the label. And you could easily query for that then.

You would keep a needs-backport label on the MR until it happened, then remove the label. And you could easily query for that then.

on the MR or on the issue ? You could very well have one issue (describing the problem, regression,...) which has multiple MR against it.

Should be a per MR thing fmpov.

On the MR(s), yes

So you would put a label on a MR which is closed ?

Yes, afaiu it is what @nirbheek does for meson backports.

the rationale of putting it on the issue is that you could leave that issue open until the backport is done

There might not always be an issue to go with MRs though.

There's nothing wrong with putting a label on closed MRs :)

just means having to go to the list of closed MR, instead of the default list of MR.

Indeed, a search like this one (enhancement -> needs-backport):

https://gitlab.freedesktop.org/groups/gstreamer/-/merge_requests?scope=all&utf8=%E2%9C%93&state=closed&label_name[]=Enhancement

I'm not saying it's not possible. I'm saying it's yet-another-place-one-needs-to-look-at