| *** odyssey4me is now known as odyssey4me_ | 13:05 | |
| knikolla[m] | tc-members: o/ reminder for the weekly meeting in 1hr | 15:00 |
|---|---|---|
| slaweq | thx knikolla | 15:01 |
| dansmith | knikolla[m]: I may be late | 15:01 |
| dansmith | or distracted in the beginning | 15:01 |
| knikolla[m] | ack | 15:01 |
| knikolla[m] | tc-members: please vote on the following about PTL appointment. requires 2 more votes. https://review.opendev.org/874969 | 15:09 |
| knikolla[m] | tc-members: the above needs just 1 more. additionally, please vote on this for another PTL appointment (Mistral, and also switched the project back from DPL). https://review.opendev.org/c/openstack/governance/+/873260 | 15:17 |
| opendevreview | Merged openstack/governance master: Adding mailto link in upstream opportunities doc https://review.opendev.org/c/openstack/governance/+/874968 | 15:20 |
| gmann | finished my work, i can attend the meeting. | 15:53 |
| knikolla[m] | gmann: awesome! perfect timing | 15:54 |
| gmann | no traffic today and I am able to reach back home on time :) | 15:55 |
| knikolla[m] | #startmeeting tc | 15:59 |
| opendevmeet | Meeting started Wed Mar 8 15:59:49 2023 UTC and is due to finish in 60 minutes. The chair is knikolla[m]. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:59 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:59 |
| opendevmeet | The meeting name has been set to 'tc' | 15:59 |
| knikolla[m] | gmann: just to make you be late I started it 1 minute early :) | 16:00 |
| gmann | :) | 16:00 |
| knikolla[m] | #topic Roll call | 16:00 |
| noonedeadpunk | o/ | 16:00 |
| gmann | o/ | 16:00 |
| slaweq | o/ | 16:00 |
| knikolla[m] | o/ | 16:00 |
| dansmith | Oj | 16:00 |
| bauzas | \o | 16:00 |
| rosmaita | o/ | 16:00 |
| knikolla[m] | I'm removing discussion on TripleO deprecation and PyPI maintainer list to give us more time to talk about leaderless projects and the vPTG planning. Any opposition? | 16:02 |
| rosmaita | nope | 16:03 |
| gmann | I think we need to decide on TripleO deprecation | 16:03 |
| noonedeadpunk | ++ | 16:03 |
| gmann | we have all the info we need and it just need to take decision | 16:03 |
| noonedeadpunk | Yeah, I'd say to avoid confusion we'd better to deprecate master early | 16:03 |
| gmann | +1 | 16:03 |
| knikolla[m] | ++, we have all the info and we discussed extensively. We just need to formalize a proposal that we can decide on. | 16:04 |
| knikolla[m] | Anyone volunteers to take that on? | 16:04 |
| noonedeadpunk | For example - we in OSA kind of depend on that as we'd love to drop out tripleo CI jobs from our master jobs | 16:04 |
| noonedeadpunk | That we have for some repos | 16:04 |
| gmann | I can do but let's discuss in today meeeting | 16:04 |
| spotz[m] | Late but here | 16:04 |
| knikolla[m] | gmann: thanks. Keeping the item in agenda. | 16:05 |
| gmann | thanks | 16:05 |
| knikolla[m] | #topic Deciding on meeting time | 16:05 |
| knikolla[m] | This week I’ll be sending out a poll to vote on a new meeting time for the TC weekly meeting. | 16:05 |
| knikolla[m] | This will be effective from the first week in April. So, after the vPTG and after all daylight savings changes, so please vote accordingly. | 16:05 |
| knikolla[m] | This will also give us a bit more time to try to make something work for everyone. | 16:05 |
| knikolla[m] | That wasn't the case last time unfortunately. | 16:06 |
| bauzas | knikolla[m]: I'm quite fine with this time at the moment | 16:06 |
| bauzas | why should you want to modify the time ? | 16:06 |
| gmann | bauzas: we need to check time as we have new TC member|s | 16:06 |
| spotz[m] | I wasn’t good with it and with the time change next week this time is a disaster | 16:06 |
| dansmith | bauzas: it's conventional when there are new members to see if the time still works for the majority | 16:06 |
| knikolla[m] | bauzas: We have new TC members. And schedules of people change. | 16:06 |
| bauzas | okay | 16:06 |
| spotz[m] | We need to get rid of daylight savings:( | 16:07 |
| gmann | bauzas: it can end up with same or new time depends on majority of availability | 16:07 |
| bauzas | spotz: well, all the upstream meetings use UTC in general | 16:07 |
| knikolla[m] | spotz: That's also why I'm delaying it to April for the new possible meeting time. | 16:07 |
| bauzas | spotz: so everyone should just know about the daylight savings for every tz | 16:08 |
| spotz[m] | Bauzas other orgs and companies don’t | 16:09 |
| knikolla[m] | You're missing out on the fun if you don't know all the tzs. | 16:09 |
| knikolla[m] | But because our meetings are in UTC, people need to be aware of DST in their own TZ only. | 16:10 |
| bauzas | spotz: look at https://meetings.opendev.org/ | 16:10 |
| bauzas | all of the meetings are using UTC | 16:10 |
| spotz[m] | I am fully aware of that page bauzas | 16:10 |
| knikolla[m] | So starting from next week the TC meeting would be at noon ET, rather than 11am, which is today. | 16:11 |
| knikolla[m] | Anyhow, I'm moving on to the next topic. Please keep an eye on for your IRC pings. | 16:11 |
| gmann | 9 AM for me, little better | 16:11 |
| dansmith | it's 11 there? | 16:11 |
| dansmith | oh right, sorry my finger math is wrong | 16:11 |
| rosmaita | dansmith: yep, 11am in blacksburg, too | 16:11 |
| knikolla[m] | Time in DC, yes. | 16:11 |
| dansmith | lol | 16:11 |
| bauzas | knikolla[m]: that's why in general the meeting chair pings like 1 hour before for making sure people remember about the time | 16:11 |
| dansmith | it's been a long morning :D | 16:12 |
| gmann | dansmith: do not check EU time :) | 16:12 |
| knikolla[m] | bauzas: which i missed last time, but did today :) i'm getting better. | 16:12 |
| knikolla[m] | anyhow. | 16:12 |
| knikolla[m] | #topic Gate health check | 16:12 |
| knikolla[m] | Always a fun topic. Any updates? | 16:12 |
| dansmith | Things are incrementally improving still | 16:13 |
| gmann | not seen much frequent failure this week | 16:13 |
| slaweq | it seems to be much better, at least from my experience | 16:13 |
| dansmith | still plenty of fail, but life is worth living again | 16:13 |
| dansmith | multiple projects seem interested in the mysql memory footprint flag | 16:13 |
| bauzas | ++ | 16:13 |
| dansmith | slaweq: did you guys enable that somewhere? | 16:13 |
| slaweq | and also number of rechecks before patches are merged are going down | 16:13 |
| dansmith | ah, excellent data point | 16:13 |
| noonedeadpunk | For us it's way better, we've almost didn't do rechecks last week | 16:13 |
| gmann | we broke stable gate with jsonschema constraints in Tempest but not it is reverted and green | 16:13 |
| slaweq | dansmith yes, I proposed patch but it's not merged yet https://review.opendev.org/c/openstack/neutron/+/876556 | 16:14 |
| gmann | *now it is reverted | 16:14 |
| dansmith | slaweq: ack | 16:14 |
| gmann | +1 | 16:14 |
| slaweq | and seems that it works pretty good so we will go with this patch most likely | 16:14 |
| dansmith | cool, we were going to flip that to default at some point | 16:15 |
| fungi | we've been a bit constrained on job capacity at heavier times of day, but have been working on trying to tune some things to squeeze a little more out of problem regions or get them back online to help with the volume | 16:15 |
| fungi | people have definitely been observing some backlogs on getting test results though | 16:15 |
| opendevreview | Ghanshyam proposed openstack/election master: Fix setup_election_config for combined election events https://review.opendev.org/c/openstack/election/+/876443 | 16:15 |
| knikolla[m] | anything else, or anything that requires a decision? | 16:17 |
| dansmith | nothing else from me | 16:17 |
| gmann | nothing from me | 16:17 |
| slaweq | nope | 16:17 |
| bauzas | I haven't seen other issues yet this week | 16:17 |
| knikolla[m] | Awesome, great work on getting things to improve! | 16:17 |
| bauzas | like from Tempest | 16:17 |
| knikolla[m] | #topic 2023.2 cycle Leaderless projects | 16:18 |
| knikolla[m] | #link https://etherpad.opendev.org/p/2023.2-leaderless | 16:18 |
| knikolla[m] | We have 7 projects without any candidates: Monasca, Rally, Sahara, Swift, TripleO, Vitrage, Winstackers. | 16:18 |
| knikolla[m] | And 3 projects with late candidacies. Charms, Senlin, and Mistral. | 16:18 |
| gmann | Mistral is basically moving from DPL to PTL | 16:18 |
| knikolla[m] | Please vote on the 3 patches linked in the etherpad for the late appointments. | 16:18 |
| knikolla[m] | And please provide comments on the projects without any candidacies. Otherwise our default behavior will be to switch to DPL. | 16:19 |
| gmann | I think we need to check with team before moving to DPL | 16:19 |
| gmann | because most of them might not have any volunteer so retirement might be the option for them | 16:20 |
| spotz[m] | Yeah | 16:20 |
| gmann | but yes, we need to check their situation and decide on available options we have in etherpad | 16:20 |
| knikolla[m] | Please write your name on the above linked etherpad if you volunteer to reach out to any one of the teams above. | 16:20 |
| gmann | but now a days, PTL missing is not because no one want to be PTL it is because there is no active maintainer left | 16:20 |
| knikolla[m] | Or if you propose a different path of action. | 16:21 |
| knikolla[m] | End of week I will reach out to all the teams that don't have a volunteering TC to reach out to them. | 16:21 |
| knikolla[m] | Seems sensible? | 16:21 |
| gmann | +1 | 16:21 |
| slaweq | knikolla I will try to help with that and will put my name on some of those projects | 16:22 |
| spotz[m] | +1 | 16:22 |
| knikolla[m] | slaweq: fantastic! thank you. | 16:22 |
| knikolla[m] | #topic Deprecation process for TripleO | 16:23 |
| knikolla[m] | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032083.html | 16:23 |
| knikolla[m] | Last week we discussed extensively about this, but if I’m now wrong, we didn’t quite have decisions or proposals. | 16:23 |
| gmann | so as per latest information, it seems no volunteer to maintain stable/zed #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032393.html | 16:23 |
| gmann | we are good for master deprecation but were waiting for stable/zed decision | 16:24 |
| noonedeadpunk | I still think we should not drop stable/zed branch | 16:24 |
| noonedeadpunk | regardless | 16:24 |
| gmann | I will propose to keep stable/zed open (do not mark deprecated) and if anyone come to take it then they can continue the maintenance | 16:24 |
| bauzas | +1 with noonedeadpunk | 16:24 |
| gmann | noonedeadpunk: that can create confusion who using stable/zed | 16:25 |
| noonedeadpunk | gmann: Um. You proposed exactly the same just in case | 16:25 |
| gmann | I will say let's keep it open from where it is today and anyone using it and want to maintain can help | 16:25 |
| knikolla[m] | ++, thank you for formulating a proposal. I also agree on keeping it open. | 16:25 |
| dansmith | yup | 16:25 |
| gmann | noonedeadpunk: oh. sorry missed to read 'not' | 16:25 |
| knikolla[m] | We should at a minimum let the security sig know that there are no maintainers on it. | 16:26 |
| gmann | yeah so basically mark master deprecated, keep stable/zed open as it is | 16:26 |
| noonedeadpunk | ++ | 16:26 |
| noonedeadpunk | With some readme adjustment? | 16:26 |
| gmann | yeah we can inform then and if anything fail need fix we will say no maintainers and any help is welcome | 16:26 |
| gmann | +1 readme can be good place | 16:26 |
| knikolla[m] | That's really the only thing that we NEED to keep supporting. | 16:27 |
| noonedeadpunk | Voting? | 16:27 |
| * bauzas stays silent so (but likes the readme thing) | 16:27 | |
| gmann | i can propose the patches and we can vote on gerrit unless we want to vote here ? | 16:27 |
| knikolla[m] | Does this require a vote on IRC or a vote on a proposal to governance? | 16:28 |
| knikolla[m] | gmann: I prefer Gerrit. | 16:28 |
| noonedeadpunk | Well, branches removal will be releases patch | 16:28 |
| slaweq | gerrit will be good IMO | 16:28 |
| noonedeadpunk | not governance | 16:28 |
| dansmith | since I think this is unprecedented, I'm not sure which procedure to apply, but I too am fine with gerrit :) | 16:28 |
| gmann | noonedeadpunk: there will be needed-by / depends-on on governance patch also and we can see how it goes. | 16:29 |
| knikolla[m] | I think a resolution? | 16:29 |
| gmann | that is same for any deprecation process | 16:29 |
| gmann | no resolution is needed i think | 16:29 |
| noonedeadpunk | yes, for master. | 16:29 |
| noonedeadpunk | But should we conclude that they should not touch zed? | 16:29 |
| gmann | for stable/zed we are just updating readme right? | 16:29 |
| noonedeadpunk | Yeah, but there we won't have rollcall or anything | 16:30 |
| gmann | yeah | 16:30 |
| noonedeadpunk | So I'm just unsure if gerrit is enough to mandate keeping zed | 16:30 |
| gmann | in that case let's do voting on IRC for stable/zed as formal agreement | 16:30 |
| bauzas | isn't that a matter of declaring a branch on EM ? | 16:30 |
| noonedeadpunk | and I guess that's the biggest question we had | 16:30 |
| gmann | noonedeadpunk: you have good point, there are many stackholder like tripleO team release team etc | 16:31 |
| bauzas | if we keep zed (which I'd like), what would be the status of its branch from a project perspective ? | 16:31 |
| noonedeadpunk | bauzas: that's the whole question. Zed is not EM and we do EM kind of coordinated | 16:32 |
| knikolla[m] | bauzas: great question. was just about to ask that to formalize the voting question. | 16:32 |
| gmann | bauzas: we discussed the EM option but stable/wallaby for tripleO is not EM i think and it can create more confusion having stable/zed EM but stable/wallaby open | 16:32 |
| noonedeadpunk | bauzas: but they're having independent release cycle so they should not have stable/zed at all. But since they do... | 16:32 |
| dansmith | wallaby is not EM? | 16:32 |
| bauzas | I'm quite OK with saying Zed is "Maintained" without contributors | 16:32 |
| dansmith | I thought it was, they were just really M'ing it a lot :) | 16:32 |
| slaweq | Even if it will officially not be EM, technically it will be in that state anyway | 16:32 |
| gmann | I mean for TripeleO I need to check | 16:33 |
| bauzas | which is the actual situation | 16:33 |
| noonedeadpunk | yeh, true | 16:33 |
| bauzas | hence the README | 16:33 |
| fungi | wallaby is already em | 16:33 |
| bauzas | but I wanted to clarify the branch state | 16:33 |
| gmann | for TripleO also ? they want to keep support as maintained i think | 16:33 |
| knikolla[m] | It will be maintained beause we need to push out security fixes, unless I'm misunderstanding our commitment to releases. | 16:33 |
| bauzas | then I'm cool with the outcome | 16:33 |
| noonedeadpunk | Well, they can keep maintained in EM :) | 16:33 |
| gmann | but my information on stable/wallaby need more clarification. anyways stable/zed can be just open to anyone to maintained | 16:34 |
| noonedeadpunk | ++ | 16:34 |
| fungi | gmann: projects transition branches to em state together. that's how it's designed. the stable/wallaby branches of all projects are no longer receiving normal maintenance | 16:34 |
| gmann | fungi: right but Tripleo is special where independent release can have stable/zed | 16:34 |
| fungi | that doesn't make it officially maintained state though | 16:35 |
| noonedeadpunk | But on W they were not independent yet | 16:35 |
| gmann | so I am not sure how they are maintaining stable/wallaby as EM or full maintenance | 16:35 |
| fungi | stable/wallaby is no longer officially maintained by openstack, full stop | 16:35 |
| gmann | let's vote on stable/zed things and master deprecation is already under our defined process | 16:35 |
| dansmith | right, so only EM by the tripleo team right? | 16:35 |
| fungi | some people from red hat are patching stable/wallaby of tripleo under extended maintenance | 16:35 |
| knikolla[m] | There's maintained by the team and downstream, and there's maintained by us as a coordinated release body | 16:36 |
| dansmith | yeah | 16:36 |
| knikolla[m] | those are separate things. | 16:36 |
| bauzas | I'm cool with stable/wallaby being EM and stable/zed being Maintained (as other projects do), provided we set a README clarifying the exact worldcrisis discussion | 16:36 |
| gmann | yeah | 16:36 |
| knikolla[m] | That works for me. Keeping stable/zed as maintained, and providing in the readme details on talking to the TC or security team, since there isn't a team anymore. | 16:38 |
| knikolla[m] | that works for formulating a vote here on IRC as the proposal? | 16:38 |
| bauzas | then, I assume no vote is actually required, right? | 16:38 |
| noonedeadpunk | As we're up with the regular process? | 16:39 |
| gmann | +1, we can add TripleO master will be deprecated as existing process | 16:39 |
| noonedeadpunk | And no exception is made? | 16:39 |
| TheJulia | I think as long as it defines the constrained of what maintained means in that specific case for stable/zed, it should work from my pov. | 16:39 |
| bauzas | that's just a bunch of contributors who decided to turn down their feet and the TC saying it's gonna write something in the repo to clarify the lack of contributors despite the project official status | 16:39 |
| knikolla[m] | bauzas: and..... you would be correct, I think. | 16:39 |
| dansmith | so to be clear, | 16:39 |
| dansmith | we're saying zed is supported/maintained which is what the tripleo team said the would not do, | 16:40 |
| noonedeadpunk | yes | 16:40 |
| dansmith | but we're hoping that if any CVEs come along, we'll be able to convince them to fix that, or hope someone else from the community will jump in and try | 16:40 |
| dansmith | correct? | 16:40 |
| TheJulia | dansmith: thanks, that was the heart of the concern I was thinking of | 16:40 |
| gmann | that is why I want to say 'it is open to maintain but no maintainers for now' | 16:40 |
| knikolla[m] | yes, or us. considering the reputation we need to uphold for releases. | 16:40 |
| dansmith | yeah, "maintained but no maintainers" is the short story I think | 16:41 |
| bauzas | :) | 16:41 |
| gmann | yeah | 16:41 |
| dansmith | or "supported but no maintainers" perhaps is better | 16:41 |
| bauzas | I just wanted to clarify it | 16:41 |
| knikolla[m] | dansmith: I effectively see that as "the TC being the emergency maintainers" | 16:41 |
| gmann | humm | 16:41 |
| knikolla[m] | and hunting people down to do something about what crops up | 16:41 |
| bauzas | and yeah, since there is no antelope series, people have to understand that the CVE fix they gonna land will first be on stable/zed | 16:42 |
| gmann | I think if anything come as urgent to fix and no volunteer then we can just retire it | 16:42 |
| fungi | saying it's being kept under stable/maintenance as a matter of policy because those branches were already created. there would need to be a deprecation policy change to make it possible to officially abandon them, but having nobody proposing or reviewing stable branch changes technically isn't that unique of a situation for an openstack project (unfortunately) | 16:42 |
| fungi | if a security fix for those stable branches becomes important to someone, the tc can give them access to approve such fixes | 16:43 |
| dansmith | fungi: yeah true, we have some non-deprecated projects that are basically in that state I guess | 16:43 |
| gmann | how about this to vote on? "TrieplO master will be deprecated as normal process, keeping stable/zed as maintained, and providing in the readme details on "it is supported but no maintainers ". " | 16:43 |
| gmann | "TrieplO master will be deprecated as normal process, keeping stable/zed as supported, and providing in the readme details on "it is supported but no maintainers ". " | 16:43 |
| fungi | or "seeking interested maintainers" maybe | 16:44 |
| gmann | s/maintained/supported | 16:44 |
| dansmith | gmann: wfm | 16:44 |
| bauzas | that leaves us about 13 months to figure out whether this is a good outcome :) | 16:44 |
| knikolla[m] | gmann: i really want a "talk to TC" part in that readme | 16:44 |
| bauzas | and in 13 months, Zed will be EM \o/ | 16:45 |
| knikolla[m] | but that works for me. | 16:45 |
| gmann | knikolla[m]: sure, or there will be tripelo PTL till it is retired so we have point of contact | 16:45 |
| knikolla[m] | How do I open a vote? I forgot the syntax. | 16:45 |
| bauzas | startvote | 16:45 |
| bauzas | with a question and a question mark with the answers | 16:45 |
| bauzas | like startvote blah ? yes, bo | 16:46 |
| gmann | knikolla[m]: #link https://docs.opendev.org/opendev/system-config/latest/irc.html#voting | 16:46 |
| knikolla[m] | #startvote For TripleO: Follow the normal deprecation process for the master branch, keep stable/zed as supported, and update the readme in the repos to describe the lack of a team and to contact the TC for urgent matters? yes, no | 16:47 |
| opendevmeet | Begin voting on: For TripleO: Follow the normal deprecation process for the master branch, keep stable/zed as supported, and update the readme in the repos to describe the lack of a team and to contact the TC for urgent matters? Valid vote options are yes, no. | 16:47 |
| opendevmeet | Vote using '#vote OPTION'. Only your last vote counts. | 16:47 |
| dansmith | #vote yes | 16:47 |
| noonedeadpunk | #vote yes | 16:47 |
| gmann | #vote yes | 16:47 |
| rosmaita | #vote no | 16:47 |
| spotz[m] | #vote yes | 16:47 |
| * bauzas abstains (despite his nod) | 16:47 | |
| slaweq | #vote yes | 16:47 |
| knikolla[m] | #vote yes | 16:48 |
| knikolla[m] | are we missing anyone? | 16:48 |
| noonedeadpunk | Jay is absent | 16:48 |
| knikolla[m] | despite the clear majority. | 16:48 |
| gmann | those present here all voted | 16:48 |
| knikolla[m] | #endvote | 16:48 |
| opendevmeet | Voted on "For TripleO: Follow the normal deprecation process for the master branch, keep stable/zed as supported, and update the readme in the repos to describe the lack of a team and to contact the TC for urgent matters?" Results are | 16:48 |
| opendevmeet | yes (6): dansmith, spotz[m], noonedeadpunk, knikolla[m], slaweq, gmann | 16:48 |
| opendevmeet | no (1): rosmaita | 16:48 |
| knikolla[m] | rosmaita: we can discuss after the meeting if you'd like about your disagreement? | 16:49 |
| dansmith | rosmaita: did I miss you arguing for something else | 16:49 |
| dansmith | ? | 16:49 |
| rosmaita | knikolla[m]: sure | 16:49 |
| gmann | as next step, I can propose the patches in governance and stable/zed or wait until rosmaita concern discussion ? | 16:49 |
| rosmaita | dansmith: no, i don't have any alternative proposal, i just don't like the precedent this sets | 16:49 |
| dansmith | rosmaita: oh I don't like it either | 16:50 |
| rosmaita | but it's the practical thing to do | 16:50 |
| gmann | me too :) | 16:50 |
| bauzas | heh, I don't see a lot of fun in this discussion | 16:50 |
| rosmaita | i had the luxury of "voting my conscience" because i knew i was going to lose! | 16:50 |
| dansmith | damn, can I change my vote to be with rosmaita ? #vote yes-but-I-hate-it ? | 16:50 |
| gmann | and something to discuss in PTG to avoid such situation in future | 16:50 |
| dansmith | haha | 16:50 |
| spotz[m] | Hehe | 16:50 |
| noonedeadpunk | It's situation we never should have found ourselves, but I assume honest mistake was made when stable/zed was created | 16:50 |
| gmann | true | 16:51 |
| knikolla[m] | all options were terrible, we chose the least worse. | 16:51 |
| knikolla[m] | alright. moving on. | 16:51 |
| bauzas | can we maybe say an independent release model needs to not use a specific release name from the upstream cadence if so ?. | 16:51 |
| noonedeadpunk | Yes, exactly this ^ I've also proposed | 16:51 |
| gmann | #link https://review.opendev.org/c/openstack/governance/+/875942 | 16:52 |
| bauzas | this isn't a quite-independent-skip-some-releases model AFAIK | 16:52 |
| knikolla[m] | thank you gmann | 16:52 |
| gmann | knikolla[m]: rosmaita you want me to go ahead on governance changes or wait more? | 16:52 |
| rosmaita | gmann: i think go ahead | 16:53 |
| gmann | I really want to close this task | 16:53 |
| gmann | rosmaita: ok thanks | 16:53 |
| spotz[m] | But they deployed that version of OpenStack so in the case it made sense | 16:53 |
| knikolla[m] | I'm moving on directly to the vPTG agenda item. And skipping the 2 ones in between. | 16:53 |
| gmann | +1 | 16:53 |
| knikolla[m] | #topic Virtual PTG Planning | 16:53 |
| knikolla[m] | March 27-31, 2023, there's the Virtual PTG. | 16:53 |
| knikolla[m] | #link https://etherpad.opendev.org/p/tc-2023-2-ptg | 16:54 |
| knikolla[m] | We need to decide on the amount of time | 16:54 |
| knikolla[m] | time | 16:54 |
| knikolla[m] | and agenda items | 16:54 |
| gmann | I think 4 hrs slots for two days work well in past PTGs | 16:55 |
| knikolla[m] | Please propose agenda items in the etherpad above | 16:55 |
| gmann | and 17-19 UTC slots on Thursday and Friday worked well last time. even ptgbot did not support those not in this PTG too | 16:55 |
| gmann | any other feedback on 17-19 UTC slots? | 16:55 |
| gmann | at least it worked fine for me to attend project specific discussion | 16:56 |
| rosmaita | which just to be clear is a 3 hour block (ends at 2000, not 1900) | 16:56 |
| rosmaita | makes for a long day, but i agree it worked well to participate in other stuff, and have other people join us | 16:57 |
| noonedeadpunk | Thursday/Friday works for me | 16:57 |
| slaweq | it will be a bit late for me after daylight change (22:00) but I will handle that if that works for others | 16:57 |
| gmann | rosmaita: I think it was 15-19 UTC | 16:57 |
| noonedeadpunk | +1 ^ | 16:57 |
| gmann | not 20 UTC | 16:57 |
| gmann | #link https://etherpad.opendev.org/p/tc-2023-1-ptg#L18 | 16:58 |
| * dansmith has a hard stop in 70 seconds | 16:58 | |
| bauzas | that's the problem with virtual meetings, you have to fight the time differences + the personal reasons | 16:58 |
| gmann | In last PTG, it ended at 19 UTC | 16:58 |
| bauzas | pick anytime you want, I'll try to attend (hardly tho) | 16:58 |
| rosmaita | ok, so we are just talking about two two-hour blocks | 16:58 |
| slaweq | gmann 19 UTC is better for me :) | 16:58 |
| knikolla[m] | I'm okay with the same times and days as last PTG. | 16:59 |
| gmann | rosmaita: I mean to say 15-16 UTC as normal slot and 17-19 UTC as extended slot where most of projects does not have their discussion schedule | 16:59 |
| gmann | 15-17 UTC as normal | 16:59 |
| fungi | just be aware that scheduling discussion during the break defeats the purpose of having a break | 16:59 |
| bauzas | and as a reminder, US and European daylight savings occur *before* the PTG, keep it in mind when you decide ;) | 16:59 |
| knikolla[m] | after US, before European | 17:00 |
| knikolla[m] | I think, no? | 17:00 |
| slaweq | after EU | 17:00 |
| bauzas | nope, europeans shift the sunday before the ptg | 17:00 |
| slaweq | it will be just weekend before PTG | 17:00 |
| knikolla[m] | After both, then, cool! | 17:00 |
| gmann | +1 | 17:00 |
| fungi | us changes this weekend, eu changes two weeks later | 17:00 |
| knikolla[m] | Alright, I'll schedule the times and send an email | 17:00 |
| gmann | knikolla[m]: one more thing but we are on time | 17:00 |
| gmann | do we want to schedule 'operator-hour' this time? | 17:01 |
| bauzas | last time, nova operator hours were crickets. | 17:01 |
| bauzas | despite heavy communication | 17:01 |
| knikolla[m] | gmann: great question, we can talk about that in the channel after the meeting. | 17:01 |
| gmann | or we can discuss it in next meeting as it might need more time to discuss | 17:01 |
| knikolla[m] | I'm closing it now. | 17:01 |
| gmann | knikolla[m]: sure | 17:01 |
| spotz[m] | I did reach out to Kendall to maybe get a list of projects they want to meet with | 17:01 |
| slaweq | thx, I have to go now | 17:02 |
| slaweq | o/ | 17:02 |
| knikolla[m] | thanks spotz | 17:02 |
| knikolla[m] | #endmeeting | 17:02 |
| opendevmeet | Meeting ended Wed Mar 8 17:02:18 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:02 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-08-15.59.html | 17:02 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-08-15.59.txt | 17:02 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-08-15.59.log.html | 17:02 |
| gmann | thanks knikolla[m] | 17:02 |
| bauzas | thanks knikolla[m] | 17:02 |
| gmann | knikolla[m]: let's add it in next week agenda as many TC members are not here now | 17:02 |
| bauzas | about operator hours, I'm not opposed to allocate some time for the nova project | 17:02 |
| gmann | we have feedback for operator-hour which can be helpful | 17:02 |
| bauzas | but I want those to be productive | 17:02 |
| knikolla[m] | Please scan this QR code for a survey and an opportunity to win a $50 gift card | 17:02 |
| bauzas | so I'd appreciate if somehow we could ask the operators first if they're willing to attend such sessions | 17:03 |
| gmann | bauzas: yeah, it was first time in last PTG but I am more optimistic here :) | 17:03 |
| bauzas | gmann: I got way more productive talks during the Summit meet-and-greet | 17:03 |
| bauzas | that I organized (and which I proposed again for YVR) | 17:03 |
| gmann | bauzas: +1 | 17:03 |
| bauzas | but again, I'm not opposed to run such operator hours, again if I'm sure audience will come | 17:04 |
| bauzas | preregistration would be a treat for me :) | 17:04 |
| gmann | knikolla[m]: bauzas: may be it will be good to ask in openstack-discuss ML this time also where we have project/operator interested in those and we can use that data to decide it for this pTG ? | 17:04 |
| bauzas | gmann: we did the show in this ML before | 17:05 |
| bauzas | for the previous PTG | 17:05 |
| bauzas | I'm honestly thinking we would get better chances if the Foundation would sign-up for a large communication | 17:05 |
| bauzas | also, | 17:06 |
| knikolla[m] | What kind of large communication do you have in mind? | 17:06 |
| gmann | last time we all tried on ML, newsletter, twitter etc | 17:06 |
| bauzas | emails | 17:06 |
| bauzas | but not on -discuss | 17:06 |
| gmann | operators/developers are on this ML though not sure how many active operators but they supposed to be | 17:07 |
| bauzas | but ack, if newsletter was in last time, that was my current expectations | 17:07 |
| bauzas | I was thinking of a email campaign, like they do for usual Summits | 17:08 |
| gmann | sure, I am saying let's collect data what all projects and operators think operator-hour they want so that we can see if no one interested then not to schedule at all | 17:08 |
| gmann | once we decide to schedule then we can talk on publishing it all best way | 17:08 |
| bauzas | cool, and again, you can consider nova as volunteer | 17:09 |
| bauzas | unrelated, do we plan to have onboarding sessions at the Summit ? | 17:09 |
| gmann | you mean project-updates ? | 17:09 |
| bauzas | no | 17:09 |
| bauzas | I mean a 1 to 2 hour of project onboarding for new contributors | 17:10 |
| bauzas | I'm fancy volunteering to it | 17:10 |
| gmann | I think i forgot about most of the scheduling for in-person summit :) | 17:10 |
| fungi | in theory you could do that during ptg time since it's going to be colocated with the summit | 17:10 |
| fungi | also from what i understand, the ptg space is going to be organized the way it was in shanghai: one giant room with tables spread apart for the teams to use | 17:11 |
| fungi | not individual rooms like we had at some venues | 17:12 |
| fungi | not sure if that makes onboarding of new contributors harder or easier | 17:12 |
| bauzas | fungi: ack ok, gtk | 17:14 |
| bauzas | I should have proposed a technical breakout session then | 17:15 |
| bauzas | I just proposed a regular breakout but it got refused | 17:15 |
| bauzas | the problem with the PTG space is that it's hard to share his screen to the trainees | 17:16 |
| bauzas | and I was thinking of a code walkthrough | 17:16 |
| fungi | availability of rooms in this venue is limited, a lot of compromises had to be sacrificed to keep costs down so that we didn't need to increase ticket prices | 17:17 |
| bauzas | fair enough | 17:18 |
| bauzas | I guess there won't be a upstream training ? | 17:18 |
| * bauzas should consider to resurrect the OUI https://docs.openstack.org/upstream-training/ | 17:19 | |
| noonedeadpunk | hm, but there were project onboarding section while submitting for forums? | 17:19 |
| gmann | but do we need upstream training ? | 17:20 |
| bauzas | noonedeadpunk: I can try to propose a Forum onboarding session for sure | 17:21 |
| bauzas | gmann: on nova, I wish so | 17:21 |
| fungi | diablo_rojo and ildikov may know what the situation is with upstream institute | 17:21 |
| bauzas | we need fresh blood | 17:21 |
| noonedeadpunk | everyone needs... | 17:21 |
| bauzas | and I see people coming in and by | 17:21 |
| gmann | bauzas: +1, i feel onboarding sessions are more helpful than upstream training | 17:22 |
| ildikov | o/ | 17:22 |
| gmann | onboarding sessions per project | 17:22 |
| bauzas | at least on our project, we have a reasonable amount of on-off contributors | 17:22 |
| gmann | for upstream training, we have really good documents written in contributors guide | 17:22 |
| ildikov | the slides and content are available on the web to run a training, if it is interest for the community | 17:22 |
| gmann | bauzas: ++ | 17:22 |
| fungi | i gather there will be a "git and gerrit lunch-n-learn" for some basic tooling and workflow introduction | 17:22 |
| bauzas | I somehow would like to solidify this amount of subject-interested people and turn them into more seasoned devs | 17:23 |
| ildikov | gmann: +1 on good content overall! | 17:23 |
| gmann | I need to update those slide for few things though but it is more of avail;able documents to know the process of getting started | 17:23 |
| gmann | bauzas: yeah, forum sessions can be good place for those | 17:23 |
| bauzas | lemme clarify, I was more thinking of a project onboarding than an openstack training, but I need to find some colocality | 17:24 |
| * bauzas wonders if he already submitted a Forum session about onboarding, now he's confused why he didn't so | 17:24 | |
| bauzas | oh no I did | 17:25 |
| bauzas | https://cfp.openinfra.dev/app/vancouver-2023/20/presentations/25420/summary | 17:25 |
| bauzas | sorry about the confusion | 17:26 |
| gmann | cool | 17:26 |
| clarkb | The struggle I've had with onboarding is that it seems different people need different things to get onboarded. This leads to mentoring which ime has been reasonably effective the problem is it doesn't scale well. Just talking out loud here maybe mentoring (over time longer term) is something we should be looking at too | 17:27 |
| clarkb | taking that brainstorm idea further one outcome of an onboarding session might be to pair specific individuals up with specific mentors | 17:27 |
| bauzas | clarkb: I did onboarding internally with 3 new members and it quite worked | 17:28 |
| bauzas | but I agree, mentoring is a required follow-up action | 17:28 |
| opendevreview | Merged openstack/governance master: Appoint Liu as Senlin PTL https://review.opendev.org/c/openstack/governance/+/874969 | 18:23 |
| opendevreview | Merged openstack/governance master: Appoint Felipe Reyes as OpenStack_Charms PTL https://review.opendev.org/c/openstack/governance/+/874971 | 18:30 |
| *** odyssey4me_ is now known as odyssey4me | 18:56 | |
| *** odyssey4me is now known as odyssey4me_ | 19:04 | |
| *** odyssey4me_ is now known as odyssey4me | 19:04 | |
| *** odyssey4me is now known as odyssey4me_ | 19:22 | |
| *** odyssey4me_ is now known as odyssey4me | 19:22 | |
| *** odyssey4me is now known as odyssey4me_ | 19:31 | |
| *** odyssey4me_ is now known as odyssey4me | 19:32 | |
| *** odyssey4me is now known as odyssey4me_ | 19:37 | |
| *** odyssey4me_ is now known as odyssey4me | 19:37 | |
| *** odyssey4me is now known as odyssey4me_ | 20:15 | |
| *** odyssey4me_ is now known as odyssey4me | 20:15 | |
| *** odyssey4me is now known as odyssey4me_ | 20:17 | |
| *** odyssey4me_ is now known as odyssey4me | 20:17 | |
| *** odyssey4me is now known as odyssey4me_ | 20:47 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!