Koha Test Wiki Canasta - March 2024

One of a series of test instances for migrating the Koha Wiki MediaWiki database.

For the current Koha Wiki, visit https://wiki.koha-community.org .

User:Victor Grousset - tuxayo/Release maintenance tips

From Koha Test Wiki Canasta
Jump to navigation Jump to search

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