Test major Koha Wiki changes or bug fixes here without fear of breaking the production wiki.
For the current Koha Wiki, visit https://wiki.koha-community.org .User:Victor Grousset - tuxayo/Release maintenance tips
Criteria to backport
Sum up of what I'll try to do
oldoldstable
severity = critial, blocker or security bug
Backport by default
severity = major
Try to backport but don't try too hard if a bit risky, invasive patch or late in the cycle (because oldoldstable will be EOL)
severity =< normal
Don't backport and leave a message that it can be done on demand.
Averse side effect or backporting too much minor stuff: many string changes can actually hinder the translation. Not only bug regressions must be watched but also translation regressions. And these are unavoidable as they are an expected part of the template patches.
Policies of other release maintainers
Note: it really depends on the person and the time resources they can put in backporting so there is not a single way of maintaining a given branch. It's all balance and compromise.
Hayley for oldoldstable
Only backport bug fixes, and sometimes minor enhancements if they didn't have any database changes.
By default try to backport every bugfix regardless of the severity. Though sometimes very minor would be skipped.
MRenvoize for stable
https://wiki.koha-community.org/wiki/MRenvoize/RMaint#18.11
I also propose to have a policy of backporting trivial API and Plugin infrastructure enhancements during my tenure to enable the widest possible range of Koha versions to be supported by upcoming plugins and integrations. I will, however, not compromise security or stability for this goal.
Mics quotes
It's a compilation of stuff that I was told by various people when asking if I should backport something.
It[example bug] verges on API/Plugin support type enhancement.. which I tended to take the stance that so long as there's not an immediately apparent end user change and it was simple to backport then I would.
-
But, at oldoldstable level probably ere on the side of caution and don't bother backporting.
-
These are certainly the ones where a bit of rmaint discretion is the way to go.. no one will blame your for not backporting something... They can always request it if they feel it's important..
-
generally oldoldstable tries to only backported critical or major, as the goal is to protect the version and not really for enhancements, but everyone does it differently really
What if a backport can help future backports to less conflict
Because upstream would have this patch so future backports could be influenced by this.
Well.. you can always revisit a bug if you decide it's easier to backport something else if you also backport this at the time