Summary: | Release team 22.05 | ||
---|---|---|---|
Product: | Koha | Reporter: | Martin Renvoize (ashimema) <martin.renvoize> |
Component: | About | Assignee: | Martin Renvoize (ashimema) <martin.renvoize> |
Status: | Pushed to oldoldoldstable --- | QA Contact: | Marcel de Rooy <m.de.rooy> |
Severity: | normal | ||
Priority: | P5 - low | CC: | david, dcook, fridolin.somers, jonathan.druart, kyle, m.de.rooy, testopia, victor, wainuiwitikapark |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28442 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28904 |
||
Change sponsored?: | --- | Patch complexity: | String patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
21.11.00,21.05.05,20.11.12,19.11.24
|
|
Circulation function: | |||
Bug Depends on: | 27108 | ||
Bug Blocks: | 30808 | ||
Attachments: |
Bug 23900: Add 22.05 release team to teams.yaml
Bug 29300: Add 22.05 release team to teams.yaml Bug 29300: Add 22.05 release team to teams.yaml |
Description
Martin Renvoize (ashimema)
2021-10-21 12:00:34 UTC
Created attachment 126664 [details] [review] Bug 23900: Add 22.05 release team to teams.yaml Add the 22.05 release team. Test plan 1/ Check against https://wiki.koha-community.org/wiki/Release_Teams Created attachment 127023 [details] [review] Bug 29300: Add 22.05 release team to teams.yaml Add the 22.05 release team. Test plan 1/ Check against https://wiki.koha-community.org/wiki/Release_Teams https://bugs.koha-community.org/show_bug.cgi?id=29300 Signed-off-by: David Nind <david@davidnind.com> Hi Martin. I have signed off, but noticed that it doesn't include: - Release maintainers - Topic experts - IRC meeting facilitator - Continuous integration infrastructure maintainer (shown as Jenkins maintainer) - Website Maintainer - Wiki Curator - Newsletter Editor - Social media managers I'm just assuming that this is because they haven't been shown for previous releases, and possibly (apart from release maintainers) it is because they are wider community roles, rather than for a specific release. David (In reply to David Nind from comment #3) > Hi Martin. > > I have signed off, but noticed that it doesn't include: > > - Release maintainers > - Topic experts > - IRC meeting facilitator > - Continuous integration infrastructure maintainer (shown as Jenkins > maintainer) > - Website Maintainer > - Wiki Curator > - Newsletter Editor > - Social media managers > > I'm just assuming that this is because they haven't been shown for previous > releases, and possibly (apart from release maintainers) it is because they > are wider community roles, rather than for a specific release. > > David Release maintainers should be included imo. We did in the past too. But the other roles are more or less outside the scope of the release team. Topic expert is not really an actual role, its more info. (I think we should not include them in the roles vote.) David did you see: + maintainer: + - version: 21.11 + name: Kyle M Hall + - version: 21.05 + name: Andrew Fuerste-Henry + - version: 20.11 + name: Victor Grousset + - version: 19.11 + name: Wainui Witika-Park And:
+ te:
+ - area: UI Design
+ name: Owen Leonard
+ - area: REST API
+ name: Tomás Cohen Arazi
+ - area: Zebra
+ name: Fridolin Somers
+ - area: Accounts
+ name: Martin Renvoize
te = topic expert
+ meeting_facilitator:
+ - name: Jessica Zairo
+ ci:
+ - name: Tomás Cohen Arazi
CI Continuous Integratoin
+ wiki:
+ - name: Thomas Dukleth
+ - name: Jake Deery
+ newsletter:
+ - name: Michael Kuhn
+ accessibility_advocates:
+ - name: Wainui Witika-Park
Seems that you only did not see:
> - Website Maintainer
> - Social media managers
(In reply to Marcel de Rooy from comment #4) > (In reply to David Nind from comment #3) > Release maintainers should be included imo. We did in the past too. But the > other roles are more or less outside the scope of the release team. Topic > expert is not really an actual role, its more info. (I think we should not > include them in the roles vote.) Conclusion: They turn out to be almost all in. I would define the borders of the release team a bit narrower. But, no problem. Created attachment 127026 [details] [review] Bug 29300: Add 22.05 release team to teams.yaml Add the 22.05 release team. Test plan 1/ Check against https://wiki.koha-community.org/wiki/Release_Teams Signed-off-by: David Nind <david@davidnind.com> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Pushed to master for 21.11, thanks to everybody involved! Pushed to 21.05.x for 21.05.05 Pushed to 20.11.x for 20.11.12 Backported: Pushed to 20.05.x branch for 20.05.18 Maybe I shouldn't have backported to 20.05.x since it will reach end of life?
Now in the about page I see:
> This is the team who are responsible for the next release of Koha and the ongoing maintenance of your currently installed Koha version. They will be in these roles up until 05/22/2022
Which doesn't make sense.
And as a consequence, the Release maintainer role isn't present. Since in the 22.05 team there is no such role.
I would say that I should revert from 20.05.x and that in the future if this patch comes up before the end of the cycle, then the soon to EOL release shouldn't backport it.
Wait, there is more, shouldn't 21.05.x and 20.11.x have waited next cycle before backporting? As the wrong RMaint is listed.
Good points to raise.. This patch should be bakported as one of the last things one does prior to their final release as RMaint.. though any time during that last month is fine really as it won't take wider effect until release. As for the last one to contain it, I'm not sure where I stand on that one.. perhaps if there's not an RMaint listed we should display 'No longer actively supported by the community' or something like that.. or 'Security release only, refer to the website for the current release team' ? With the introduction of LTS releases, this becomes a bigger question indeed. Another option is to put 'end of life' details into the teams.yaml and publish that on the about page too? > This patch should be bakported as one of the last things one does prior to their final release as RMaint.. though any time during that last month is fine really as it won't take wider effect until release. But about.pl will still say that the release is maintained while it's already EOL? I plan to revert from 20.05.x unless I missed something and someone tells me. That way it will be like the past cycles where the next team patch was done and backported on the beginning of it's cycle. So only the still supported releases had this team. > Another option is to put 'end of life' details into the teams.yaml and publish that on the about page too? EOL could be mentioned when the RMaint isn't found. Then yes it's makes sense to backport the next team in a release soon-to-be-EOL Could someone please help me with what I should do with this bug for 19.11.x? I think it is too late this month to add it to 19.11.x but I can add it next month? Did we reach a final agreement on what our support process would be.. how long is long in LTS terms.. do we continue to maintain three stables + the LTS or do we drop at least one stable so we can concentrate on doing a good job of maintaining an LTS.. how far back to security only releases continue. I think we need to consider these things before adding an 'End of life' date into releases... I'd love to see a rolling stream added personally. Reverted from 20.05.x as it's end of line. See comment 13 and following (In reply to wainuiwitikapark from comment #17) > Could someone please help me with what I should do with this bug for 19.11.x? I think you should backport it. Like for 21.05 and 20.11, this bug is relevant for 19.11. Backported: Pushed to 19.11.x branch for 19.11.24 |