I just tried to ensure the backport was not missed because I saw that there were other commits backported after this issue was commited. In this case I saw that the commit had been done +10 days ago and I seem to remember that backports were done within a week after the commit in default.
What is the rule used for backports? How can we be sure that a backport was not missed without causing more noise? Would it make sense to add a “backport” keyword to issues, for example?
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.
If the current workflow works I don’t see a big problem with keeping it. Don’t want to put more burden.
It’s just kind of a blackbox where we don’t know when/if a backport will happen. That it’s not a problem for NaN-tic because we keep our own patches. When we ask if it will be backported is more to ensure that is not forgotten, rather than a need for us. Except for client fixes, but as we’re moving to Sao, shouldn’t be a problem anymore either.
However, it may be interesting to know how others are dealing with fixes and backports.
That sounds reasonable to me.
Not sure I understood correctly the last bit: as I understand, if the keyword is added maybe you should just check those issues that have the keyword. No need to check the mailbox. Right?
I do not think I will spend time on adding the keyword on the issues. So I will keep my mailbox workflow and others can flag issue for backport (that may happen or not).
We are maintaining just like NaN-tic our own patch/backport set. For us and supposedly all downstreams it is valuable information if there is an intent to backport. We are seeing here and there inquiries in the bug tracker, if a fix will be backported or not. This overhead could be streamlined, if the information about the intention to backport would be public. As well I agree that this would offer more control about evtl. forgotten patches. Hence the proposed adding of a keyword on the bugtracker could perhaps also save time in the workflow.