I think before starting to discuss a better workflow, we should describe the current one.
For now, I’m the only one who manages the back-ports. I manage it by keeping in an mailbox the commit message that are eligible to be back-ported. From time to time (about every 1-2 weeks), I check this mailbox and applies the patches (older than 1 week) to all supported branches (branches for which the patch applies and without too much conflict). Then I delete the message from the mailbox.
This is a simple process that works pretty well. Over the past 10 years, I think I may have missed less than 10 patches.
The eligibility rules are:
- It must fix a bug (that can not be worked around)
- It must not change the API or requires database update
- It must be simple/minimal
Now if we want to change this process, for me it must stay simple, not increase the workload.
I do not think it will help as-is.
I’m not against having this information in the bug tracker but then it should have some requirements:
- We should be able to see all the patches that must be back-ported
- They should be automatically solved when they are back-ported
But the big difficulty is to decide on which version the patch should be back-ported. For now, the decision is made by trying to apply it on the branch. If this should be decided upfront, there will be false-positive and this will increase the workload.
Maybe we could have a single keyword and the hook updating the roundup may remove the flag for commit done on other branch than ‘default’.
The only drawback is that it requires a manual intervention on the issue to set the keyword. But I could keep my current workflow and just check additionally the list of issues with the keyword.