15:59:49 <knikolla[m]> #startmeeting tc
15:59:49 <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:49 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:49 <opendevmeet> The meeting name has been set to 'tc'
16:00:17 <knikolla[m]> gmann: just to make you be late I started it 1 minute early :)
16:00:26 <gmann> :)
16:00:29 <knikolla[m]> #topic Roll call
16:00:30 <noonedeadpunk> o/
16:00:31 <gmann> o/
16:00:32 <slaweq> o/
16:00:35 <knikolla[m]> o/
16:00:39 <dansmith> Oj
16:00:39 <bauzas> \o
16:00:55 <rosmaita> o/
16:02:52 <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:03:07 <rosmaita> nope
16:03:11 <gmann> I think we need to decide on  TripleO deprecation
16:03:25 <noonedeadpunk> ++
16:03:43 <gmann> we have all the info we need and it just need to take decision
16:03:49 <noonedeadpunk> Yeah, I'd say to avoid confusion we'd better to deprecate master early
16:03:58 <gmann> +1
16:04:14 <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:22 <knikolla[m]> Anyone volunteers to take that on?
16:04:33 <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:39 <noonedeadpunk> That we have for some repos
16:04:45 <gmann> I can do but let's discuss in today meeeting
16:04:51 <spotz[m]> Late but here
16:05:08 <knikolla[m]> gmann: thanks. Keeping the item in agenda.
16:05:12 <gmann> thanks
16:05:22 <knikolla[m]> #topic Deciding on meeting time
16:05:31 <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:40 <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:50 <knikolla[m]> This will also give us a bit more time to try to make something work for everyone.
16:06:02 <knikolla[m]> That wasn't the case last time unfortunately.
16:06:10 <bauzas> knikolla[m]: I'm quite fine with this time at the moment
16:06:27 <bauzas> why should you want to modify the time ?
16:06:39 <gmann> bauzas: we need to check time as we have new TC member|s
16:06:41 <spotz[m]> I wasn’t good with it and with the time change next week this time is a disaster
16:06:50 <dansmith> bauzas: it's conventional when there are new members to see if the time still works for the majority
16:06:52 <knikolla[m]> bauzas: We have new TC members. And schedules of people change.
16:06:59 <bauzas> okay
16:07:16 <spotz[m]> We need to get rid of daylight savings:(
16:07:24 <gmann> bauzas: it can end up with same or new time depends on majority of availability
16:07:45 <bauzas> spotz: well, all the upstream meetings use UTC in general
16:07:46 <knikolla[m]> spotz: That's also why I'm delaying it to April for the new possible meeting time.
16:08:12 <bauzas> spotz: so everyone should just know about the daylight savings for every tz
16:09:07 <spotz[m]> Bauzas other orgs and companies don’t
16:09:40 <knikolla[m]> You're missing out on the fun if you don't know all the tzs.
16:10:16 <knikolla[m]> But because our meetings are in UTC, people need to be aware of DST in their own TZ only.
16:10:17 <bauzas> spotz: look at https://meetings.opendev.org/
16:10:28 <bauzas> all of the meetings are using UTC
16:10:41 <spotz[m]> I am fully aware of that page bauzas
16:11:05 <knikolla[m]> So starting from next week the TC meeting would be at noon ET, rather than 11am, which is today.
16:11:28 <knikolla[m]> Anyhow, I'm moving on to the next topic. Please keep an eye on for your IRC pings.
16:11:28 <gmann> 9 AM for me, little better
16:11:29 <dansmith> it's 11 there?
16:11:43 <dansmith> oh right, sorry my finger math is wrong
16:11:48 <rosmaita> dansmith: yep, 11am in blacksburg, too
16:11:49 <knikolla[m]> Time in DC, yes.
16:11:51 <dansmith> lol
16:11:59 <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:12:02 <dansmith> it's been a long morning :D
16:12:21 <gmann> dansmith: do not check EU time :)
16:12:28 <knikolla[m]> bauzas: which i missed last time, but did today :) i'm getting better.
16:12:48 <knikolla[m]> anyhow.
16:12:49 <knikolla[m]> #topic Gate health check
16:12:59 <knikolla[m]> Always a fun topic. Any updates?
16:13:05 <dansmith> Things are incrementally improving still
16:13:13 <gmann> not seen much frequent failure this week
16:13:16 <slaweq> it seems to be much better, at least from my experience
16:13:19 <dansmith> still plenty of fail, but life is worth living again
16:13:31 <dansmith> multiple projects seem interested in the mysql memory footprint flag
16:13:35 <bauzas> ++
16:13:36 <dansmith> slaweq: did you guys enable that somewhere?
16:13:44 <slaweq> and also number of rechecks before patches are merged are going down
16:13:52 <dansmith> ah, excellent data point
16:13:54 <noonedeadpunk> For us it's way better, we've almost didn't do rechecks last week
16:13:55 <gmann> we broke stable gate with jsonschema  constraints in Tempest but not it is reverted and green
16:14:24 <slaweq> dansmith yes, I proposed patch but it's not merged yet https://review.opendev.org/c/openstack/neutron/+/876556
16:14:30 <gmann> *now it is reverted
16:14:32 <dansmith> slaweq: ack
16:14:36 <gmann> +1
16:14:50 <slaweq> and seems that it works pretty good so we will go with this patch most likely
16:15:07 <dansmith> cool, we were going to flip that to default at some point
16:15:07 <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:38 <fungi> people have definitely been observing some backlogs on getting test results though
16:15:50 <opendevreview> Ghanshyam proposed openstack/election master: Fix setup_election_config for combined election events  https://review.opendev.org/c/openstack/election/+/876443
16:17:15 <knikolla[m]> anything else, or anything that requires a decision?
16:17:29 <dansmith> nothing else from me
16:17:35 <gmann> nothing from me
16:17:44 <slaweq> nope
16:17:46 <bauzas> I haven't seen other issues yet this week
16:17:52 <knikolla[m]> Awesome, great work on getting things to improve!
16:17:53 <bauzas> like from Tempest
16:18:07 <knikolla[m]> #topic 2023.2 cycle Leaderless projects
16:18:12 <knikolla[m]> #link https://etherpad.opendev.org/p/2023.2-leaderless
16:18:22 <knikolla[m]> We have 7 projects without any candidates: Monasca, Rally, Sahara, Swift, TripleO, Vitrage, Winstackers.
16:18:22 <knikolla[m]> And 3 projects with late candidacies. Charms, Senlin, and Mistral.
16:18:44 <gmann> Mistral is basically moving from DPL to PTL
16:18:50 <knikolla[m]> Please vote on the 3 patches linked in the etherpad for the late appointments.
16:19:22 <knikolla[m]> And please provide comments on the projects without any candidacies. Otherwise our default behavior will be to switch to DPL.
16:19:47 <gmann> I think we need to check with team before moving to DPL
16:20:05 <gmann> because most of them might not have any volunteer so retirement might be the option for them
16:20:15 <spotz[m]> Yeah
16:20:27 <gmann> but yes, we need to check their situation and decide on available options we have in etherpad
16:20:47 <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:56 <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:21:18 <knikolla[m]> Or if you propose a different path of action.
16:21:34 <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:47 <knikolla[m]> Seems sensible?
16:21:54 <gmann> +1
16:22:32 <slaweq> knikolla I will try to help with that and will put my name on some of those projects
16:22:34 <spotz[m]> +1
16:22:45 <knikolla[m]> slaweq: fantastic! thank you.
16:23:20 <knikolla[m]> #topic Deprecation process for TripleO
16:23:28 <knikolla[m]> #link https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032083.html
16:23:50 <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:54 <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:24:16 <gmann> we are good for master deprecation but were waiting for stable/zed decision
16:24:43 <noonedeadpunk> I still think we should not drop stable/zed branch
16:24:45 <noonedeadpunk> regardless
16:24:46 <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:49 <bauzas> +1 with noonedeadpunk
16:25:02 <gmann> noonedeadpunk: that can create confusion who using stable/zed
16:25:32 <noonedeadpunk> gmann:  Um. You proposed exactly the same just in case
16:25:37 <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:44 <knikolla[m]> ++, thank you for formulating a proposal. I also agree on keeping it open.
16:25:53 <dansmith> yup
16:25:56 <gmann> noonedeadpunk: oh. sorry missed to read 'not'
16:26:13 <knikolla[m]> We should at a minimum let the security sig know that there are no maintainers on it.
16:26:14 <gmann> yeah so basically mark master deprecated, keep stable/zed open as it is
16:26:29 <noonedeadpunk> ++
16:26:45 <noonedeadpunk> With some readme adjustment?
16:26:48 <gmann> yeah we can inform then and if anything fail need fix we will say no maintainers and any help is welcome
16:26:59 <gmann> +1 readme can be good place
16:27:02 <knikolla[m]> That's really the only thing that we NEED to keep supporting.
16:27:29 <noonedeadpunk> Voting?
16:27:51 * bauzas stays silent so (but likes the readme thing)
16:27:56 <gmann> i can propose the patches and we can vote on gerrit unless we want to vote here ?
16:28:02 <knikolla[m]> Does this require a vote on IRC or a vote on a proposal to governance?
16:28:13 <knikolla[m]> gmann: I prefer Gerrit.
16:28:22 <noonedeadpunk> Well, branches removal will be releases patch
16:28:25 <slaweq> gerrit will be good IMO
16:28:27 <noonedeadpunk> not governance
16:28:56 <dansmith> since I think this is unprecedented, I'm not sure which procedure to apply, but I too am fine with gerrit :)
16:29:06 <gmann> noonedeadpunk: there will be needed-by / depends-on on governance patch also and we can see how it goes.
16:29:14 <knikolla[m]> I think a resolution?
16:29:15 <gmann> that is same for any deprecation process
16:29:22 <gmann> no resolution is needed i think
16:29:24 <noonedeadpunk> yes, for master.
16:29:38 <noonedeadpunk> But should we conclude that they should not touch zed?
16:29:43 <gmann> for stable/zed we are just updating readme right?
16:30:09 <noonedeadpunk> Yeah, but there we won't have rollcall or anything
16:30:24 <gmann> yeah
16:30:29 <noonedeadpunk> So I'm just unsure if gerrit is enough to mandate keeping zed
16:30:41 <gmann> in that case let's do voting on IRC for stable/zed as formal agreement
16:30:50 <bauzas> isn't that a matter of declaring a branch on EM ?
16:30:52 <noonedeadpunk> and I guess that's the biggest question we had
16:31:00 <gmann> noonedeadpunk: you have good point, there are many stackholder like tripleO team release team etc
16:31:50 <bauzas> if we keep zed (which I'd like), what would be the status of its branch from a project perspective ?
16:32:07 <noonedeadpunk> bauzas: that's the whole question. Zed is not EM and we do EM kind of coordinated
16:32:07 <knikolla[m]> bauzas: great question. was just about to ask that to formalize the voting question.
16:32:19 <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:34 <noonedeadpunk> bauzas: but they're having independent release cycle so they should not have stable/zed at all. But since they do...
16:32:39 <dansmith> wallaby is not EM?
16:32:51 <bauzas> I'm quite OK with saying Zed is "Maintained" without contributors
16:32:53 <dansmith> I thought it was, they were just really M'ing it a lot :)
16:32:56 <slaweq> Even if it will officially not be EM, technically it will be in that state anyway
16:33:02 <gmann> I mean for TripeleO I need to check
16:33:02 <bauzas> which is the actual situation
16:33:05 <noonedeadpunk> yeh, true
16:33:09 <bauzas> hence the README
16:33:10 <fungi> wallaby is already em
16:33:21 <bauzas> but I wanted to clarify the branch state
16:33:30 <gmann> for TripleO also ? they want to keep support as maintained i think
16:33:30 <knikolla[m]> It will be maintained beause we need to push out security fixes, unless I'm misunderstanding our commitment to releases.
16:33:49 <bauzas> then I'm cool with the outcome
16:33:55 <noonedeadpunk> Well, they can keep maintained in EM :)
16:34:05 <gmann> but my information on stable/wallaby need more clarification. anyways stable/zed can be just open to anyone to maintained
16:34:15 <noonedeadpunk> ++
16:34:17 <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:45 <gmann> fungi: right but Tripleo is special where independent release can have stable/zed
16:35:00 <fungi> that doesn't make it officially maintained state though
16:35:03 <noonedeadpunk> But on W they were not independent yet
16:35:06 <gmann> so I am not sure how they are maintaining stable/wallaby as EM or full maintenance
16:35:12 <fungi> stable/wallaby is no longer officially maintained by openstack, full stop
16:35:40 <gmann> let's vote on stable/zed things and master deprecation is already under our defined process
16:35:45 <dansmith> right, so only EM by the tripleo team right?
16:35:57 <fungi> some people from red hat are patching stable/wallaby of tripleo under extended maintenance
16:36:03 <knikolla[m]> There's maintained by the team and downstream, and there's maintained by us as a coordinated release body
16:36:04 <dansmith> yeah
16:36:12 <knikolla[m]> those are separate things.
16:36:35 <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:44 <gmann> yeah
16:38:03 <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:20 <knikolla[m]> that works for formulating a vote here on IRC as the proposal?
16:38:44 <bauzas> then, I assume no vote is actually required, right?
16:39:02 <noonedeadpunk> As we're up with the regular process?
16:39:05 <gmann> +1, we can add TripleO master will be deprecated as existing  process
16:39:09 <noonedeadpunk> And no exception is made?
16:39:18 <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:24 <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:26 <knikolla[m]> bauzas: and..... you would be correct, I think.
16:39:54 <dansmith> so to be clear,
16:40:12 <dansmith> we're saying zed is supported/maintained which is what the tripleo team said the would not do,
16:40:33 <noonedeadpunk> yes
16:40:33 <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:35 <dansmith> correct?
16:40:41 <TheJulia> dansmith: thanks, that was the heart of the concern I was thinking of
16:40:48 <gmann> that is why I want to say 'it is open to maintain but no maintainers for now'
16:40:55 <knikolla[m]> yes, or us. considering the reputation we need to uphold for releases.
16:41:08 <dansmith> yeah, "maintained but no maintainers" is the short story I think
16:41:17 <bauzas> :)
16:41:18 <gmann> yeah
16:41:24 <dansmith> or "supported but no maintainers" perhaps is better
16:41:24 <bauzas> I just wanted to clarify it
16:41:32 <knikolla[m]> dansmith: I effectively see that as "the TC being the emergency maintainers"
16:41:45 <gmann> humm
16:41:49 <knikolla[m]> and hunting people down to do something about what crops up
16:42:04 <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:05 <gmann> I think if anything come as urgent to fix and no volunteer then we can just retire it
16:42:09 <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:43:02 <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:11 <dansmith> fungi: yeah true, we have some non-deprecated projects that are basically in that state I guess
16:43:33 <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:55 <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:44:04 <fungi> or "seeking interested maintainers" maybe
16:44:04 <gmann> s/maintained/supported
16:44:28 <dansmith> gmann: wfm
16:44:46 <bauzas> that leaves us about 13 months to figure out whether this is a good outcome :)
16:44:52 <knikolla[m]> gmann: i really want a "talk to TC" part in that readme
16:45:02 <bauzas> and in 13 months, Zed will be EM \o/
16:45:09 <knikolla[m]> but that works for me.
16:45:28 <gmann> knikolla[m]: sure, or there will be tripelo PTL till it is retired so we have point of contact
16:45:36 <knikolla[m]> How do I open a vote? I forgot the syntax.
16:45:43 <bauzas> startvote
16:45:56 <bauzas> with a question and a question mark with the answers
16:46:03 <bauzas> like startvote blah ? yes, bo
16:46:07 <gmann> knikolla[m]: #link https://docs.opendev.org/opendev/system-config/latest/irc.html#voting
16:47:16 <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:16 <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:16 <opendevmeet> Vote using '#vote OPTION'. Only your last vote counts.
16:47:35 <dansmith> #vote yes
16:47:36 <noonedeadpunk> #vote yes
16:47:39 <gmann> #vote yes
16:47:45 <rosmaita> #vote no
16:47:49 <spotz[m]> #vote yes
16:47:52 * bauzas abstains (despite his nod)
16:47:55 <slaweq> #vote yes
16:48:01 <knikolla[m]> #vote yes
16:48:25 <knikolla[m]> are we missing anyone?
16:48:37 <noonedeadpunk> Jay is absent
16:48:40 <knikolla[m]> despite the clear majority.
16:48:47 <gmann> those present here all voted
16:48:50 <knikolla[m]> #endvote
16:48:50 <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:50 <opendevmeet> yes (6): dansmith, spotz[m], noonedeadpunk, knikolla[m], slaweq, gmann
16:48:50 <opendevmeet> no (1): rosmaita
16:49:18 <knikolla[m]> rosmaita: we can discuss after the meeting if you'd like about your disagreement?
16:49:31 <dansmith> rosmaita: did I miss you arguing for something else
16:49:31 <dansmith> ?
16:49:39 <rosmaita> knikolla[m]: sure
16:49:56 <gmann> as next step, I can propose the patches in governance and stable/zed  or wait until rosmaita concern discussion ?
16:49:57 <rosmaita> dansmith: no, i don't have any alternative proposal, i just don't like the precedent this sets
16:50:15 <dansmith> rosmaita: oh I don't like it either
16:50:22 <rosmaita> but it's the practical thing to do
16:50:23 <gmann> me too :)
16:50:34 <bauzas> heh, I don't see a lot of fun in this discussion
16:50:40 <rosmaita> i had the luxury of "voting my conscience" because i knew i was going to lose!
16:50:41 <dansmith> damn, can I change my vote to be with rosmaita ? #vote yes-but-I-hate-it ?
16:50:45 <gmann> and something to discuss in PTG to avoid such situation in future
16:50:46 <dansmith> haha
16:50:55 <spotz[m]> Hehe
16:50:56 <noonedeadpunk> It's situation we never should have found ourselves, but I assume honest mistake was made when stable/zed was created
16:51:08 <gmann> true
16:51:26 <knikolla[m]> all options were terrible, we chose the least worse.
16:51:35 <knikolla[m]> alright. moving on.
16:51:35 <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:54 <noonedeadpunk> Yes, exactly this ^ I've also proposed
16:52:17 <gmann> #link https://review.opendev.org/c/openstack/governance/+/875942
16:52:21 <bauzas> this isn't a quite-independent-skip-some-releases model AFAIK
16:52:25 <knikolla[m]> thank you gmann
16:52:41 <gmann> knikolla[m]: rosmaita you want me to go ahead on governance changes or wait more?
16:53:02 <rosmaita> gmann: i think go ahead
16:53:03 <gmann> I really want to close this task
16:53:13 <gmann> rosmaita: ok thanks
16:53:14 <spotz[m]> But they deployed that version of OpenStack so in the case it made sense
16:53:29 <knikolla[m]> I'm moving on directly to the vPTG agenda item. And skipping the 2 ones in between.
16:53:33 <gmann> +1
16:53:40 <knikolla[m]> #topic Virtual PTG Planning
16:53:49 <knikolla[m]> March 27-31, 2023, there's the Virtual PTG.
16:54:18 <knikolla[m]> #link https://etherpad.opendev.org/p/tc-2023-2-ptg
16:54:35 <knikolla[m]> We need to decide on the amount of time
16:54:41 <knikolla[m]> time
16:54:45 <knikolla[m]> and agenda items
16:55:11 <gmann> I think 4 hrs slots for two days work well in past PTGs
16:55:12 <knikolla[m]> Please propose agenda items in the etherpad above
16:55:22 <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:53 <gmann> any other feedback on 17-19 UTC slots?
16:56:10 <gmann> at least it worked fine for me to attend project specific discussion
16:56:39 <rosmaita> which just to be clear is a 3 hour block (ends at 2000, not 1900)
16:57:12 <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:17 <noonedeadpunk> Thursday/Friday works for me
16:57:25 <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:38 <gmann> rosmaita: I think it was 15-19 UTC
16:57:38 <noonedeadpunk> +1 ^
16:57:45 <gmann> not 20 UTC
16:58:01 <gmann> #link https://etherpad.opendev.org/p/tc-2023-1-ptg#L18
16:58:17 * dansmith has a hard stop in 70 seconds
16:58:20 <bauzas> that's the problem with virtual meetings, you have to fight the time differences + the personal reasons
16:58:41 <gmann> In last PTG, it ended at 19 UTC
16:58:43 <bauzas> pick anytime you want, I'll try to attend (hardly tho)
16:58:48 <rosmaita> ok, so we are just talking about two two-hour blocks
16:58:58 <slaweq> gmann 19 UTC is better for me :)
16:59:30 <knikolla[m]> I'm okay with the same times and days as last PTG.
16:59:31 <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:41 <gmann> 15-17 UTC as normal
16:59:52 <fungi> just be aware that scheduling discussion during the break defeats the purpose of having a break
16:59:58 <bauzas> and as a reminder, US and European daylight savings occur *before* the PTG, keep it in mind when you decide ;)
17:00:15 <knikolla[m]> after US, before European
17:00:18 <knikolla[m]> I think, no?
17:00:23 <slaweq> after EU
17:00:30 <bauzas> nope, europeans shift the sunday before the ptg
17:00:33 <slaweq> it will be just weekend before PTG
17:00:35 <knikolla[m]> After both, then, cool!
17:00:36 <gmann> +1
17:00:38 <fungi> us changes this weekend, eu changes two weeks later
17:00:46 <knikolla[m]> Alright, I'll schedule the times and send an email
17:00:54 <gmann> knikolla[m]: one more thing but we are on time
17:01:12 <gmann> do we want to schedule 'operator-hour' this time?
17:01:32 <bauzas> last time, nova operator hours were crickets.
17:01:42 <bauzas> despite heavy communication
17:01:44 <knikolla[m]> gmann: great question, we can talk about that in the channel after the meeting.
17:01:45 <gmann> or we can discuss it in next meeting as it might need more time to discuss
17:01:48 <knikolla[m]> I'm closing it now.
17:01:51 <gmann> knikolla[m]: sure
17:01:54 <spotz[m]> I did reach out to Kendall to maybe get a list of projects they want to meet with
17:02:00 <slaweq> thx, I have to go now
17:02:01 <slaweq> o/
17:02:13 <knikolla[m]> thanks spotz
17:02:18 <knikolla[m]> #endmeeting