| opendevreview | Tony Breeds proposed openstack/election master: Remove DPL model projects. https://review.opendev.org/c/openstack/election/+/873046 | 00:32 |
|---|---|---|
| opendevreview | chenker proposed openstack/election master: Add Ke Chen candidacy for Watcher PTL https://review.opendev.org/c/openstack/election/+/872677 | 00:49 |
| opendevreview | chenker proposed openstack/election master: Add Ke Chen's candidacy for Watcher PTL https://review.opendev.org/c/openstack/election/+/872677 | 01:23 |
| opendevreview | Tony Breeds proposed openstack/election master: Remove DPL model projects. https://review.opendev.org/c/openstack/election/+/873046 | 02:49 |
| opendevreview | Merged openstack/election master: Add Ke Chen's candidacy for Watcher PTL https://review.opendev.org/c/openstack/election/+/872677 | 03:19 |
| *** JasonF is now known as JayF | 04:12 | |
| *** blarnath is now known as d34dh0r53 | 06:52 | |
| *** blarnath is now known as d34dh0r53 | 07:02 | |
| opendevreview | Michal Nasiadka proposed openstack/election master: Michal Nasiadka candidacy for Kolla PTL Bobcat/2023.2 https://review.opendev.org/c/openstack/election/+/873066 | 08:35 |
| *** amorin_ is now known as amorin | 09:09 | |
| opendevreview | Axel Vanzaghi proposed openstack/election master: Adding Axel Vanzaghi candidacy for project Mistral https://review.opendev.org/c/openstack/election/+/873095 | 09:50 |
| *** blarnath is now known as d34dh0r53 | 12:14 | |
| opendevreview | Axel Vanzaghi proposed openstack/election master: Adding Axel Vanzaghi candidacy for project Mistral https://review.opendev.org/c/openstack/election/+/873095 | 13:26 |
| *** dasm|off is now known as dasm|rover | 13:51 | |
| *** tosky_ is now known as tosky | 14:19 | |
| *** dasm|rover is now known as dasm|afk | 15:36 | |
| gmann | tc-members: weekly meeting in 5 min from now | 15:55 |
| gmann | #startmeeting tc | 16:00 |
| opendevmeet | Meeting started Wed Feb 8 16:00:17 2023 UTC and is due to finish in 60 minutes. The chair is gmann. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'tc' | 16:00 |
| gmann | #topic Roll call | 16:00 |
| dansmith | o/ | 16:00 |
| gmann | o/ | 16:00 |
| slaweq | o/ | 16:00 |
| knikolla[m] | o/ | 16:01 |
| noonedeadpunk | o/ | 16:01 |
| rosmaita | o/ | 16:02 |
| gmann | let's wait for couple of min, meanwhile this is today agenda #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting | 16:02 |
| spotz | o/ | 16:02 |
| gmann | let's start | 16:04 |
| gmann | #topic Follow up on past action items | 16:04 |
| gmann | JayF to write document on how to remove pypi maintainer/owner access and a draft email for PTLs to use when asking former-contributors to give up their access. | 16:04 |
| gmann | JayF has started working on this, we will talk about it in separate topic we have next | 16:04 |
| gmann | #topic Gate health check | 16:04 |
| gmann | any better news with gate :) ? | 16:05 |
| gmann | we are seeing lot of timeout in various tempest jobs now a days | 16:05 |
| dansmith | lots of timeouts :( | 16:05 |
| gmann | which blocking the things to merged | 16:05 |
| dansmith | *still* trying to get my chunked get patch merged, but it keeps getting nailed | 16:05 |
| slaweq | I noticed at the begining of the week some failure due to failed download of ubuntu images | 16:05 |
| noonedeadpunk | and timouts seems to be related just to some very slow/overloaded provider | 16:05 |
| gmann | yeah | 16:05 |
| gmann | noonedeadpunk: not sure if that is the only reason | 16:06 |
| slaweq | yeah, timeouts is also something what I saw often recently | 16:06 |
| dansmith | we're also seeing an occasional failure with the glance test that tries an external http download of cirros, so I have a patch up to make that retry a few times | 16:06 |
| gmann | yes, I need to review that. will do today | 16:06 |
| noonedeadpunk | Well, out of our jobs, they do timout in the middle of execution, on tasks that was not hanging for too long | 16:06 |
| dansmith | it hasn't gotten a clean test yet, but it is passing the tests it's supposed to of course | 16:07 |
| noonedeadpunk | So it looked like execution is slow overall | 16:07 |
| dansmith | noonedeadpunk: same | 16:07 |
| gmann | noonedeadpunk: ohk | 16:07 |
| dansmith | I've also seen timeouts in older release jobs, | 16:08 |
| dansmith | so I don't think it's anything like keystone or nova suddenly do a sleep(1) in every request or anything | 16:08 |
| dansmith | i.e. a performance regression in one of the release-specific services that is causing it to go slower | 16:08 |
| noonedeadpunk | no-no, the jobs that passing do have proper execuiton time | 16:08 |
| gmann | yes, I also did not see any increase in time for passing job | 16:09 |
| noonedeadpunk | and timouts are quite random on scenario/OS | 16:09 |
| dansmith | are the passing jobs just under the job timeout? or do the timed out jobs end up running way longer for some reason? | 16:09 |
| gmann | what i observed is passing jobs are taking time they use to do in previous releases or so | 16:10 |
| gmann | at least not noticeable increase in their time | 16:10 |
| noonedeadpunk | so my bet would be on some overloaded provider. I think it should be possible to identify what provider is that, but I'm not sure we have spare capacity for nodepool to just disable it... | 16:10 |
| dansmith | gmann: okay but it seems to me like they're fairly close to the timeout right? | 16:11 |
| dansmith | like a full-xena run that did not timeout ran in 1:55 but a full-zed that did was 2:05 | 16:11 |
| dansmith | noonedeadpunk: if nothing is wrong and it's just a slow provider, then perhaps a different job timeout for that provider, or we split up some jobs so they run in less time | 16:12 |
| gmann | but if you see other passing rate tempest-full-py3 takes ~1.35 in many time | 16:12 |
| dansmith | gmann: on that same patch I was looking at full-py3 took 1:57 | 16:12 |
| dansmith | but okay | 16:12 |
| noonedeadpunk | dansmith: well, we had job timeout set in 3h, and job that takes in average 1.40-2h does timeout | 16:13 |
| gmann | yeah not always. | 16:13 |
| slaweq | noonedeadpunk I think it's the same in neutron check queue as well | 16:13 |
| dansmith | is it set at 3h or 2h? because it seems like 2h is the threshold from what I'm seeing | 16:13 |
| slaweq | but I don't have links to any jobs now | 16:13 |
| fungi | noonedeadpunk: zuul logs the provider id if the builds have logs available. if not, i should be able to look it up from the executor's service logs | 16:14 |
| gmann | dansmith: tempest multinode/slow jobs are 3 hr ands rest are 2 | 16:14 |
| noonedeadpunk | dansmith: in osa we have 3h | 16:14 |
| dansmith | gmann: okay | 16:14 |
| noonedeadpunk | fungi: yup, logs are available - they don;'t reach post timeout | 16:14 |
| fungi | in that case, look in the zuul info log files | 16:14 |
| fungi | you may also be able to correlate it with dpawlik's opensearch service | 16:15 |
| gmann | rax-iad is recent provider I am seeing taking 3 hr for tempest-slow job which used to take 2 hr https://zuul.opendev.org/t/openstack/build/5f5f48160b0049d99153d0d60909cee7/log/job-output.txt#49 | 16:15 |
| dansmith | gmann: I guess my point is.. it seems like some legit full runs are dangerously close to the 2h mark, so either a slight performance regression, or a few extra tests could be causing all the jobs on our slowest provider to tip over that mark lately | 16:15 |
| gmann | dansmith: yeah, agree with that. i have started the test split in this, #link https://review.opendev.org/c/openstack/tempest/+/873055 | 16:16 |
| gmann | need some more work on that, checking some project gate coverage on those extra tests | 16:17 |
| dansmith | gmann: ack | 16:17 |
| gmann | anyways, let's monitor the provider if we can identify the one making things slow | 16:17 |
| gmann | anything else on gate ? | 16:18 |
| gmann | #topic Cleanup of PyPI maintainer list for OpenStack Projects | 16:18 |
| gmann | Etherpad for audit and cleanup of additional PyPi maintainers | 16:19 |
| gmann | #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup | 16:19 |
| gmann | ML discussion | 16:19 |
| gmann | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-January/031848.html | 16:19 |
| gmann | as discussed in last meeting, JayF is working on the email template and steps to remove/give access to openstackci | 16:19 |
| gmann | ha has prepared the email template for PTLs to ask additional maintainers to do the required steps #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup-email-template | 16:20 |
| gmann | adding PyPi steps also here #link https://review.opendev.org/c/opendev/infra-manual/+/873033 | 16:20 |
| gmann | please check and add it in etherpad if any feedback | 16:20 |
| JayF | I will respond to feedback on that PR/etherpad this afternoon. | 16:20 |
| gmann | +1 | 16:21 |
| gmann | another thing is to explicitly add PyPi things in governance as policy | 16:21 |
| gmann | noonedeadpunk: if i remember correctly you wanted to add it in documentation ? | 16:22 |
| gmann | that will help to clearly document the process on PyPi acess | 16:22 |
| noonedeadpunk | Yes, I didn't manage to push patch yet as took a week of vacation | 16:22 |
| noonedeadpunk | But was planning to do that during this week | 16:23 |
| gmann | perfect, let me add action item just to track | 16:23 |
| knikolla[m] | great! | 16:23 |
| gmann | #action noonedeadpunk to add PyPi access policy in governance documentation | 16:23 |
| noonedeadpunk | +1 | 16:24 |
| gmann | JayF: as you are on top of your email template and steps documentation, do you want me to continue your action item for next meeting? | 16:24 |
| JayF | It'd be ideal for me if we can action those before next meeting | 16:24 |
| JayF | e.g. get general agreement on email and if the change merges, we can update actions for PTLs | 16:24 |
| gmann | JayF: also, please add this email template/sending to main etherpad also in step1 #link https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup | 16:25 |
| JayF | I'm waiting to do that until folks here give a general agreement to the etherpad :) | 16:25 |
| gmann | sure | 16:25 |
| JayF | if it's OK for me to do that; I'm going to do it :D | 16:25 |
| gmann | JayF to write document on how to remove pypi maintainer/owner access and a draft email for PTLs to use when asking former-contributors to give up their access. | 16:25 |
| gmann | thanks JayF for working on that | 16:25 |
| gmann | anything else on PyPi things? | 16:25 |
| gmann | #topic Recurring tasks check | 16:27 |
| gmann | Bare 'recheck' state | 16:27 |
| gmann | #link https://etherpad.opendev.org/p/recheck-weekly-summary | 16:27 |
| gmann | slaweq please go ahead | 16:27 |
| slaweq | nothing really new there | 16:28 |
| slaweq | I updated stats, generally gates aren't very stable as we discussed already | 16:28 |
| gmann | yeah | 16:28 |
| slaweq | and it is visible in number of rechecks needed to merge patches | 16:28 |
| slaweq | nothing else except that | 16:28 |
| gmann | ok. thanks for updating | 16:29 |
| gmann | #topic Open Reviews | 16:29 |
| gmann | #link https://review.opendev.org/q/projects:openstack/governance+is:open | 16:29 |
| gmann | 6 open reviews out of which 3 are ready to review | 16:29 |
| gmann | #link https://review.opendev.org/c/openstack/governance/+/872232 | 16:29 |
| gmann | #link https://review.opendev.org/c/openstack/governance/+/872233 | 16:29 |
| gmann | this is new one #link https://review.opendev.org/c/openstack/governance/+/872769 | 16:29 |
| gmann | slaweq I will check it today, opened it in tab | 16:30 |
| gmann | others are waiting for their dependency to merge first | 16:30 |
| slaweq | thx | 16:30 |
| gmann | that is all on open reviews | 16:30 |
| gmann | two things more from my side | 16:30 |
| gmann | 1. elections: nomination are open. tc members whos term are completing in this election and thinking to re-run, please check nomination deadline | 16:31 |
| gmann | also encourage other members to run even TC or PTL for your known projects. deadline for nomination is Feb 15, 2023 23:45 UTC | 16:32 |
| slaweq | ++ | 16:32 |
| knikolla[m] | time flies | 16:33 |
| gmann | yeah :) | 16:33 |
| gmann | 2. open infra Board syncup call today at 20 UTC details are mentioned in #link https://etherpad.opendev.org/p/2023-02-board-openstack-sync | 16:33 |
| gmann | which is zoom call in 3hr 30 min from now | 16:33 |
| gmann | please plan to attend or feel free to add topics to discussed in etherpad | 16:34 |
| gmann | that is all from agenda and me for today. we have ~26 min left if anything else to discuss from anyone ? | 16:34 |
| slaweq | ot | 16:34 |
| slaweq | it's pretty late for me but I will try to be | 16:34 |
| gmann | ack | 16:34 |
| noonedeadpunk | btw, should we somehow start tracking how projects are progressing with adding upgrade jobs for N-2? | 16:35 |
| gmann | noonedeadpunk: good point, we do have grenade-skip job which we will update on release and if I am not wrong that will be added in integrated gate template | 16:36 |
| gmann | but that is only for 4-5 projects. and manila does too. but i agree it will be good to ask other projects to do so and track that | 16:36 |
| gmann | ~16 projects have the greande plugin and should add the skip level testing #link https://docs.openstack.org/grenade/latest/plugin-registry.html | 16:37 |
| noonedeadpunk | As while it's matter of practise for SLURP upgrades, I think we'd better have things and mindset in place sooner then later | 16:37 |
| gmann | yeah | 16:38 |
| dansmith | gmann: how many have it voting? | 16:38 |
| gmann | dansmith: good question. I have not checked that but yes many of them might be non voting | 16:39 |
| dansmith | AFAIK, pretty much everyone should have it voting in current master right? | 16:39 |
| gmann | yes | 16:39 |
| slaweq | You mean skip-level job voting? | 16:39 |
| dansmith | yes | 16:39 |
| noonedeadpunk | But does everyone have grenade-skip in some default template? | 16:39 |
| gmann | noonedeadpunk: not for this cycle as this is non-SLURP | 16:40 |
| dansmith | wait what? | 16:40 |
| gmann | those run only for SLURP releases. | 16:40 |
| slaweq | I though that we agreed to have them non-voting for now as it will be just first SLURP release now | 16:40 |
| dansmith | 2023.1 is a slurp no? | 16:40 |
| slaweq | 2023.1 will be first slurp | 16:40 |
| slaweq | yes | 16:40 |
| rosmaita | yes, but in the forward direction | 16:40 |
| noonedeadpunk | Well, it's first slurp. so it's indeed can be non-voting | 16:40 |
| gmann | dansmith: i mean the first immediate SLUPR after 2023.1 | 16:40 |
| noonedeadpunk | But already running at least? | 16:40 |
| dansmith | oh you mean because it's the first, right right | 16:40 |
| gmann | in 2023.1 it is non voting yes as we discussed, but in 2023.3 it should be voting | 16:41 |
| dansmith | ack, but opt-in to voting for 2023.1 would be good if the project can swing it | 16:41 |
| gmann | 2024.1 | 16:41 |
| slaweq | so in neutron we have neutron-ovs-grenade-multinode-skip-level and neutron-ovn-grenade-multinode-skip-level jobs but those are non-voting for now | 16:41 |
| gmann | in 2023.2 it will not run. in 2024.1 it should be voting | 16:41 |
| dansmith | yep, I keep thinking this is the first upgradeable-to but it's really the first upgradeable-from...I'm on the page now :) | 16:42 |
| noonedeadpunk | I don't see them in heat at least https://opendev.org/openstack/heat/src/branch/master/.zuul.yaml#L185-L202 | 16:42 |
| gmann | I think we have updated our PTI document also for that but not every project knowing that | 16:42 |
| noonedeadpunk | Unless it's part of some template | 16:42 |
| noonedeadpunk | dansmith: I think it's unofficial upgradable-to as well, as a matter of practise? | 16:42 |
| gmann | noonedeadpunk: if I remember, except manila and grenade in-tree projects, I do not think any one else staretd | 16:43 |
| dansmith | noonedeadpunk: just not required yeah | 16:43 |
| gmann | so this is for 2024.1 and something we can start in next cycle to ask projects to prepare those jobs and rn | 16:43 |
| gmann | run | 16:43 |
| noonedeadpunk | ok, maybe worth writing some ML to encourage projects in doing so? | 16:43 |
| gmann | +1 | 16:44 |
| noonedeadpunk | ok | 16:44 |
| gmann | no harm to do that | 16:44 |
| dansmith | yeah, running it for everyone, encouraging projects to opt-in to voting now would be best, IMHO | 16:44 |
| gmann | sure | 16:44 |
| dansmith | meaning non-voting in the template | 16:44 |
| gmann | let me put the data in etherpad about what all project need to add and then I can send it on ML to ask projects | 16:45 |
| slaweq | maybe we should talk with release team so they can add info about it in their weekly emails about releases? To remind projects e.g. to remove those jobs from gate in 2023.2 cycle | 16:45 |
| gmann | #action gmann to prepare etherpad for grenade skip upgrade job data and send email asking required projects to add job | 16:46 |
| gmann | slaweq: that also work and even I can add it in my weekly summary too | 16:46 |
| gmann | once 2023.2 start | 16:46 |
| slaweq | gmann++ thx | 16:47 |
| gmann | noonedeadpunk: thanks, good reminder. | 16:47 |
| gmann | anything else for today? | 16:47 |
| spotz | not from me | 16:47 |
| gmann | ok, let's close then. thanks everyone for joining. | 16:48 |
| gmann | #endmeeting | 16:48 |
| opendevmeet | Meeting ended Wed Feb 8 16:48:36 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:48 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-08-16.00.html | 16:48 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-08-16.00.txt | 16:48 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-02-08-16.00.log.html | 16:48 |
| slaweq | o/ | 16:48 |
| spotz | o/ | 16:49 |
| clarkb | oh I wanted to call attention to ianw's email about gerrit acls | 16:50 |
| clarkb | Basically gerrit 3.6 (the version we are running on) is the transition version between label functions and submit requirements in gerrit acls. ianw has a change up to begin converting these in our acls | 16:50 |
| clarkb | we believe the change to be a 1:1 mapping but openstack uses this heavily for things like backport candidates and review priority so be on the lookout for behavior changes after that merges | 16:51 |
| clarkb | https://review.opendev.org/c/openstack/project-config/+/867931 is the change | 16:51 |
| clarkb | this doesn't actually change the functions yet just the copy conditions, so there will be an iterative process as we convert each little aspect of this | 16:52 |
| noonedeadpunk | btw about that email - it was the time I realised we do have dash-creator. As we currently are using manually create dashboard that's not commited anywhere | 16:52 |
| clarkb | we should probably also try to get around to enabling hashtags globally since a lot of this could be addressed by hashtags I think | 16:54 |
| clarkb | backport candidates in particular come to mind | 16:54 |
| clarkb | re timeouts one thing to check is swap use | 16:55 |
| noonedeadpunk | well. it's a bit tricky, as making a typo in hashtag will lead to missing patch from the dashboard | 16:56 |
| clarkb | in the past it has correlated well to jobs suddenly being slow. Particularly on providers that don't have high iops | 16:56 |
| clarkb | additionally we can be our own noisy neighbors. | 16:56 |
| clarkb | Having a bunch of jobs all swapping on the same host is unlikely to be good for performance of the jobs running there | 16:57 |
| noonedeadpunk | so label in that sense is protecting from stupid mistkaes | 16:57 |
| clarkb | noonedeadpunk: ya thats fair, I personally don't mind how ya'll do it, just want to ensure you have options | 16:57 |
| JayF | clarkb: we explicitly wanted votes over tags for BC so you can BC-1 | 17:01 |
| fungi | also labels allow for per-reviewer feedback while tags are effectively shared | 17:04 |
| opendevreview | Amy Marrich proposed openstack/election master: Amy Marrich TC candidacy https://review.opendev.org/c/openstack/election/+/873160 | 17:27 |
| fungi | tc-members: please see https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032083.html "Last maintained release of TripleO is Wallaby" since it contains a governance question | 17:52 |
| noonedeadpunk | I assume it's project deprecation, isn't it? | 17:56 |
| gmann | yes, deprecation case and then retire once last maintained rlease is EOL | 17:57 |
| noonedeadpunk | when master and futher development is stopped, and stable branches are still maintained. Though I'm not sure how to deal with Zed if it was branched... Likely it can be EOLed, but it's quite weird from governance prespective indeed | 17:58 |
| fungi | noonedeadpunk: the governance question is one of ptl elections | 17:58 |
| fungi | see the last paragraph | 17:58 |
| noonedeadpunk | Yeah, ok, there were 2 questions then I guess :) | 17:59 |
| fungi | though on rereading, i guess the question is on how to deprecate new development, and not about leadership. so yeah, a pointer to the deprecation process could be in order | 18:00 |
| noonedeadpunk | I'd say no PTL is needed for maintain deprecated project | 18:00 |
| fungi | he does at least say that they'd nominate someone to act as ptl if required, so a semi-question i suppose | 18:00 |
| gmann | well they can have PTL as they maintain on stable release and still in governance | 18:01 |
| gmann | replying with the deprecation process and still they can propose for PTL | 18:01 |
| noonedeadpunk | I'm not sure if they have stable-maint-core as a separate group? | 18:01 |
| fungi | seems like dpl could work, they're planning to handle stable branch testing and security fixes, which means liaisons for infra and security could be warranted, not sure if they issue point releases from their stable branches | 18:01 |
| noonedeadpunk | though I don't think PTL is a requirement | 18:01 |
| noonedeadpunk | yeah, exactly was thinking about dpl | 18:02 |
| gmann | yeah, dpl can be option too but honestly saying it is same thing for them if 1 person listed as DPL liaison or PTL | 18:03 |
| fungi | right. if they want to spread those roles around then dpl could makes sense | 18:03 |
| gmann | but until project is in governance even though deprecated we should have some point of contact | 18:03 |
| gmann | sure | 18:04 |
| fungi | anyway, just wanted to call that post out since it's a pretty significant change in course for a long-time official project team, and they didn't add [tc] in the subject so it could have gone unnoticed | 18:04 |
| dansmith | seems kinda weird to sort of abandon an existing should-be-supported release right? | 18:07 |
| dansmith | I mean, I'm guessing it's true that there would be few objections, but...that's a bit odd, no? | 18:07 |
| gmann | but it was not release at all after wallaby which is not caught? | 18:09 |
| fungi | i thought they announced a while back that they weren't going to make releases of tripleo every cycle and were consciously tying them to rdo releases which have a different cycle driven by rh's downstream support decisions | 18:09 |
| dansmith | okay, so there have been no releases since wallaby but there are named release branches? | 18:10 |
| fungi | probably worth asking their team though, rather than speculating here | 18:10 |
| clarkb | the email does imply zed was maintained though | 18:10 |
| clarkb | but ya I'm not sure at what level | 18:10 |
| dansmith | they say "zed release" in the mail | 18:10 |
| dansmith | right | 18:10 |
| gmann | there releases are not marked as deprecated yet | 18:10 |
| dansmith | "empty commit those branches" seems a bit drastic to me | 18:10 |
| gmann | yeah that was confusing. it is strange that releases were missed ? | 18:11 |
| dansmith | why do you say missed? | 18:12 |
| dansmith | but this says only wallaby: https://releases.openstack.org/teams/tripleo.html | 18:12 |
| gmann | dansmith: I mean xena, yoga, zed rleased are missed right as it is not yet deprecated | 18:13 |
| gmann | deprecation process/question should be in xena release itself | 18:13 |
| noonedeadpunk | they do have Zed branch | 18:13 |
| noonedeadpunk | https://opendev.org/openstack/tripleo-common/src/branch/stable/zed | 18:13 |
| gmann | yeah, that is another strange, wallaby and then directly zed they have not deprecated it yet so | 18:14 |
| dansmith | they have branches, they refer to "zed release" in their email, but yeah I don't see any releases on that page past wallaby | 18:14 |
| dansmith | so I'm confused | 18:14 |
| gmann | yes | 18:14 |
| noonedeadpunk | They were targeting to skip couple of releases to catch up with refactoring or smth IIRC | 18:14 |
| dansmith | gmann: are you talking about deprecating the *project*? | 18:14 |
| gmann | https://github.com/openstack/tripleo-common/branches | 18:14 |
| * noonedeadpunk was talkign about deprecating project at least | 18:14 | |
| gmann | dansmith: yes, they are not marked as deprecated or release-deprecated means they are supposed to do release | 18:15 |
| dansmith | yeah, I thought they were moving to release-independent though | 18:15 |
| gmann | release team monitor that i think if anyone missed release then they propose to mark it release management None or deprecate release | 18:15 |
| noonedeadpunk | I do recall their ML in W though when they said - we're gonna skip couple of releases but will do Z or Y iirc | 18:15 |
| noonedeadpunk | Not sure I will be able t ofind that quickly though | 18:15 |
| gmann | ohk | 18:15 |
| dansmith | yeah, something | 18:15 |
| gmann | elodilles: ^^ you know about tripleO release skipping for xena, yoga, and zed also? | 18:16 |
| dansmith | but still... they say "zed release" in the email, and even if the branches weren't released, it seems odd to destroy them, which is what they're implying I think | 18:16 |
| noonedeadpunk | I'm not sure they've skipped Z? | 18:16 |
| dansmith | maybe they just meant "zed branch" | 18:16 |
| noonedeadpunk | yeah, dunno... | 18:16 |
| gmann | I cannot find it here https://releases.openstack.org/zed/index.html | 18:16 |
| gmann | yeah, may be zed branch not release | 18:17 |
| noonedeadpunk | well 18.0.0 tag seem to reffer zed | 18:17 |
| noonedeadpunk | or it's even master.... | 18:18 |
| gmann | ah, here it is independent releases https://github.com/openstack/releases/blob/3bef29d74c7be4a834518e3b01dd7ee20c79a22e/deliverables/_independent/tripleo-common.yaml | 18:20 |
| gmann | 17.0.0 was cut as stable/zed | 18:20 |
| dansmith | so there are releases after wallaby, | 18:20 |
| dansmith | but they don't show up on the releases page | 18:20 |
| noonedeadpunk | looks quite messy... | 18:21 |
| gmann | yeah. it should show there even it is independent | 18:21 |
| gmann | but yes all seems messy | 18:21 |
| gmann | ah, we have that in independent so release page is all good https://releases.openstack.org/independent.html#tripleo-common | 18:22 |
| dansmith | okay weird | 18:23 |
| gmann | so after 15.0.0 (stable/wallaby) it is kind of no stable branch things/backport support but they do have new releases | 18:24 |
| dansmith | are they expected to support those releases? I would expect so | 18:24 |
| dansmith | at least not delete the branch before EOL | 18:24 |
| dansmith | if they're not around to support them, then we can't expect them to, but I guess if they're supporting wallaby, it seems uncool to change the support envelope of releases after that | 18:25 |
| noonedeadpunk | I think main question is what we're supposed to do with branched (and likely tagged) Zed? | 18:25 |
| noonedeadpunk | Yes, exactly | 18:25 |
| dansmith | noonedeadpunk: well, the email said they would "empty commit those branches", which to me means leave them up so they're find-able, but effectively destroy (as much as could happen in git) them to avoid people running or packaging those right? | 18:26 |
| gmann | well, we do not have stable branch support as governance requirement right? but agree that we should have somewhere marking that project-supporiting-branch now stopped supporting it | 18:26 |
| noonedeadpunk | oh, don't we? As I thought release cadence and supporting stable releases is kind of requirement... | 18:27 |
| dansmith | gmann: we do *not* have stable branch support as a requirement? meaning for independent releases or what? | 18:27 |
| dansmith | yeah me too | 18:27 |
| fungi | "destroy" is a bit strong, but yes break them sufficiently that people will hopefully spot the readme file in them that says what's happened | 18:27 |
| gmann | independent releases, branchless repo are example of no stable branch right | 18:27 |
| dansmith | fungi: yeah I said "as much as could happen in git | 18:27 |
| fungi | they can always grab HEAD^1 if they need it | 18:27 |
| dansmith | fungi: doing that seems not very constructive though.. a final commit in the readme or something, maybe | 18:27 |
| noonedeadpunk | To be frank, I'd vote to mark zed as EOL for this specific project rather then empty it.... | 18:28 |
| dansmith | gmann: okay IDK, I thought releases need to be supported | 18:28 |
| dansmith | noonedeadpunk: ++ | 18:28 |
| noonedeadpunk | +1 ^ | 18:28 |
| gmann | agree on marking zed EOL that is confusing | 18:28 |
| mnaser | wow, tripleo winding down | 18:29 |
| gmann | dansmith: release needs to be supported but cutting stable branches are not | 18:29 |
| dansmith | it's also weird to have releases after the last supported one be EOL but the last supported one not | 18:29 |
| dansmith | gmann: ack, but they were released right? | 18:29 |
| mnaser | i'm curious what the different deployment approach is | 18:29 |
| gmann | dansmith: yeah | 18:29 |
| gmann | dansmith: noonedeadpunk: I think EOL/remove zed and mark it deprecated after stable/wallaby? or may be after tag 18.0.0 | 18:30 |
| noonedeadpunk | mnaser: I've heard from folks they've invested time/resources into deploying openstack in k8s, but that info is not 100% | 18:30 |
| mnaser | ah, i've never heard of anyone thinking of doing that before 👀 | 18:31 |
| dansmith | gmann: I'm not sure what you mean | 18:31 |
| dansmith | gmann: you mean mark everything post-W as EOL? | 18:31 |
| dansmith | deleting releases doesn't sound very good to me | 18:31 |
| gmann | dansmith: not deleting. marking deprecated after 'tag 18.0.0' which is last release. deprecating after stable/wallaby does not seems right | 18:32 |
| gmann | I think this is first case of deprecation for independent release model so taking last release tag seems right way | 18:33 |
| dansmith | gmann: okay, still confused | 18:33 |
| gmann | :) | 18:33 |
| noonedeadpunk | I'm not sure how you can mark everything after some tag as deprecated? | 18:34 |
| gmann | you mean how to support last tag release as we cannot backport? | 18:34 |
| noonedeadpunk | As I guess you can deprecate only current HEAD, as you need to drop content from it first | 18:34 |
| gmann | ohk, so i mean to record in governance about what is last supported for this deprecation | 18:35 |
| gmann | here https://github.com/openstack/governance/blob/master/reference/projects.yaml#L809 | 18:35 |
| noonedeadpunk | actually you also mae a good point about tag that can't be supported anymore... | 18:35 |
| gmann | so we know when to retire the project | 18:35 |
| noonedeadpunk | ok, yeah, gotcha | 18:36 |
| gmann | it is confusing by saying stable/wallaby is last supported but hey we do have newer release than stable/wallaby :) | 18:36 |
| dansmith | well, that would be okay if nothing past wallaby was released, | 18:37 |
| noonedeadpunk | Once we sort this out - we should likely do lessons learned from that to cover gaps that allowed this to happen... | 18:37 |
| dansmith | but since there were, I'm not sure how you can go back on previous promises/releases | 18:37 |
| gmann | noonedeadpunk: yeah, this is something needs to cover when projects moving 'from branched to independent release' what is needed in governance | 18:38 |
| noonedeadpunk | make another tag on the same SHA as already released one saying EOL-18.0.0 ? | 18:38 |
| gmann | dansmith: yeah | 18:39 |
| noonedeadpunk | Not sure how that will help, but at least some indication that smth is wrong with this | 18:39 |
| gmann | but if we see from 'support' perspective stable/wallaby is the only branch they can support. so may be we just ignore the releases after stable/wallaby ? | 18:40 |
| noonedeadpunk | I mean - we can ignore a lot of things. But we should make it also clear for operators and users that this project died way before they think it did | 18:40 |
| gmann | humm | 18:41 |
| gmann | can we move wallaby-em to 18.0.0 hash and that way we can say stable/wallaby last release as their last release and supported | 18:42 |
| dansmith | noonedeadpunk: that may be the reality, but anyone who has packaged this needs a bit more than that I think | 18:42 |
| dansmith | gmann: wouldn't that involve a regression of, for example, the requirements.txt etc | 18:42 |
| dansmith | ? | 18:42 |
| noonedeadpunk | I'm not sure it was ever packaged? | 18:42 |
| gmann | dansmith: right, it may. most probably it will | 18:43 |
| dansmith | noonedeadpunk: you don't know | 18:43 |
| dansmith | looks like there were at least some packages in ubuntu at some point | 18:44 |
| dansmith | agreed, not likely widespread, but if we do it now for this, some other project could expect the same | 18:45 |
| noonedeadpunk | well. another option is likely to say our no on EOLing or emptying Zed branch allowing for rest of community to pick up it's maintenance if needed | 18:48 |
| fungi | basically treat those branches as if they're in extended maintenance state early? | 18:48 |
| dansmith | I definitely think we should ask for not emptying the branches | 18:48 |
| noonedeadpunk | Yeah | 18:48 |
| JayF | We don't have a lot of leverage here, even as technical leadership, unless we are going to provide technical support for keeping CI running and the like, yeah? I don't understand the value of leaving EM branches open if the community around them doesn't exist anymore | 18:49 |
| fungi | from a governance perspective, you've got the current maintainers saying they're no longer able to continue development on the project, so from the tc's perspective you could i suppose hope someone else offers to take it over | 18:49 |
| noonedeadpunk | ^ yes, exactly | 18:50 |
| JayF | I don't see a large queue of contributors itching to contribute to it | 18:50 |
| dansmith | nobody is going to take it over, but I don't see why that has anything to do with not *emptying* branches that already exist | 18:50 |
| dansmith | for releases that are supposed to have timelines attached to them | 18:50 |
| noonedeadpunk | Well. We're already in situation, where they're going to maintain only N-1 release basically, but not N. And I hate this specific aspect of that | 18:51 |
| JayF | Supposed to really is the key word though; becuase we can't do anything to enforce that tripleo follow this timeline; if the contributors are gone the project is gone, right? | 18:51 |
| gmann | yeah, let's go that way. mark it deprecated, keep zed as it is (for already release versions or in case anyone want to un-deprecate and maintain it), retire when stable/wallaby is EOL | 18:51 |
| JayF | I don't love it, but I think we might be better off just "ripping the band-aid off" | 18:51 |
| dansmith | noonedeadpunk: right, the other weird thing is, maintenance of W creates regressions in the W+n release branches too | 18:52 |
| noonedeadpunk | It's open development after all ;) | 18:52 |
| gmann | and later we can document the process to better handle such cases | 18:52 |
| dansmith | gmann: you mean deprecate X, Y, and Z correct? | 18:54 |
| gmann | dansmith: there is no X, Y right only Z and we can keep Z as it is with master README.rst mentioning about 'this project maintenance is not supported after wallaby' | 18:56 |
| dansmith | gmann: there are numbers between 14 and 17 in the releases thing right? | 18:57 |
| gmann | yeah but we cannot do anything about those, keeping zed open is the way if someone want to pick/maintain it after 18.0.0 (last release) | 18:57 |
| gmann | or from stable/wallaby | 18:58 |
| dansmith | you mean the only open *branch* since wallaby is zed? | 18:58 |
| gmann | yes | 18:58 |
| gmann | dansmith: https://github.com/openstack/tripleo-common/branches | 18:58 |
| dansmith | right, so that makes sense, but I guess it seems like the "lifetime" of the releases between W and Z have now changed | 18:58 |
| dansmith | probably doesn't matter that much I guess, but... | 18:59 |
| gmann | yeah, we cannot do anything on that now | 18:59 |
| gmann | its very weird situation | 18:59 |
| noonedeadpunk | Yeah, I'd say that keeping Zed open is likely by far best choice even if we know it will be broken and quite unmaintained. As I assume there might be ppl who used 18.0.0 and will appear one day to step in to maintain these | 19:01 |
| gmann | yeah | 19:02 |
| noonedeadpunk | At least we shouldn't shut the door until Zed will move to EM, where it can be instantly EOLed | 19:02 |
| dansmith | I guess I'm still confused on the expected support envelope of the intermediate releases on an independent project | 19:02 |
| dansmith | is it not expected to be 18ish months in the same way as our coordinated releases? | 19:02 |
| noonedeadpunk | I'd say confusing thing is that they have independent release cycle but releases named same way as coordinated ones | 19:03 |
| gmann | dansmith: if it is completely independent model project then there is no 'deprecation' it is directly 'retirement' as there is no stable branches there to keep support for | 19:03 |
| gmann | openstack-health project is example of that which we recently retired | 19:03 |
| dansmith | noonedeadpunk: yeah | 19:04 |
| noonedeadpunk | So it's some mix of both worlds that exists by moving to independent and then somehow branching zed... | 19:04 |
| dansmith | gmann: I mean for the releases, not the project | 19:04 |
| gmann | 'deprecation' is only for those who do support old release via stable branhces | 19:04 |
| dansmith | gmann: okay I guess i don't get it.. most consumers care about releases, not so much the branches that back the releases, | 19:04 |
| gmann | yeah, here situation is weird that it is mix of coordinated and independent release | 19:04 |
| dansmith | so I think they expect support for the 17.x lineage not "does the 17.x have a stable/foo branch?" | 19:05 |
| noonedeadpunk | dansmith: I don't think they can support 17.x without stable/foo | 19:05 |
| gmann | yeah how they will support tag only releases | 19:06 |
| dansmith | noonedeadpunk: I'm talking about what consumers expect | 19:06 |
| gmann | means they cannot backport right | 19:06 |
| noonedeadpunk | ah, yes | 19:06 |
| gmann | ohk | 19:06 |
| dansmith | i.e. people that deploy a release (from a tarball or package) do not first go look to see if there's a stable/foo branch backing it and then extrapolate the support envelope from that | 19:06 |
| gmann | I will say support for them is to fix and release new tag | 19:06 |
| gmann | same as any PyPi release? | 19:07 |
| dansmith | gmann: to be clear, I'm not talking about tripleo specifically here, I'm talking about what consumers of "openstack project foo" have in the way of expectations for *any* release they get from "us" | 19:07 |
| JayF | That cat is already out of the bag | 19:07 |
| JayF | we explicitly have a list of OpenStack projects that opt-in to stable processes | 19:08 |
| JayF | there is no clear way for an operator to know how long a given openstack deliverable will be supported without navigating documentation | 19:08 |
| dansmith | that's my point, I'm trying to say that I'm not sure what the expectation is for tripleo 17.x support | 19:09 |
| noonedeadpunk | dansmith: well. quite a few consumers prefer to track branch and not tags. | 19:09 |
| dansmith | (in a world where anyone other than redhat customers are running tripleo) | 19:09 |
| gmann | dansmith: may be I am also confused with 'support':) for any released software what is mean of 'support' for that release - backport things right? | 19:09 |
| noonedeadpunk | so it's not really black and white | 19:09 |
| gmann | if they are thinking of support, it needs to be with backport branches | 19:10 |
| noonedeadpunk | gmann: not only backport, but fixing at least security issues | 19:10 |
| gmann | yeah | 19:10 |
| dansmith | gmann: yes, I'm saying the current way we have releases, someone may be expecting that grabbing a release from an independent project could *ever* get a bug or CVE fix, but that's probably a bad assumption from just looking at the releases page and seeing releases with semver-ish version numbers | 19:10 |
| gmann | for example, fix bugx for me and do not give me all new things | 19:10 |
| noonedeadpunk | so if just 18.x contains vulnarabiltiy -- there should be the way to cover it | 19:11 |
| dansmith | noonedeadpunk: right, and it sounds like there isn't currently because there's no branch for those | 19:11 |
| gmann | dansmith: yes, from release page it is not clear | 19:11 |
| gmann | we should mark explicitly 'not supported/no-bug-fix for this release and only new releases' for independent releases | 19:12 |
| dansmith | gmann: yeah I guess I'm saying, it seems like we maybe need some indication of what to expect | 19:13 |
| dansmith | on a project that does coordinated releases and stable branches, it's pretty clear | 19:13 |
| TheJulia | dansmith: and creation of branches after the fact where applicable/needed has also been frowned upon/outright rejected where it came up and was needed, which is what helped spur bugfix branching to become a thing in ironic | 19:13 |
| JayF | Or even defer to project policy in some cases? I wonder how that kind of verbiage would interact with ironic bugfix releases | 19:13 |
| gmann | dansmith: yeah. that is clearly needed | 19:13 |
| dansmith | but for anyone not in that bucket, it probably isn't | 19:13 |
| JayF | which also live in a weird intermediate place | 19:13 |
| dansmith | TheJulia: ack, but how do you make sure you're applying bug fix 27 on top of bug fix 26? I mean, I understand the mechanics of it, I'm just saying, I can see it being confusing | 19:14 |
| JayF | it is confusing, and we fix it with documentation and folks who approve our stable stuff knowing bugfix branches exist | 19:15 |
| TheJulia | dansmith: and time consuming, and not *always* needed. It is situational unfortunately | 19:15 |
| dansmith | yeah | 19:15 |
| JayF | I think I cleaned up some of that confusion this cycle by retiring old ironic bugfix branches + changing policy to be more judicious about when we cut them | 19:15 |
| TheJulia | yes, cleaning things up unfortunately is an easy thing to let slip | 19:16 |
| dansmith | relying on brute force and some stable maintainers to be sure you're not releasing a bugfix that regresses another because you had the order wrong in your head though is kinda unfortunate.. obviously if you're super good and never go outside near busses, then it works :) | 19:17 |
| JayF | I mean, honestly it goes back to the heart of the tripleo discussion | 19:17 |
| gmann | so here is no mention of 'maintained/supported' for independent releases. may be adding 'Status' as 'not maintained' or soemthing https://releases.openstack.org/independent.html | 19:17 |
| JayF | a project is not code; it is the people who work on it | 19:18 |
| JayF | I'd love to have the problem of Ironic having so many contributors that bugfix branches got to be an issue | 19:18 |
| TheJulia | +++++++++ project == people | 19:18 |
| JayF | but that's not the spot that we're at now; so I prefer to solve problems that do exist rather than ones that may :/ | 19:18 |
| noonedeadpunk | It's also people who consume it - let's not forget about thouse | 19:18 |
| noonedeadpunk | And consumers can convert to maintainers. I don't say they will, but they can | 19:18 |
| dansmith | noonedeadpunk: yeah, thanks for saying that | 19:19 |
| TheJulia | ++ | 19:19 |
| dansmith | and the rest of openstack is on the hook for the consumers, IMHO, especially if we stop being responsible in our support policies for one project and that reflects on the others | 19:19 |
| TheJulia | sometimes it also takes such an announcement to get people to think "maybe I should" | 19:19 |
| JayF | TheJulia++ | 19:19 |
| JayF | and honestly, if I were to stack rank concerns people have when I try to sell them on openstack "stable support" never even gets on the list :/ | 19:20 |
| noonedeadpunk | yes, I agree we should try to avoid creating nasty precedent | 19:20 |
| TheJulia | we can ask/advocate/beg for help, but until there is pain, sometimes people won't do anything when they see others involved | 19:20 |
| JayF | we've seen that in PTL elections almost every cycle as of late | 19:20 |
| JayF | nobody wants to be a PTL until there is no PTL | 19:20 |
| JayF | similar thing here, I guess, I'm coming around to the more popular opinion of leaving zed open for tripleo | 19:20 |
| * fungi doesn't want to be ptl ;) | 19:21 | |
| JayF | because we are providing the "stick" of the carrot-and-stick to get people outta downstream and contributing back | 19:21 |
| fungi | (at least not again) | 19:21 |
| gmann | so on triplo discussion | 19:21 |
| gmann | yeah keeping zed open | 19:21 |
| TheJulia | So... different discussion, perhaps for in 39 minutes, "what thoughts or patterns might help encourage people to want to serve in those roles?" | 19:21 |
| dansmith | JayF: that's funny, the biggest thing I hear is "we want to be on release X forever and keep getting backports" | 19:21 |
| gmann | anything we need to discuss with them or in ML thread other then let them proposed as deprecation and we will mark it as stble/wallaby but keep zed opne ? | 19:22 |
| JayF | TheJulia: that's already on the agenda :) | 19:22 |
| TheJulia | Oh, somebody needs to take notes on that call. I'm limited bandwidth and will be dialed in to start it | 19:22 |
| TheJulia | \o/ | 19:22 |
| JayF | dansmith: fair; I filtered those kinds of opinions out because that wish is ... hardly unique to openstack... and doesn't really acknowledge the reality of the environments changing around us (even if our software is 'stable') | 19:23 |
| dansmith | um, okay :) | 19:23 |
| TheJulia | And the rate of evolution/change is forever moving faster | 19:23 |
| JayF | dansmith: I am extremely happy to have a deeper version of this conversation later; I'm really interested in it. | 19:24 |
| JayF | but now, I need to get lunch before the meeting | 19:24 |
| TheJulia | ++++ food | 19:24 |
| noonedeadpunk | dansmith: to be frank, as of today I don't feel huge difference of doing minor openstack upgrade comparing to the major one | 19:24 |
| fungi | yes, everyone wants to be on a stable version of teh software forever except get new features too, but somehow without it breaking anything they rely on | 19:24 |
| TheJulia | fungi: exactly :( | 19:24 |
| * JayF ==fungi | 19:24 | |
| gmann | I am adding it it PTG etherpad to discuss it further and give more thought | 19:24 |
| noonedeadpunk | It's close to same thing I've heard quite a lot recently, like "I've tried openstack 10 years ago - it was hard and it's still hard, so nothing has changed" | 19:25 |
| TheJulia | "hi, I would like big giant new feature in your minor patchlevel release!" *sigh* | 19:25 |
| fungi | basically everyone wants fewer bugs, and they equate that to not making new releases | 19:25 |
| fungi | the releases aren't the problem though | 19:25 |
| TheJulia | consumption side problem? | 19:26 |
| fungi | it's a conflicting desire to want things to not change but wanting them to get better | 19:26 |
| TheJulia | indeed | 19:26 |
| fungi | and you can't make the software better without changing it in some way. you can either have software which doesn't change and so never gets better, or software which gets better over time but necessarily changes to make that happen | 19:27 |
| TheJulia | and in that, sometimes steps must be taken, decision points exist, understanding is sometimes needed to appropriately navigate that | 19:28 |
| TheJulia | which is challenging in an age where people yearn for simple/easy | 19:28 |
| noonedeadpunk | People always want simple solutions to their complex usecases... | 19:31 |
| TheJulia | yup | 19:31 |
| TheJulia | That is not just limited to use cases, but perceptions | 19:31 |
| noonedeadpunk | yes, totally | 19:32 |
| TheJulia | and often, they are the best person to advocate for that change when they don't want to be | 19:32 |
| TheJulia | since they are best suited to make the case and advocate/convince | 19:32 |
| * TheJulia will happily discuss this on the call soon | 19:32 | |
| gmann | added 'support' things discussion in PTG etherpad, feel free to reword it as I might not have phrased it well (as still no coffee for me yet ) https://etherpad.opendev.org/p/tc-2023-2-ptg#L50 | 19:42 |
| noonedeadpunk | should we hold tripleo folks from cleaning out stable/zed until the next week at least? | 19:44 |
| elodilles | oh, i see here kind of a long discussion :) | 19:46 |
| elodilles | gmann: i did not remember that tripleo is not releasing after wallaby, | 19:47 |
| elodilles | gmann: though tripleo was always a 'special' project | 19:47 |
| elodilles | gmann: only maintained by RH folks, so basically almost a pure RH project | 19:47 |
| elodilles | gmann: and yes, they had some special handling, like they chose to close ussuri and victoria branches (EOL), while keeping train and wallaby in EM | 19:48 |
| noonedeadpunk | hm... what about moving it to X namespace then? | 19:48 |
| elodilles | gmann: since wallaby they changed release model to 'independent' | 19:49 |
| noonedeadpunk | elodilles: the problem they've branched stable/zed but don't want to maintain it anymore but keep wallaby | 19:49 |
| gmann | noonedeadpunk: we should move it to x/ only if anyone interested to maintain there | 19:49 |
| noonedeadpunk | well. they're interested to maintain wallaby :) | 19:49 |
| gmann | elodilles: ok. close ussuri and victoria branches (EOL), while keeping train is another different thing here | 19:50 |
| elodilles | gmann: which means they can release from the tip of the branch anytime, cut branches (like they did with stable/zed - i was surprised first, that this is possible, but we had examples in the past), but *NO* release is possible from those branches | 19:50 |
| fungi | also the tc enacted a policy that you can't "move" a project out of openstack. for awareness of downstream consumers it has to be retired in openstack and then forked to begin development elsewhere outside openstack | 19:50 |
| fungi | because that's a clear signal to everyone that the project is no longer under the governance and policies of the openstack project | 19:51 |
| noonedeadpunk | makes sense | 19:51 |
| gmann | noonedeadpunk: It seems we did not clear agreement here even tc-members discussed here agree on keeping stable/zed open. let me add this in next week meeting agenda and ask tripleo on ML to hold the stable/zed things till we get official agreement in governance | 19:51 |
| noonedeadpunk | ++ | 19:51 |
| elodilles | noonedeadpunk: as soon as they cut a branch in independent release model, it's the team responsibility to maintain / delete those branches (just what happened with ironic's many 'bugfix/*' branches) | 19:52 |
| noonedeadpunk | elodilles: it's is akwardly confusing when independent project cuts a branch with coordinated name | 19:52 |
| gmann | elodilles: but branch with independent release model end up in weird situation or at least many process about 'support', 'deprecation/retirement' are not covered for that cases | 19:53 |
| noonedeadpunk | so as a user you don't really know much about what release model some project at very least | 19:53 |
| gmann | noonedeadpunk: yeah, that one | 19:53 |
| dansmith | exactly | 19:53 |
| JayF | honestly saying "don't make indepedendent releases with the same name as the coordinated release" seems like it'd be reasonable policy | 19:53 |
| noonedeadpunk | ++ | 19:54 |
| gmann | any ways that is something we can discuss in PTG and find some better process on release as well as governance perspective | 19:54 |
| bauzas | from what I see, there are other contributors but Red Hat who express interest in TripleO development on stable/zed https://www.stackalytics.io/?release=zed&module=tripleo-group | 19:54 |
| gmann | JayF: ++ | 19:54 |
| elodilles | JayF: ++ | 19:54 |
| bauzas | I'm not 100% sure they'll appreciate an empty commit on stable/zed | 19:54 |
| noonedeadpunk | 99cloud contributed not that long ago | 19:55 |
| elodilles | we did not have a rule for that, but did have examples in the past with stable/$series, so we allowed to cut stable/zed, but i agree, the best is to avoid this in the future | 19:55 |
| gmann | yeah | 19:55 |
| noonedeadpunk | should be also possible to add a CI test for that | 19:55 |
| bauzas | noonedeadpunk: all their commits were about docs, but their reviews seemed to me to express interest in the development | 19:56 |
| noonedeadpunk | well, at least they to consume it | 19:57 |
| TheJulia | I've started the call | 19:57 |
| bauzas | I don't know what 99cloud is using of tripleo if not none, but saying "only RH was paying attention to the TripleO development" seems to me a wrong assumption | 19:57 |
| TheJulia | I suspect they were typo fixes | 19:58 |
| gmann | tc-members: call time https://etherpad.opendev.org/p/2023-02-board-openstack-sync | 19:58 |
| TheJulia | someone will need to take a look, but I'm 95% sure they had their own product | 19:58 |
| JayF | Is the email sent to the list just straight up false then? Did tripleo have a meeting and vote on it? Or just a bunch of people in a backroom nodded at each other with red fedoras on | 19:59 |
| JayF | Perhaps asking for the paper trail on how that decision was made is wise from an open governance perspective | 19:59 |
| bauzas | TheJulia: which may be based on bits of TripleO, including THT probably given the reviews | 20:00 |
| bauzas | and yeah, the 4 commits were on docs, but they had like 90 reviews | 20:00 |
| TheJulia | puppet modules it looks like | 20:01 |
| TheJulia | or at least the tripleo-puppet stuffs | 20:01 |
| bauzas | yup, tripleo templates and modules | 20:01 |
| TheJulia | and all look like drive-by +1's in my quick look | 20:01 |
| bauzas | yup, don't know if part of the +1s were gamification, but that's still a valid concern | 20:01 |
| JayF | I think the sentiment that it is mostly driven by redhat is accurate | 20:01 |
| bauzas | and I don't disagree | 20:02 |
| JayF | but we should still do due dillegence to make sure the entire community was consulted in a public forum | 20:02 |
| bauzas | but between "mostly" and "entirely" there are nuances | 20:02 |
| bauzas | and the puppet modules or the heat templates may be reused by other companies | 20:02 |
| TheJulia | indeed | 20:03 |
| TheJulia | TIL, we have an opendev.org matrix server | 20:11 |
| fungi | that's where zuul's channel is | 20:18 |
| fungi | https://matrix.to/#/#zuul:opendev.org | 20:19 |
| fungi | we also have a gerritbot which we can connect to matrix channels | 20:19 |
| *** dasm|afk is now known as dasm|offline | 22:05 | |
| tonyb | gmann: In terms of process, how long will it take to move mistral from DPL -> PTL. Can it be done in <7 days from today? noting that as of now there isn't actually a change to so. | 23:13 |
| tonyb | If not I propose that we continue with the election with mistral as DPL and switch it afterwards. As that's overall less work anyway | 23:13 |
| fungi | probably the only gotcha is if more than one person is interested in being ptl | 23:23 |
| fungi | but that doesn't seem likely | 23:24 |
| fungi | and even if it does crop up, the tc can decide that the way they're going to appoint the ptl is to have a special election for it | 23:24 |
| tonyb | fungi: Yeah I tend to agree. I feel like we need an explicit step in the proccess that's like "$date the TC and projects will not alter projects.yaml in a way that alters the configuration of an election, until after the election concludes" | 23:26 |
| fungi | that was the original intent with deciding when the governance repo would be tagged | 23:26 |
| tonyb | fungi: Yeah I'm happy to do the special election also it only invalidates my "less work" satement | 23:27 |
| tonyb | fungi: Yeah that's true. | 23:27 |
| tonyb | fungi: (re tagging). I'll update the setup-election tool to emit that tagging date so the election officials can communicate that to the TC | 23:28 |
| fungi | good ca | 23:29 |
| fungi | ll | 23:29 |
| tonyb | FWIW: I've captured that at: https://etherpad.opendev.org/p/TC_PTL_Elections2023.2Bobcat#L97 | 23:30 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!