| *** bauzas_ is now known as bauzas | 01:12 | |
| gmann | gouthamr: sorry for missing today meeting. I was out of town but thought of attending it but could not connect due to poor internet connection. | 01:42 |
|---|---|---|
| opendevreview | Ghanshyam proposed openstack/governance master: Reset the DPL model for Freezer project https://review.opendev.org/c/openstack/governance/+/925830 | 03:01 |
| opendevreview | Ghanshyam proposed openstack/governance master: Reset the DPL model for Watcher project https://review.opendev.org/c/openstack/governance/+/925831 | 03:04 |
| opendevreview | Ghanshyam proposed openstack/governance master: Reset the DPL model for Release management project https://review.opendev.org/c/openstack/governance/+/925832 | 03:08 |
| opendevreview | Ghanshyam proposed openstack/governance master: Reset the DPL model for Requirement project https://review.opendev.org/c/openstack/governance/+/925833 | 03:11 |
| opendevreview | Ghanshyam proposed openstack/governance master: Reset the DPL model for Oslo project https://review.opendev.org/c/openstack/governance/+/925834 | 03:14 |
| gmann | tc-members As next cycle technical election is approaching ^^ resetting the DPL model liaisons list. please review | 03:24 |
| frickler | I wonder if I really need to restate every time that I won't join Zoom meetings, would be nice if there was a way to document that permanently | 04:53 |
| frickler | I also don't feel comfortable being around just on IRC during these meetings fwiw | 04:54 |
| frickler | gmann: commented on https://review.opendev.org/c/openstack/governance/+/925833/1 but maybe this warrants another more general discussion (cc tc-members) | 05:11 |
| elodilles | gouthamr: no plans yet | 07:33 |
| *** bauzas_ is now known as bauzas | 07:36 | |
| opendevreview | Tony Breeds proposed openstack/governance master: Revert "Reset the DPL model for Requirement project" https://review.opendev.org/c/openstack/governance/+/925850 | 08:53 |
| *** bauzas_ is now known as bauzas | 08:57 | |
| frickler | tc-members: I'm not sure where we last had a discussion about dropping py3.8 support, but I know some people at least claimed it would need openstack-wide coordination. cf. https://review.opendev.org/c/openstack/openstacksdk/+/923662 and https://review.opendev.org/c/openstack/python-openstackclient/+/924493 | 11:20 |
| frickler | also the latest OSC release has multiple regressions that people may want to look out for https://bugs.launchpad.net/python-openstackclient/+bug/2076229 and https://bugs.launchpad.net/python-openstackclient/+bug/2076212, also blocking its adoption into u-c | 11:22 |
| *** tkajinam is now known as Guest2415 | 12:52 | |
| *** tkajinam is now known as Guest2416 | 13:00 | |
| opendevreview | Slawek Kaplonski proposed openstack/election master: Add email template for direct reminder about nomination deadline https://review.opendev.org/c/openstack/election/+/925873 | 13:51 |
| *** whoami-rajat_ is now known as whoami-rajat | 13:56 | |
| gmann | frickler: thanks, replied on release as well as requirement changes. | 17:04 |
| gmann | for py3.8 drop, I think we can send email to projects top start dropping the py3.8 and in next cycle early we plan to drop from oslo/lib and requirement | 17:04 |
| gmann | this way we can give enough time to projects or discuss if any strong objection on dropping (like we faced in py3.6 case) | 17:05 |
| *** bauzas_ is now known as bauzas | 18:15 | |
| *** bauzas_ is now known as bauzas | 18:26 | |
| *** bauzas_ is now known as bauzas | 19:36 | |
| gouthamr | gmann: (late ack) hey np! i just uploaded the meeting recording to our channel: https://youtu.be/HZhY9pxezWo | 21:13 |
| gouthamr | > I wonder if I really need to restate every time that I won't join Zoom meetings, would be nice if there was a way to document that permanently | 21:14 |
| gouthamr | frickler: ack; i'll keep that in mind.. some of my mentions aren't direct pings; i reference nicks while taking notes and didn't mean to really alert you/ask questions | 21:14 |
| * gouthamr hmmm, a revert commit for something that's not yet merged :D | 21:17 | |
| gouthamr | gmann: in case you have an active participation from the DPL teams, and the TC liaisons say things are going well, do we really need the per-cycle reinstatement of the DPL liaisons? seems like you agree with tonyb's argument | 21:19 |
| gouthamr | if we don't, i want to see if we can remove that requirement from our charter.. i think this was done with good intentions, but, maybe we added a couple of redundant checks at once.. i wonder if, we can float a "reinstate DPL" patch for each team and have all liaisons +1 | 21:21 |
| gouthamr | its less intrusive than resetting the list and have someone propose the same list again | 21:21 |
| gouthamr | wdyt? | 21:21 |
| gmann | gouthamr: it is hard to keep them up to dated then even TC liaisons are there. For now it might work but later it might not. I have experienced it in project health tracking TC liaisons cases. Instead of removing the requirement, I will add the option of -1 on reset change by all liaisons can avoid reset. | 21:34 |
| gmann | otherwise we should reset it. example release team where there will be change in liaisons and these reset help such changes. | 21:35 |
| gouthamr | gmann: ah; that would give us the same outcome | 21:35 |
| gouthamr | gmann: so the I shouldn't treat these as "project-updates", correct? if the TC has two positive roll-call votes, i'd still ignore them if the liaisons -1 it | 21:37 |
| gmann | 'reinstate DPL' can hang us for long time like Inactive/active state change does and we always wait for the PTL to get +_1 | 21:37 |
| gmann | +1 | 21:37 |
| gmann | gouthamr: if all liaisons is -1 means we got confirmation from all of them and we can abandon it | 21:37 |
| gmann | if not all liaisons -1 then we should still reset it | 21:38 |
| gouthamr | gmann: ack, what if these liaisons are out between now and the election period? can we go proxy votes too, here? | 21:39 |
| gmann | gouthamr: I think that is same as candidates on vacation during election time and miss PTL nomination. We see such cases in every election. If there is any such case we can still handle them after election as leaderless project and liaisons can move them to DPL | 21:40 |
| gmann | but proxy vote is also not bad as we can get to know if liaisons is active or not once they return back | 21:41 |
| gmann | we can give them exception if one liaisons confirm the other liaisons continuity | 21:44 |
| gouthamr | ^ +1 i think that'd allow flexibility | 21:44 |
| gouthamr | and i like the -1 approach; its the path of least resistance :) | 21:45 |
| gouthamr | i.e., these current "Reset the DPL model for <x>" can be -1'ed by the liaisons, and we'd not reset.. | 21:46 |
| gouthamr | liaisons have until the end of the election cycle to -1 this change | 21:46 |
| gouthamr | is this understanding correct? | 21:46 |
| gouthamr | s/election cycle/election period | 21:47 |
| gmann | not end of election it should be done before start of the election nomination otherwise we will be giving duplicate work for election official. TC should have clear list of projects running in that election. | 21:47 |
| gouthamr | hmm, yes, but that gives everyone under a week | 21:50 |
| gouthamr | btw, we've already generated the list of projects | 21:52 |
| gouthamr | https://review.opendev.org/c/openstack/election/+/925707 | 21:52 |
| gouthamr | this affects 5 teams: oslo, requirements, freezer, watcher and release-management | 21:53 |
| gmann | yeah, that is why it needs to be before nomination start. if any poroject move to PTL model then we can add them in election | 21:55 |
| gouthamr | i saw comments in all of these patches (except oslo) from at least one liaison stating that they'd like to keep the DPL model.. so, i'm hoping we can encourage -1s and abandon all of these changes. If hberaud's role changes within the release-mgmt, i think it can be a separate change.. (there're two other release management liaisons for the release-management team) | 21:58 |
| gmann | yeah, I sent those in ML. pinged oslo team in oslo channel. let's see how soon we can get response. | 22:00 |
| gmann | I am ok either way if release team want to reset the state of update the liaisons as per next cycle planning | 22:01 |
| gouthamr | gmann: nice; thank you.. | 22:01 |
| gouthamr | er; sorry if i feels like we're going in circles about something though... should we add "-1s to reset patch will suffice" to the charter now? | 22:06 |
| opendevreview | Ghanshyam proposed openstack/governance master: Update DPL model reset steps https://review.opendev.org/c/openstack/governance/+/925926 | 22:09 |
| gouthamr | perfect; thank you | 22:09 |
| gmann | gouthamr: ^^ it is not in charter but DPL doc, check if it looks ok | 22:09 |
| * gouthamr \m/ not being in the charter :) | 22:10 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!