| opendevreview | Ghanshyam proposed openstack/governance master: Retire patrole https://review.opendev.org/c/openstack/governance/+/880014 | 04:55 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/governance master: Retire puppet-rally - Step 3: Retire Repository https://review.opendev.org/c/openstack/governance/+/880018 | 06:09 |
| frickler | tc-members: johnsom mentioned in #-doc that most of the subpages on https://docs.openstack.org/2023.1.antelope/ are in a very bad state, I think mostly due to inconsistent release naming | 07:03 |
| slaweq | frickler where are the sources of those pages? | 07:05 |
| slaweq | sorry for that question but I never did anything with it | 07:06 |
| noonedeadpunk | and we have a tripleo there in deployment guides | 07:57 |
| noonedeadpunk | slaweq: it's https://opendev.org/openstack/openstack-manuals | 07:58 |
| noonedeadpunk | at least most of that | 07:58 |
| frickler | iiuc most pages are auto-generated from content in that repo | 08:36 |
| frickler | looking a bit deeper, it seems like www/project-data/2023.1.antelope.yaml is missing. comparing with previous cycles, it seems it should have been added with https://review.opendev.org/c/openstack/openstack-manuals/+/877304 | 08:39 |
| frickler | cf. https://review.opendev.org/c/openstack/openstack-manuals/+/859678 | 08:39 |
| frickler | oh, wait, my checkout wasn't current, there is https://review.opendev.org/c/openstack/openstack-manuals/+/877303 | 08:41 |
| frickler | hmm, seems something is broken in the live pages, then. https://9ec5b31508c5a60e9e8c-1a8ea1aab3e0f1d5273c349c5204e85c.ssl.cf5.rackcdn.com/877303/2/gate/build-tox-manuals-publishdocs/8edc5b9/docs/2023.1.antelope/projects.html has all the expected content, https://docs.openstack.org/2023.1.antelope/projects.html has nothing | 08:44 |
| frickler | the first broken build is https://review.opendev.org/c/openstack/openstack-manuals/+/877304 though I'm not sure how that could affect anything. might be some updated dependency | 08:53 |
| ttx | gmann: Let me know if my help is still needed on the virtualpdu thing. AFAICT https://github.com/openstack/virtualpdu is set up and should be synced next time a commit lands on the opendev side. Should I delete https://github.com/openstack-archive/virtualpdu ? | 12:41 |
| frickler | this might help with the docs: https://review.opendev.org/c/openstack/openstack-manuals/+/880049, in the long run, consistent naming would be helpful | 12:44 |
| frickler | still inconsistent, generates links like https://docs.openstack.org/designate/2023.1.antelope/admin/ instead of https://docs.openstack.org/designate/2023.1/admin/ | 13:25 |
| frickler | maybe this needs a huge redirect setup? | 13:26 |
| opendevreview | Merged openstack/project-team-guide master: Cover the branchless repo in deprecation process https://review.opendev.org/c/openstack/project-team-guide/+/880005 | 13:43 |
| *** spotz_ is now known as spotz | 14:00 | |
| clarkb | frickler: the indexes are generated by a tool in the openstack-manuals repo. Maybe it should just check for what various targets exist directly and add them that way rather than assuming a consistency across the board. THat said we should be able to assume a consistency across the board I think | 14:44 |
| frickler | clarkb: the tools is what my patch is trying to fix, just seems more complex than my initial idea | 14:45 |
| clarkb | frickler: I think the path under the project docs is based directly on what the git tag value is | 14:45 |
| clarkb | and the release team should enforce consistency on that that the docs index generation can expect? | 14:46 |
| frickler | in that case, naming everything 2023.1 instead of 2023.1.antelope would be the only path forward | 14:47 |
| frickler | seems we are talking about branch names here, not tags | 14:51 |
| clarkb | ah yup that makes sense | 14:51 |
| clarkb | but those are also centrally managed so should be consistent I hope | 14:51 |
| frickler | I can try to just update the series name in a patch, not sure what that would break, though | 14:52 |
| frickler | https://review.opendev.org/c/openstack/openstack-manuals/+/880060 | 14:54 |
| frickler | anyway, IMO the current situation is harming general openstack appearance to the public and should be tackled by tc-members with priority, feel free to pick up one of my patches or come up with a better solution | 14:56 |
| gmann | knikolla: ^^ I think it is good to add/discuss in today meeting. | 17:16 |
| gmann | ttx: thanks. yeah, I think we can delete openstack-archive/virtualpdu to avoid confusion https://github.com/openstack-archive/virtualpdu | 17:18 |
| knikolla | gmann: yes, adding to the agenda. | 17:31 |
| knikolla | tc-members: reminder that the weekly meeting is in 30 minutes | 17:31 |
| noonedeadpunk | yeah, now docs.openstack.org is just broken :( | 17:34 |
| gmann | noonedeadpunk: this is path added for 2023.1 right? https://docs.openstack.org/2023.1.antelope/ | 17:40 |
| noonedeadpunk | If you open https://docs.openstack.org/ it will redirect wrongly now | 17:40 |
| gmann | ah right | 17:41 |
| noonedeadpunk | I assume as result of merge 880060 | 17:41 |
| noonedeadpunk | there's already a revert | 17:41 |
| gmann | yeah, just +A on that let's see | 17:41 |
| knikolla | #startmeeting tc | 17:59 |
| opendevmeet | Meeting started Tue Apr 11 17:59:31 2023 UTC and is due to finish in 60 minutes. The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:59 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:59 |
| opendevmeet | The meeting name has been set to 'tc' | 17:59 |
| knikolla | #topic Roll call | 17:59 |
| noonedeadpunk | o/ | 17:59 |
| knikolla | Hi all, welcome to the weekly meeting of the OpenStack Technical Committee | 17:59 |
| knikolla | A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct | 17:59 |
| knikolla | o/ | 17:59 |
| jamespage | o/ | 18:00 |
| dansmith | o/ | 18:00 |
| gmann | o/ | 18:00 |
| slaweq | o/ | 18:00 |
| knikolla | We have JayF noted under absences for today. | 18:00 |
| spotz | o/ | 18:00 |
| * slaweq will probably need to leave a bit earlier today | 18:01 | |
| knikolla | thanks for the heads up! | 18:01 |
| knikolla | If I'm not mistaken we're missing rosmaita from the roll call | 18:02 |
| rosmaita | oops | 18:03 |
| rosmaita | o? | 18:03 |
| rosmaita | i mean o/ | 18:03 |
| knikolla | \o/ | 18:03 |
| knikolla | #topic Follow up on past action items | 18:03 |
| slaweq | :) | 18:03 |
| knikolla | I had an action to create a new TC tracker for 2023.2 | 18:03 |
| knikolla | As I was on vacation last week, I have not completed that action. | 18:04 |
| knikolla | No other action items come to mind excepting the PTG items. So moving on to the next topic. | 18:05 |
| gmann | there is one for JayF #link https://meetings.opendev.org/meetings/tc/2023/tc.2023-03-22-16.00.html | 18:05 |
| gmann | whichis completed | 18:06 |
| knikolla | Yes, I think we discussed that during the PTG. | 18:06 |
| gmann | yeah | 18:06 |
| knikolla | If I'm not mistaken. | 18:06 |
| knikolla | #topic Gate health check | 18:07 |
| knikolla | Any updates on the situation of the gate? | 18:07 |
| dansmith | not super healthy | 18:07 |
| dansmith | hard to point the finger to one thing | 18:07 |
| dansmith | although I will say that there was a recent u-c bump for PasteDeploy | 18:07 |
| dansmith | which broke glance's functional tests hard, | 18:07 |
| dansmith | and have been broken for several weeks now, but it was just discovered | 18:07 |
| noonedeadpunk | We've seen post failures lately related to slow swift backends I assume | 18:08 |
| dansmith | I think there's a todo item there to get glance's functional tests into the u-c gate, but I might be wrong | 18:08 |
| dansmith | noonedeadpunk: I've seen several such post failures as well | 18:08 |
| gmann | yeah there were few post failure last week | 18:09 |
| slaweq | I have seen it once or twice too | 18:09 |
| knikolla | Any action items that we want to circle back on during next weeks meeting? | 18:12 |
| dansmith | nothing specific to address at the moment I think | 18:13 |
| dansmith | (which is not a good place to be) | 18:13 |
| knikolla | Great to hear! | 18:13 |
| dansmith | um... | 18:13 |
| knikolla | I misread that, sorry. | 18:14 |
| knikolla | Are there any exploratory items we can take to reach out with the teams? | 18:14 |
| dansmith | I've seen a number of guest kernel crashes on volume-based tests lately, | 18:15 |
| dansmith | but I dunno what to do about those | 18:15 |
| dansmith | they might be qemu things we have less control over | 18:15 |
| slaweq | dansmith what guest image are You using? | 18:15 |
| clarkb | are they overriding to enable nested virt? | 18:15 |
| dansmith | I guess we need to "explore" how to avoid breaking glance functional tests with further u-c bumps :) | 18:15 |
| clarkb | someone was looking at nested virt crashes on vexxhost I think | 18:16 |
| dansmith | slaweq: just cirros in the usual jobs | 18:16 |
| slaweq | I think we have seen many of kernel panics with Cirros 0.5.x IIRC | 18:16 |
| slaweq | but with 0.6.1 it's better | 18:16 |
| dansmith | slaweq: yeah | 18:16 |
| gmann | dansmith: adding job there can help as requirement gate is good to wait if more thigns to fix before u-c bump | 18:16 |
| dansmith | apparently 0.6.1 changes a lot about dhcp/network though so we saw worse behavior with 0.6 | 18:16 |
| slaweq | there's different dhcp client used but tempest supports that already | 18:17 |
| slaweq | we are using it in neutron ci job and it's fine for us | 18:17 |
| gmann | slaweq: dansmith: I think we did revert the 0.6 in devstack, should we bump version there? | 18:17 |
| dansmith | slaweq: yeah, bauzas tried using 0.6 and saw lots (more) failures | 18:17 |
| dansmith | slaweq: hmm, okay | 18:17 |
| slaweq | ahh, ok | 18:17 |
| gmann | ah i remember failure with 0.6 and reverted to use 0.5 in devstack. | 18:18 |
| dansmith | yeah | 18:18 |
| knikolla | Got it. I'll write this down when sending the weekly summary of the TC, to see if someone else has any ideas or run into the same things. | 18:18 |
| slaweq | maybe frickler can help with cirros issues thene | 18:19 |
| slaweq | *then | 18:19 |
| noonedeadpunk | I think it was when Qemu/KVM<4.2, and its generic kernel version <5.4 | 18:19 |
| dansmith | ...moving on? | 18:21 |
| gmann | yeah, we can move on | 18:21 |
| slaweq | ++ | 18:21 |
| knikolla | #topic 2023.2 cycle Leaderless projects | 18:21 |
| knikolla | #link https://etherpad.opendev.org/p/2023.2-leaderless | 18:22 |
| gmann | we have few changes from what we discussed in PTG | 18:22 |
| gmann | first sahara: | 18:22 |
| gmann | we decided to retire it but there is volunteer now to lead this project. Jerry from Inspur company. | 18:22 |
| gmann | they would like to maintain it | 18:22 |
| gmann | #link https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033254.html | 18:22 |
| gmann | even in last cycle also and what tosky mentioned in PTG that there is PTL volunteer in last cycle also but project is not maintained | 18:23 |
| gmann | we might see this situation this cycle also but denying their request also does not looks good | 18:23 |
| gmann | I think we can try for this cycle also and accept their PTL request ? | 18:24 |
| knikolla | Can we "approve with conditions"? | 18:24 |
| noonedeadpunk | I'd give them a chance. I think gates should be relatively okeyish - at least last time I checked/fixed them they were not that bad. | 18:24 |
| jamespage | I was about to ask the same | 18:24 |
| gmann | conditions on what? | 18:24 |
| noonedeadpunk | Release patches are passing at least, but not reviewed | 18:24 |
| gmann | we can always retire any project if it goes to inactive right ? | 18:24 |
| rosmaita | i think we can point out to them that they need to start thinking about PTL earlier this cycle | 18:24 |
| slaweq | ++ | 18:24 |
| gmann | If we do not retire and accept their PTL then we can monitor it like any other project | 18:25 |
| gmann | rosmaita: yeah, i mentioned about project actual mainteince also in email and it is not just be a PTL | 18:25 |
| knikolla | Yeah... it's really hard to define any sort of condition | 18:25 |
| rosmaita | what was the "tech preview" status for existing projects? | 18:25 |
| gmann | I remember gate was broken and noonedeadpunk or tosky fixed it to get it release ? | 18:26 |
| noonedeadpunk | yup | 18:26 |
| noonedeadpunk | It was that https://review.opendev.org/c/openstack/sahara/+/864728 | 18:26 |
| slaweq | rosmaita it's not "tech preview" but "inactive" project IIRC | 18:26 |
| gmann | we can check if their gate is broken and they are not fixing it then move it under Inactive project ? | 18:26 |
| rosmaita | slaweq: yes, that's what i was thinking of | 18:27 |
| noonedeadpunk | well, it's green now | 18:27 |
| noonedeadpunk | from what I see | 18:27 |
| gmann | but we need to decide on release things by m-1 so monitor closely | 18:27 |
| knikolla | sure | 18:28 |
| gmann | let's not retire and inspur showing interest in this but if we end up with no maintained situation in this cycle also then we can retire it before we ask for PTL in next cycle >? | 18:28 |
| rosmaita | gmann: can we make it inactive before retiring? | 18:29 |
| noonedeadpunk | We also should be explicit that they musrt review patches and ensure gate state in ML | 18:29 |
| gmann | rosmaita: sure, that is good flow. we can do that | 18:29 |
| rosmaita | i finally found the doc about that: https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html | 18:29 |
| gmann | noonedeadpunk: +1, I can mention it explicitly in email as well as in their PTL appointment patch | 18:29 |
| gmann | rosmaita: :) | 18:29 |
| noonedeadpunk | as otherwise they have big risk of Antelope being their last release | 18:30 |
| gmann | yeah | 18:30 |
| knikolla | so, inactive and then circling back to decide if to release or retire on M-1? | 18:30 |
| gmann | you mean marking inactive now ? or if their gate is broken and no maintenance from PTL/team ? | 18:30 |
| noonedeadpunk | I think we're monitoring, if they don't do a thing - then yes | 18:31 |
| gmann | yeah, let's not mark inactive now but we can monitor it closely | 18:31 |
| slaweq | IIRC we should monitor it and mark as inactive before M-2 if it will not be in good shape | 18:31 |
| gmann | yeah | 18:32 |
| rosmaita | how about let them know they need to find a PTL before election time this cycle or they go to inactive and the clock starts for retirement | 18:32 |
| spotz | I like that idea | 18:33 |
| gmann | rosmaita: yeah, many project miss the PTL nomination deadline and shows up after that | 18:33 |
| gmann | but yes, mentioning all those things to them is good idea | 18:33 |
| spotz | But for an inactive project I think making sure they have someone on time shows at least some forward progression | 18:33 |
| knikolla | It's not only about just having a PTL, but also about keeping the gate working, and releases flowing. | 18:33 |
| gmann | yeah, and that is what expected from someone volunteer for PTL | 18:34 |
| knikolla | I feel like marking the project as inactive gives us a way to mark something as "being actively monitored" | 18:34 |
| gmann | to make sure project is maintained | 18:34 |
| rosmaita | well, i figure the PTL will handle that stuff ... i think maybe inspur needs a fire lit under their butt to allocate time for the project | 18:34 |
| knikolla | since exiting the inactive state requires fulfilling the criteria for being accepted as an official project. | 18:34 |
| noonedeadpunk | "keeping the gate working, and releases flowing" + , and patches reviewed | 18:34 |
| gmann | knikolla: not as such, inactive is state where project is failed gate, cannot merge patches or so. monitoring is different when their gate is up | 18:35 |
| knikolla | per the resolution introducing the emerging and inactive states. "inactive state for existing projects that are not so active anymore" | 18:35 |
| knikolla | there's nothing there saying that a project must be hard-failing. | 18:35 |
| gmann | "For existing projects which became inactive due to lack of maintainers and are not able to do the mandatory activities, such as release, fix testing, review incoming code, etc., " | 18:36 |
| knikolla | "are not able to do the mandatory activities, such as release, fix testing, review incoming code, etc., TC can consider marking such projects as inactive" | 18:36 |
| knikolla | we have fixed their testing. | 18:36 |
| gmann | this is entry criteria #link https://governance.openstack.org/tc/reference/emerging-technology-and-inactive-projects.html#entry-criteria | 18:36 |
| gmann | yeah it is not broken now. it is green | 18:37 |
| gmann | either we could have moved them to inactive before fixing the testing or need to wait if it happen again and no one there to fix it | 18:37 |
| knikolla | i'll drop the subject if i'm the only one thinking we should mark it as inactive now, rather than wait for later. | 18:38 |
| knikolla | alright. then we'll keep an eye out for Sahara and if something breaks or the situation changes we'll mark them as inactive during M-1 or M-2. | 18:40 |
| noonedeadpunk | I think we should not mark inactive now. But we can always vote :) | 18:40 |
| slaweq | noonedeadpunk++ | 18:40 |
| knikolla | No it's alright, I was the only one pushing for it. | 18:42 |
| knikolla | So gmann, can you respond to the PTL volunteer telling them to propose a patch to become Sahara PTL? | 18:42 |
| * slaweq needs to drop, I will read through log later | 18:42 | |
| slaweq | o/ | 18:42 |
| gmann | sure. I will explain all those work needed in email reply as well as asking them to propose governance patch for PTL assignment | 18:42 |
| gmann | knikolla: yeah | 18:42 |
| gmann | next leaderless project and we decide to retire is Winstackers | 18:42 |
| knikolla | #action gmann respond to Sahara PTL volunteer to propose a patch to governance, and explain the outcome of today's discussion | 18:43 |
| gmann | +1 | 18:43 |
| gmann | there is good question from tkajinam about window support in OpenStack if we retire this project #link https://lists.openstack.org/pipermail/openstack-discuss/2023-April/033273.html | 18:43 |
| gmann | retirement means all those dependent functionality also gone. | 18:43 |
| gmann | I am not sure if we need to find any alternate implementation for window support or try to find someone to maintain this project ? | 18:44 |
| knikolla | ugh :/ I'm sure there's plenty of clouds that depend on Windows VMs as a use case. | 18:44 |
| dansmith | hmm, I wonder if that's a dep of the hyperv driver in the case of nova? | 18:44 |
| gmann | also not sure if any other company than cloudbase was interested window support in openstack | 18:44 |
| gmann | dansmith: yes | 18:44 |
| dansmith | knikolla: not sure this has any effect (other than optics) on vm support | 18:44 |
| rosmaita | all the windows CI was run by cloudbase, is that correct? | 18:45 |
| clarkb | gmann: there have definitely been people asking about windows support recently. For example with amd + windows being broken in nova | 18:45 |
| dansmith | yeah looks like just the hyperv driver | 18:45 |
| gmann | dansmith: need to check hyperV deps but not sure if that driver is maintained by anyone else than cloudbase people | 18:45 |
| dansmith | gmann: not sure it's really maintained at all, tbh | 18:45 |
| dansmith | but never anyone other than them that I know of | 18:45 |
| gmann | yeah. | 18:45 |
| noonedeadpunk | Yeah, I don't think it's about guests | 18:46 |
| TheJulia | Seems like something each project will need to look at and consider after consulting with their operator base, in the grand scheme of things. | 18:46 |
| dansmith | last patch in 202 | 18:46 |
| dansmith | er, 2020 | 18:46 |
| gmann | humm. also not sure what is state of hyperV 3rd part Ci | 18:47 |
| dansmith | non-existent AFAIK | 18:47 |
| dansmith | although maybe it still runs on virt/hyperv, but I haven't noticed it in forever | 18:47 |
| gmann | i can see here but failing https://review.opendev.org/c/openstack/nova/+/852087 | 18:47 |
| gmann | Cloudbase Nova Hyper-V CI | 18:47 |
| knikolla | If it's been failing for a while, and this doesn't affect in any way guest VMs but only HyperV hypervisors, the situation is a bit different. | 18:48 |
| gmann | but yes, it has deps from many projects and its question about what they want to do with this window support/users | 18:48 |
| dansmith | last time I saw their CI run was 23 weeks ago | 18:49 |
| knikolla | So the path forward is: 1) ask operators about windows support 2) ask projects to remove os-win dependencies, or make them soft dependencies 3) retire winstackers? | 18:51 |
| dansmith | I think they're soft deps already IIRC, at least for nova | 18:51 |
| gmann | yeah, it needs to be removed completely as os-win deps but project can find alternate implementation if needed ? | 18:52 |
| dansmith | oh I see this: https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html | 18:52 |
| spotz | That the one from earlier? | 18:52 |
| dansmith | no more ci, no more cloudbase working on openstack it seems | 18:52 |
| gmann | dansmith: yeah in nov they announced, I also missed that | 18:52 |
| dansmith | yeah me too | 18:52 |
| spotz | NM november:) | 18:52 |
| jamespage | I can't see a response to that statement from Lucian | 18:53 |
| dansmith | so I guess that means nova should be working to remove hyperv from the tree | 18:53 |
| noonedeadpunk | Yeah, I do remember it:) | 18:53 |
| gmann | jamespage: yeah, no response and that is why I was thinking no one interested in window support ? but same time we cannot say openstack-discuiss ML is perfect place to get all the ansers | 18:53 |
| gmann | answer | 18:53 |
| gmann | dansmith: I think so | 18:54 |
| knikolla | seems like the approach i outlined above still works, but with removing os-win entirely rather than just a soft dependency. | 18:54 |
| gmann | I am more concern on 1st one. how to reachout to operators and how much time we need to get those answer from them ? | 18:54 |
| jamespage | does last user survey have anything on this subject? | 18:54 |
| gmann | openstack-discuss ML is not perfect place to reachout to them | 18:55 |
| dansmith | cern was using hyperv at one point | 18:55 |
| dansmith | it was a long while ago, not sure if they still are or not | 18:55 |
| spotz | arne_wiebalck: ^ | 18:56 |
| jamespage | 2022 - 2% of deploys on HyperV | 18:56 |
| dansmith | oof | 18:56 |
| gmann | we can try to announce/notify it in June event and then decide on retirement things. do not start retirement for now ? | 18:57 |
| knikolla | Agree on not starting requirement now | 18:57 |
| gmann | and starting the email announcement now including on openstack-annouce ML | 18:58 |
| knikolla | But we need to start introducing the subject through mailing list, as that will affect operators and projects. | 18:58 |
| knikolla | gmann++ | 18:58 |
| gmann | yeah | 18:58 |
| gmann | we can try in all those places and try final in June event. if nothing comes up then retirement is only option | 18:59 |
| knikolla | ++ | 18:59 |
| jamespage | sounds sensible | 18:59 |
| knikolla | any volunteers to write the email? | 18:59 |
| knikolla | I can do it then. | 18:59 |
| knikolla | We're out of time, thanks all. | 19:00 |
| jamespage | I'm happy to give that a go | 19:00 |
| knikolla | jamespage: awesome, thanks :) | 19:00 |
| gmann | oh, we missed doc things which is important to fix | 19:00 |
| jamespage | will ask for a pre-send review knikolla | 19:00 |
| knikolla | #action jamespage to write email about Winstackers removal | 19:00 |
| knikolla | :) | 19:00 |
| knikolla | We can continue outside of the meeting gmann | 19:01 |
| knikolla | #endmeeting | 19:01 |
| opendevmeet | Meeting ended Tue Apr 11 19:01:04 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:01 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-11-17.59.html | 19:01 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-11-17.59.txt | 19:01 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-04-11-17.59.log.html | 19:01 |
| spotz | Thanks all! | 19:01 |
| gmann | jamespage: please send on opentack-announce also along with openstack-discuss | 19:01 |
| gmann | thanks | 19:01 |
| jamespage | gmann: ack | 19:01 |
| jamespage | thanks all | 19:01 |
| rosmaita | just wanted to mention that i took the liberty of revising the paragraph about office hours on the agenda wiki page | 19:01 |
| rosmaita | here's the diff if anyone is interested/concerned or wants to edit it some more | 19:01 |
| rosmaita | https://wiki.openstack.org/w/index.php?title=Meetings%2FTechnicalCommittee&type=revision&diff=183019&oldid=183018 | 19:01 |
| knikolla | @rosmaita ah, good catch! | 19:02 |
| gmann | rosmaita: or we can just remove that paragrah itself as no office hour things since long | 19:02 |
| gmann | rosmaita: i mean remove mentioning of office hour not full para | 19:02 |
| rosmaita | well, since we used to do it at one point, probably good to explicitly say that we don't any more | 19:03 |
| gmann | ok but we stopped it I think since 1 year or longer maybe | 19:04 |
| gmann | anyways thanks for noticing and fixing it | 19:04 |
| rosmaita | np | 19:04 |
| knikolla | I like the revision, thanks rosmaita | 19:05 |
| knikolla | gmann: trying to catch up on the discussion about docs being broken. the cause is the inconsistency between projects? | 19:06 |
| * bauzas is sad to not able to attend the TC meetings now :( | 19:07 | |
| gmann | knikolla: I have not debugged/detailed it but just saw frickler message here about it and agree that we should fix it on priority as antelope is released and many users might be seeing doc | 19:07 |
| knikolla | ++ 100% agree | 19:08 |
| bauzas | for hyper-v, I'm sorry I wasn't able to be discussing about this on the meeting | 19:09 |
| knikolla | bauzas: we can still discuss about all of that in the channel here outside of the meeting | 19:11 |
| knikolla | there's very few decisions that are ever made during the meetings | 19:12 |
| knikolla | bauzas: does it feel like it's hard to engage with the TC if unable to attend the weekly meeting? | 19:14 |
| bauzas | knikolla, sure but in general, I prefer to attend a synced discussion | 19:15 |
| bauzas | anyway, the boat is sailed | 19:15 |
| bauzas | has* | 19:16 |
| knikolla | bauzas: That's what I'm trying to achieve, it not to feel like the boat has sailed. We're still here on the channel and we can still discuss the topic if you have something you want to bring about the topic. | 19:18 |
| knikolla | Most people monitor the channel and do respond at odd hours, so synced discussions are possible. | 19:19 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!