DISCUSSION - tracking regression and backports: what do we want?
Following the discussion on IRC, I've asked myself if I'm over-engineering things, so let's have a discussion about what we want and how we can do that.
Things we want:
-
track regressions to make sure we fix them ASAP
-
make sure all MRs associated with regressions are backported, ie. the fix is not only in
master
but also in the stable branch(es) -
nominate commits to be backported, even without a corresponding regression issue; a) before merging, b) after merging
Current solutions:
-
regression
label let us know the issue is or was a regression at some point and may have been fixed at some point and may have been backported to some branch; lots of unknowns here, requiring a lot of manual work from maintainers with no way to keep track of it from one release to the next -
release milestones allow us to track MRs that need to be backported to one (1) stable branch. We always have an overlap in releases, so this solution is unusable. Currently no other solution exists either.
-
if the dev knew & remembered to add it to the commit message, a)
Fixes:
andCc: mesa-stable@
; otherwise b) create another MR targetingstaging/XX.Y
My proposal:
I've been adding a bunch of gitlab labels to help track all this. The maintainer-scripts can look at all the issues and MRs with said labels, and inform the maintainer of the status of everything or perform automatic actions such as nominating a commit for backport.
One common concern is "label spam" so let me address that: the idea is that when a stable branch is closed, ie. no new release will be made, all the labels relating to that branch are removed, which should mean that this system uses no more than about 12 labels at any given time.
-
a separate
regression-in-XX.Y.Z
for each release that contains the regression but not the fix.- When a release is being prepared, any still open regression gets carried over to the new release's label, so that we don't loose track of regressions.
- For all the regressions present in the latest release that have been closed by an MR, make sure that MR is backported before the new release. This can be automated into our maintainer-scripts with precise enough labels.
- If the commit at fault is not part of any release yet,
regression-in-master
is used; if that issue is still open by the time the next stable branch is cut, the issue will get the new release's regression label.
-
this would be automatically tracked as part of 1. above
-
Fixes:
andCc: mesa-stable@
are here to stay, but the latter can be replaced with abackport-to-XX.Y
that can also be applied to MRs after they've been merged, solving the issue with 3b. The next time the maintainer runs the tools, the MR will be backported.
To summarize, for the devs this means the following:
-
the
regression
label should be deprecated in favour of version-specificregression-in-XX.Y.Z
(orregression-in-master
if the commit at fault is not part of any release yet) -
if you have a specific commit that you're fixing, please use
Fixes:
, it's the best one can do. -
if you forgot to tag a commit before merging it, or if you don't have a specific commit you're fixing, you can use the
backport-to-XX.Y
label to request a backport. Once the MR is backported, the label will automatically be replaced withbackported-to-XX.Y
to indicate to the dev that it has been done. (This is not necessary from the maintainer's point of view, and if devs don't need this then we can drop that label)
That's about 10 labels per release (usually no more than 8 releases with possible regressions + "please backport" + "backported"), and with a new stable branch overlapping that's 3 more, so 13 labels for this system. All labels for a stable branch are deleted once that branch is closed, which means usually there will be much fewer.
If there's an other/better/different solution you want to suggest, feel free to do it, nothing is set in stone.
/cc the maintainers @dbaker @evelikov @tanty @jasuarez
/cc from the IRC discussion @jekstrand