| *** amoralej|off is now known as amoralej | 08:15 | |
| ttx | hberaud: elodilles : Can we get https://review.opendev.org/c/openstack/reno/+/873024 in? Fixes tests for modern git and would like to include it in reno 4.0.0 | 08:39 |
|---|---|---|
| ttx | which we need out asap to fix release notes all over | 08:40 |
| * hberaud looks | 08:40 | |
| ttx | only affects tests | 08:40 |
| ttx | thanks! will update https://review.opendev.org/c/openstack/releases/+/876753 once that lands | 08:42 |
| hberaud | ttx: do you know why we can't access jobs logs? | 08:45 |
| hberaud | example https://review.opendev.org/c/openstack/releases/+/876567 | 08:45 |
| hberaud | I reviewed a couple of this morning and logs seems unavailable all the time | 08:46 |
| opendevreview | Hervé Beraud proposed openstack/releases master: release ironic 21.4.0 and branch stable/2023.1 https://review.opendev.org/c/openstack/releases/+/876573 | 08:51 |
| ttx | hmm, no | 08:53 |
| hberaud | ttx: other question, the ironic team migrated their patches to release a minor version even if the latest tag doesn't justify it. They want a room for bugfix patches, I think they want a possibility to release bugfix version even for anterior versions, example: 1.3.0 exist, we propose 1.3.1 but they want 1.4.0 to allow them to release 1.3.1 and 1.4.1, I don't think we want | 08:56 |
| hberaud | to allow that, correct? | 08:56 |
| hberaud | ttx: example https://review.opendev.org/c/openstack/releases/+/876572 | 08:56 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: [neutron] New Xena releases for Neutron https://review.opendev.org/c/openstack/releases/+/876827 | 09:15 |
| ttx | They basically want to support additional stable branches (bugfix/) in addition to the openstack-blessed one (stable/). I don't see why we'd object to that, as long as the tooling does not complain too much about it... | 09:17 |
| hberaud | ok wfm | 09:18 |
| ttx | as far as release management is concerned, we would ignore those bugfix/* branches | 09:18 |
| hberaud | ok | 09:20 |
| hberaud | I wasn't sure | 09:21 |
| opendevreview | Jake Yip proposed openstack/releases master: Release magnum RC1 for Antelope https://review.opendev.org/c/openstack/releases/+/875418 | 09:24 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron https://review.opendev.org/c/openstack/releases/+/876828 | 09:28 |
| ttx | Between those inaccessible logs and some jobs taking ages to enqueue, I feel like our infra is not in perfect shape today. We should probably refrain from approving stuff until the US crew gets up and looks into it | 09:51 |
| opendevreview | Rajat Dhasmana proposed openstack/releases master: Release cinder RC1 for Antelope https://review.opendev.org/c/openstack/releases/+/875397 | 09:57 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: Release neutron-tempest-plugin for 2023.1 Antelope https://review.opendev.org/c/openstack/releases/+/876616 | 10:01 |
| opendevreview | Merged openstack/reno master: Fix scanner tests failing with modern Git https://review.opendev.org/c/openstack/reno/+/873024 | 10:07 |
| opendevreview | Thierry Carrez proposed openstack/releases master: Release reno 4.0.0 https://review.opendev.org/c/openstack/releases/+/876753 | 10:22 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron https://review.opendev.org/c/openstack/releases/+/876828 | 10:30 |
| elodilles | ttx: sounds OK to me, though as I see zuul is in better shape now: https://zuul.opendev.org/t/openstack/status | 10:31 |
| elodilles | at least I could look at the logs that I opened o:) | 10:32 |
| elodilles | do you still experience issues? | 10:32 |
| ttx | seems better now | 10:34 |
| ttx | There are still missing logs for that release failure from yesterday, but I think that one will be refreshed as soon as a new release happens | 10:34 |
| ttx | (publish-tox-docs-releases fail) | 10:35 |
| ttx | elodilles: feel free to review and approve reno 4.0.0 so that we can doublecheck release notes look better | 10:35 |
| elodilles | ttx: ack, i will look at the release patch now | 10:36 |
| elodilles | +2+W'd | 10:39 |
| elodilles | let's see if everything works as expected | 10:39 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: [neutron] New Zed releases for Neutron https://review.opendev.org/c/openstack/releases/+/876835 | 10:39 |
| opendevreview | Slawek Kaplonski proposed openstack/releases master: New neutron-lib release for stable/zed https://review.opendev.org/c/openstack/releases/+/876837 | 10:47 |
| opendevreview | Elod Illes proposed openstack/releases master: Release venus-tempest-plugin for 2023.1 Antelope https://review.opendev.org/c/openstack/releases/+/876621 | 10:56 |
| zigo | Cinder's release tag is ready for approval: https://review.opendev.org/c/openstack/releases/+/875397 | 10:58 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: [neutron] New Zed releases for Neutron https://review.opendev.org/c/openstack/releases/+/876835 | 11:00 |
| elodilles | zigo: ack, looks OK, +2'd | 11:03 |
| opendevreview | Merged openstack/releases master: Release reno 4.0.0 https://review.opendev.org/c/openstack/releases/+/876753 | 11:11 |
| opendevreview | Merged openstack/releases master: Branch ironic-P-A-B https://review.opendev.org/c/openstack/releases/+/876571 | 11:11 |
| opendevreview | Merged openstack/releases master: Branch stable/2023.1 for networking-baremetal https://review.opendev.org/c/openstack/releases/+/876574 | 11:17 |
| whoami-rajat | sorry it took long for cinder, i was trying to get a change in but it seems a lost cause for RC1 as of now, will target that for RC2 (and see if the backport is acceptable) | 11:26 |
| elodilles | whoami-rajat: ack, thanks. yes, it is a bit late for RC1, and we still have a bit of a time for rc2 | 11:40 |
| whoami-rajat | elodilles, thanks | 11:54 |
| *** amoralej is now known as amoralej|lunch | 12:17 | |
| ttx | elodilles: we can also approve https://review.opendev.org/c/openstack/releases/+/875418 which will conclude the RC1 list | 12:25 |
| ttx | also this one https://review.opendev.org/c/openstack/releases/+/876767 | 12:26 |
| opendevreview | Merged openstack/releases master: Release cinder RC1 for Antelope https://review.opendev.org/c/openstack/releases/+/875397 | 12:36 |
| opendevreview | Elod Illes proposed openstack/releases master: Add Horizon Antelope cycle highlights https://review.opendev.org/c/openstack/releases/+/876767 | 12:40 |
| elodilles | ttx: magnum patch +2+W'd; I've updated the horizon patch ^^^ as there were some wording mismatch o:) | 12:42 |
| elodilles | ttx: also, there are quite many approved tempest plugin patches that need a 2nd review, if you have time o:) https://review.opendev.org/q/topic:antelope-tp-latest+label:PTL-Approved | 12:44 |
| ttx | wanted to check if reno 4 kicks in first | 12:50 |
| opendevreview | Merged openstack/releases master: Release magnum RC1 for Antelope https://review.opendev.org/c/openstack/releases/+/875418 | 12:51 |
| elodilles | we can test that with the nova patch | 13:00 |
| ttx | not sure how to test it | 13:03 |
| elodilles | well, i guess 1st this needs to be merged: https://review.opendev.org/c/openstack/requirements/+/876846 | 13:04 |
| elodilles | and then recheck this: https://review.opendev.org/c/openstack/nova/+/876553 | 13:04 |
| elodilles | though, of course it can be tested by a local run of the above patch with bumped upper constraints ^^^ | 13:04 |
| elodilles | tested it locally and reno was generated fine with reno===4.0.0 \o/ | 13:16 |
| elodilles | so we need the req bump patch to merge and the nova patch will pass | 13:16 |
| elodilles | but now i have to disappear for about an hour | 13:19 |
| *** elodilles is now known as elodilles_afk | 13:20 | |
| ttx | ok pinging prometheanfire to approve https://review.opendev.org/c/openstack/requirements/+/876846 | 13:37 |
| ttx | will push it tomorrow morning in case he does not get to it today | 13:38 |
| *** amoralej|lunch is now known as amoralej | 13:44 | |
| rosmaita | hello ... what was the final decision on the proposal to EOL rocky and stein openstack-wide? | 13:54 |
| *** elodilles_afk is now known as elodilles | 14:58 | |
| elodilles | rosmaita: hi, well, to tell you the truth, i forgot about that mail thread o:) | 15:04 |
| elodilles | rosmaita: i wanted to wait a bit to get some more opinions | 15:05 |
| rosmaita | looks like zigo is against it, everyone else is in favor! | 15:05 |
| rosmaita | elodilles: i couldn't remember if you were going to do openstack-wide, or individual projects should propose patches | 15:06 |
| elodilles | rosmaita: i wanted to do it openstack-wide | 15:06 |
| rosmaita | i'm asking because the cinder rocky gate is hosed, and there's no point fixing it if it's about to go EOL | 15:07 |
| elodilles | rosmaita: considering that some of the core projects have already EOL'd their rocky branches (neutron, nova) | 15:07 |
| rosmaita | elodilles: exactly | 15:07 |
| elodilles | rosmaita: the question is now whether cinder team would accept patches without gate jobs | 15:08 |
| rosmaita | elodilles: no, definitely not | 15:08 |
| rosmaita | well, that's me, i shouldn't speak for the whole team these days | 15:08 |
| elodilles | rosmaita: yeah, i'm in the same opionion, some level of gate jobs are definitely needed | 15:09 |
| elodilles | and unfortunately rocky and stein gates are completely broken for most of the projects | 15:10 |
| elodilles | (as I can see these are the latest mails in the topic: https://lists.openstack.org/pipermail/openstack-discuss/2023-February/thread.html#32018 ) | 15:11 |
| rosmaita | elodilles: i guess my question is, should we wait for the openstack-wide retirement, or should we push cinder project patches now to EOL rocky and stein? | 15:14 |
| rosmaita | does it make any difference to the release team? | 15:14 |
| zigo | rosmaita: This is a very bad sum-up of my opinion. I'm not against making EOL, and stop having a gate, I'm just against removing any possibility to push and share security fixes to the branch (even without a gate). | 15:32 |
| elodilles | rosmaita: the same patches need to be proposed, so actually it does not make a difference | 15:33 |
| rosmaita | zigo: ack, sorry to mischaracterize | 15:34 |
| elodilles | zigo: EOL means the branch is deleted, so that at least is contradicting | 15:34 |
| zigo | Right... | 15:35 |
| zigo | Feel free to ignore me anyways ... :) | 15:35 |
| rosmaita | well, i think what zigo is after is EOL and no more patches, but the branch is kept so that patches can be posted to gerrit and discussed in public | 15:35 |
| rosmaita | i mean, no more merged patches | 15:35 |
| zigo | rosmaita: Exactly, you got my point !!! :) | 15:35 |
| zigo | We could merge patches after at least 2 distros validated them, for example. But no need to have the extra effort to maintain a gate, as downstream distros (like me with Debian...) have other ways to test patches. | 15:36 |
| elodilles | hmmm, that is interesting. as far as I know gerrit does not allow patches against non-existing (deleted) branches, but maybe i'm wrong | 15:36 |
| zigo | FYI, I managed to break Rocky, Stein and Train for Nova ! :) | 15:36 |
| zigo | elodilles: That's the point, we need to keep at least the branches. | 15:37 |
| rosmaita | elodilles: i think you are correct, so we would have to change the policy about deleting EOL branches | 15:37 |
| rosmaita | i guess we could have a "community maintenance" mode for those branches, where the openstack project team is no longer responsible for what goes on in those branches | 15:38 |
| rosmaita | though now that i said it out loud, it sounds like a recipe for disaster | 15:38 |
| rosmaita | or maybe not | 15:39 |
| rosmaita | i guess we could have responsible "community-maintenance-cores" with some kind of vetting process | 15:39 |
| elodilles | the problem i think (what I remember; i wasn't there in the early days of OpenStack) is that people would propose patches against EOL'd branches and teams would end up with a bunch of open patches that no one ever reviews, or even finds, when it is needed for them. | 15:40 |
| elodilles | even Extended Maintenance exists with the same purpose: to let people cooperate and propose bugfix backports. unfortunately even EM branches are poorly maintained | 15:41 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: Release neutron-tempest-plugin for 2023.1 Antelope https://review.opendev.org/c/openstack/releases/+/876616 | 15:41 |
| elodilles | maybe this is a good topic for teams or PTLs or for the TC @ PTG | 15:42 |
| elodilles | zigo: in my opinion, in rare cases (like Security bug fix backports to EOL'd branches), there is the possibility, to add a patch to the bugreport | 15:45 |
| elodilles | zigo: if i remember well team members offered the help in the recent case as well, so when a patch is in a good shape, discussed with project teams, it can be attached to the bug report | 15:47 |
| elodilles | zigo: would that end up with the same result that you want with keeping branches open? | 15:48 |
| elodilles | zigo: and it could be ease to find (sometimes even easier than to find in gerrit) | 15:48 |
| zigo | elodilles: Well, for the VMDK vuln, we had no help from upstream for any branch before Ussuri in Nova... | 15:51 |
| zigo | Because it needed more patches to be backported, probably. | 15:51 |
| elodilles | zigo: hmm, i see, it's still not backported (not even a WIP) for train | 15:55 |
| elodilles | well, i wanted to help with the review (or even backport) to train, but it lost in my TODO list :S | 15:58 |
| elodilles | anyway, i understand your point, but still, it is more painful to keep old branches open. as those need some kind of maintenance anyway, if not that to keep things operational, then the clean-up time to time, to be able to change / remove old, unused CI jobs, for example | 16:02 |
| fungi | skimming because there's a lot of discussion here, but just to reiterate, extended maintenance doesn't require that there be any jobs run for those branches, nor that the changes proposed for them will ever necessarily be merged. the whole point of extended maintenance was to provide a place for downstream consumers to be able to share and collaborate on patches rather than all doing | 16:20 |
| fungi | the same redundant work independently. it was never supposed to be a burden on the core review teams for projects, they should only ever have to care about the officially maintained branches and can ignore or delegate control over extended maintenance branches to other people entirely | 16:20 |
| fungi | rosmaita: were you under the impression that the health of extended maintenance branches was the responsibility of the project teams? | 16:21 |
| rosmaita | fungi: i know technically it is not, but we do feel a responsibility while they are open | 16:22 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron https://review.opendev.org/c/openstack/releases/+/876828 | 16:22 |
| fungi | they're only "open" so that people can coordinate patches for those branches after they core teams are no longer caring for them. that's why we stop tagging releases once the branches transition to extended maintenance | 16:24 |
| fungi | would renaming "extended maintenance" to "community maintenance" make it more clear? | 16:24 |
| fungi | to me' "community maintained" feels like the alternative to "commercially maintained" (like you find in open-core software) | 16:25 |
| fungi | so i'm not all that keen on the name | 16:25 |
| rosmaita | fungi: yes, i see your point about the name | 16:34 |
| rosmaita | i wonder whether 'unmaintained' would be better | 16:36 |
| fungi | i have always felt that we should just combine the extended maintenance and unmaintained states, the distinction for switching between them has always been uselessly vague | 16:37 |
| fungi | for whatever reason, though, people find "unmaintained" to be a scary name even though it means mostly the same as how extended maintenance is already defined | 16:38 |
| rosmaita | i am coming around to your way of thinking | 16:38 |
| elodilles | i also find "community maintained" less scary and more meaningful than "unmaintained" | 16:49 |
| elodilles | but maybe it's just me :) | 16:49 |
| fungi | well, regardless the point would be to get rid of the separation between the current extended maintenance and unmaintained states since there's no effective distinction between them. just go from stable maintenance by core review teams with full testing and point releases, to uncoordinated maintenance by interested members of the broader community with limited testing while no longer | 17:32 |
| fungi | tagging releases, then to eol once it stops making sense to keep the branch open | 17:32 |
| fungi | naming is, as always, the hardest part of the problem | 17:33 |
| *** amoralej is now known as amoralej|off | 17:36 | |
| opendevreview | Merged openstack/releases master: Add Horizon Antelope cycle highlights https://review.opendev.org/c/openstack/releases/+/876767 | 17:37 |
| opendevreview | Rodolfo Alonso proposed openstack/releases master: [neutron] New Yoga releases for Neutron https://review.opendev.org/c/openstack/releases/+/876828 | 17:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!