| mharley[m] | Hello, gouthamr . Just saw your message sent on the meeting yesterday. We do actually have a dedicated PQC channel: #_oftc_#openstack-pqc:matrix.org . :-) | 10:16 |
|---|---|---|
| mharley[m] | I'm planning to make some movement there by next week (possibly Wednesday). | 10:17 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: wip https://review.opendev.org/c/openstack/openstack-manuals/+/989373 | 12:39 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: wip https://review.opendev.org/c/openstack/openstack-manuals/+/989373 | 12:41 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Replace deprecated openstackdocstheme options https://review.opendev.org/c/openstack/openstack-manuals/+/989373 | 12:42 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Replace deprecated openstackdocstheme options https://review.opendev.org/c/openstack/openstack-manuals/+/989373 | 12:43 |
| fungi | mharley[m]: you still haven't followed up on https://review.opendev.org/c/openstack/project-config/+/988770 though | 13:13 |
| mharley[m] | Goot callout, fungi . I'll work on it. | 13:35 |
| sean-k-mooney | hi folks, before i go through the project creation steps to create a new cyborg-extra repo i just want to sanity check the logic behind having a spereate repo. i have two general usecase for it that are somewhat conflicting but the second is somewhat speculative anyway | 15:02 |
| sean-k-mooney | usecase number 1 is i have a prototype kernel module that im buidlign purly for ci and dev to allow testing cybrog withotu real hardware | 15:03 |
| sean-k-mooney | this being a kernel moudle built form the kernels exmaple code woudl be GPLv2 licenced as a result | 15:03 |
| sean-k-mooney | so i knid of want to put that in its own repo to the side rather then in the main cybrog one | 15:04 |
| sean-k-mooney | the secodn usecase is many of the current cybrog driver have no docs or tests and are mostly incompelte | 15:05 |
| sean-k-mooney | the slightly conflicting usecase woudl be that instead fo deletign them if we can find supprot to maintian team woudl be to move them to cyborg-extra more as a contib space | 15:05 |
| sean-k-mooney | usecase 1 is my primary objective but i was wonderign if we really need that level of sepreation or is it fine just to have a spereat folder | 15:06 |
| sean-k-mooney | for the kernel module in the cybrog repo that we do not package or distibute | 15:06 |
| fungi | the main reasons to have a separate repo are: you want different people responsible for reviewing/approving changes, you want it tagged/released independently, or you want separate installable packages for it | 15:07 |
| sean-k-mooney | eventually i might consider tryign to upstream it to the actual kernel but for now while im builting out the feature set we need for testign i want to keep it hosted on opendev.org | 15:07 |
| sean-k-mooney | fungi: right so i do not want to package/distirbute it adn teh reviewer woudl likely be the same | 15:08 |
| sean-k-mooney | so in that case woudl just having the approate liscen herader adn puting it in its own folder in the cybrog repo be enough | 15:08 |
| fungi | also if you *think* it's likely to fall into one of those categories later, separating it preemptively can be less messy than trying to untangle all the commit history down the road | 15:09 |
| fungi | but yeah, if none of those fit then keeping it in your main repository is likely fine | 15:09 |
| sean-k-mooney | i think the only possibel change i see in maintaienrship or distibution woudl be if i was to upstream it as a sample kernel module to linux itself | 15:10 |
| clarkb | I think you can also tell setuptools to not include the files in your python package if you keep it in one repo | 15:11 |
| clarkb | (since in theory you don't ened the kernel source unbuilt in a python package) | 15:11 |
| sean-k-mooney | clarkb: yes i dont thinkt hat would be a probelem even in our current config | 15:11 |
| sean-k-mooney | we are suign the find files package to fine the files related to the python package | 15:12 |
| sean-k-mooney | that does nto include the devstack foler for example to my knoladge | 15:12 |
| sean-k-mooney | i coudl certnely check that with a locak package build either way | 15:12 |
| clarkb | if you use pbr I think anything committed to git is included by default | 15:12 |
| sean-k-mooney | ack ok so that is somethign for me to verify | 15:13 |
| fungi | basically do a file listing of the tarball from pypi to see if things you think are excluded aren't | 15:15 |
| fungi | you can also use unzip or 7z to get a file listing from a wheel if you want to compare one of those as well | 15:16 |
| sean-k-mooney | ack, ya ill do both, i have a devstack plugin that can automaticlly compile it, inject it and configure nova/cybrog to use it that work on ubutnu 26.04, i was just adding debian-13 supprot and im debating if i want ot supprot c10s or ubuntu noble. once i have that asn some other local cleanup done i was going to look at hooking it into ci to see if it woudl work there as | 15:18 |
| sean-k-mooney | expected | 15:18 |
| sean-k-mooney | the only other reaosn to have it in its own repo is it a tiny bit simpler to resue in nova howver nova has a cybrog job and i can jsut make it so that the cybrog devstack plugin can provide this without needing to deploy cyborg if nova want to use it in a job without cybrog itself | 15:19 |
| sean-k-mooney | ill review the package builds locally and teh one on pypi and confirm this all works the way we expect and tha ti can filter it out | 15:20 |
| sean-k-mooney | thanks for the input | 15:20 |
| clarkb | I like to open the files with vim | 15:20 |
| clarkb | it gives you a nice browseable interface and works with jars/wars, sdists, wheels, etc | 15:21 |
| sean-k-mooney | i do the same with kde's archive manager quite often | 15:21 |
| sean-k-mooney | it was really a nice impvoemnt when that got cpio? supprot and i could jsut brows an rpm or deb package | 15:21 |
| fungi | these days i typically use `7z l archive.whl | grep 'what i want to check'` (or .tar.gz since it will handle both) | 15:22 |
| fungi | though `tar tf archive.tar.gz` and `unzip -l archive.whl` are also ingrained in my finger memory | 15:23 |
| sean-k-mooney | yep i have done it with unzip beofre but i generally have to check the man pages for tar every time i try to use it | 15:23 |
| sean-k-mooney | tar -xvf is the only tar command i remember | 15:24 |
| fungi | t is the tar action for listing contents whereas x extracts them and then you're left cleaning up afterward | 15:29 |
| sean-k-mooney | yes... t for list i see the went with the last later | 15:30 |
| sean-k-mooney | i dont like a lot a things about gnu as an organsiation but i do like there command line convertosn with a singel `-` for short opts and `--` for long and attempt to use numics where it makes sense | 15:31 |
| sean-k-mooney | tar/find/ps all have some bsd heritage | 15:32 |
| sean-k-mooney | so i knwo why they dont really follwo that | 15:32 |
| sean-k-mooney | but i kind of forget/ignore that the - is nto requried | 15:32 |
| fungi | i use a lot of bsd as well as sysv-inspired platforms, so am accustomed to the differences | 15:33 |
| sean-k-mooney | fungi: by the way i woudl like to just rasie a diffent issue breifly. id dont really mind consilitayt the resleae leason toolign into a common place but i still woudl liek use to revisit the liaoson reset every cycle and discontinue it if possibel and not extend tha tot plt based project as part of this move | 15:45 |
| sean-k-mooney | we do the reset at a really incovenitnt time in the cycle before the election when we are also prepaing for the cordiated release | 15:46 |
| sean-k-mooney | and it jsut create a lot of addtional papepwork for floks when we are already quite busy | 15:46 |
| sean-k-mooney | so i woudl hope we can fidn a better way then reseting the liasons by default | 15:47 |
| sean-k-mooney | to knwo if a project is active | 15:47 |
| sean-k-mooney | in the ptl model the ptl is empored to deligate the release duties to leasosn and apointing a leason just required the ptl to endorce the patch and the release team to review it | 15:49 |
| sean-k-mooney | movign the file to the covernace repo will change that very slightly in that it will need a tc member ot actully do the merge | 15:49 |
| sean-k-mooney | for the dpl model it was slightly differnet as there i no natural project laion ot have the ablity to apoint the others. perhaps the tract leasion or the newer tc laison but the latter need to be a tc member | 15:50 |
| sean-k-mooney | so its not really a delegated role in that sence its still really the tc apointing it which is why the different poccesses/toolign made sense in teh past fore each models | 15:51 |
| sean-k-mooney | so im just hopign we can keep the overhead fo this move low and not create extra work for the ptl and release team | 15:51 |
| fungi | the tc previously discussed some options for that, like switching the liaison refresh to once a year and/or decoupling from the election | 15:52 |
| fungi | i suggest adding it as a topic for an upcoming tc meeting | 15:53 |
| sean-k-mooney | yep after the election is complete woudl be better then before if it was every cycle | 15:53 |
| sean-k-mooney | one of the factors that went into selectign the dpl model for watcher ofritglly was i was nto aware https://review.opendev.org/c/openstack/governance/+/916833 had been passed and i was expecting the proir workflow where the reset woudl not happen | 15:56 |
| sean-k-mooney | i was very disaporinte dwith the extra process that entrial wehen we went to eimplemtn it | 15:57 |
| sean-k-mooney | its not hard it just feels, unnessary | 15:57 |
| sean-k-mooney | *dissapointed with... implement... | 16:01 |
| fungi | in particular, the vmt and release managers have struggled to get responses from liaisons over time, many of whom turned out to be gone from the project sometimes for years without anyone else updating the records | 16:18 |
| fungi | and in some cases the projects themselves could be abandoned and the tc wouldn't know because there was no forcing function like with ptl elections for at least someone to indicate they're still around | 16:19 |
| JayF | It's literally just -1'ing a change in governance to "reset" DPL. | 16:22 |
| JayF | That's what we're talking about eliminating; a proof of life where someone says "I care enough about this project to vote -1 on a governance change twice a year" | 16:23 |
| JayF | I don't think it's asking a lot of people, and if it's not working, that indicates either the folks aren't paying attention, we aren't highlighting the need well enough -- or most likely a combo thereof. | 16:23 |
| JayF | DPL should *not* be an escape hatch you can use to not worry about governance. | 16:25 |
| fungi | the escape hatch to not worry about governance is to develop a project outside of openstack. developing a project in openstack is basically a choice to adopt some fairly rigorous governance | 16:27 |
| JayF | ++ | 16:27 |
| TheJulia | There is a trade-off there, but also a benefits ultimately. | 16:47 |
| frickler | iiuc the rationale for the timing of the DPL reset is to allow the project to fall back to having a PTL election again, making room for new contributors to step up, which is very difficult to do otherwise when the leadership is "blocked" by a DPL team | 16:49 |
| frickler | having a reset after the election would make the project leaderless for a cycle or require ptl appointment | 16:50 |
| fungi | though the idea of "falling back" on ptl model when there are no/insufficient dpl liaison volunteers is probably wishful thinking in practice | 16:53 |
| fungi | if a project can't even get people to sign up for all the required liaison roles, there's nobody to serve as ptl since the ptl would need to cover all of those responsibilities anyway | 16:54 |
| fungi | so the workflow could be: 1. teams that want to switch between ptl and dpl declare that ahead of the election, 2. teams with ptl model hold an election, 3. remaining teams refresh their dpl liaisons, 4. if a dpl team lacks volunteers for all the required liaison roles then it is inactive | 16:56 |
| fungi | and just forget about "ptl fallback" as an option | 16:56 |
| sean-k-mooney | JayF: the thing is that the DPL model end up beign more paper work then the ptl one in practice | 18:51 |
| sean-k-mooney | and its not that you -1 the ptatch | 18:52 |
| sean-k-mooney | for the pathc to no be merged you need all the leasson to do that | 18:52 |
| sean-k-mooney | which mean i or whoever hwas to chase them to do it | 18:52 |
| JayF | yeah, I had to chase one of the folks for Ironic. Bluntly chasing folks down for reviews is something I do a lot. | 18:53 |
| sean-k-mooney | what i woudl per is to have teh tc laison be a member of the project team | 18:53 |
| sean-k-mooney | and have it be there repsonisblity to either propsoe teh reset or not | 18:54 |
| sean-k-mooney | based on just talkign to the team | 18:54 |
| sean-k-mooney | so we coudl jus tdcuss it in our team meeting and if nothing needed to change then we dont | 18:54 |
| JayF | That sorta reinforces the undemocratic issues DPL already has a little | 18:54 |
| JayF | where like, it's not clear in our governance how one would break up a DPL cabal | 18:55 |
| JayF | the reset, as is, gives a place to oppose that | 18:55 |
| sean-k-mooney | well the ptl can only appoint liason bcuase it a delegated power of the tc | 18:56 |
| sean-k-mooney | requiring the tc liason to opt in each time is less of an overhead | 18:56 |
| sean-k-mooney | it just was disapoint that we chose the dpl model orgianly to have a distibuted roles and lighter process sand it ended up being more work for me at least in the end | 18:57 |
| sean-k-mooney | as a team the watch team did dicuss our govrance option sin our weekly meeting comeint up ot each election cycle | 18:57 |
| sean-k-mooney | so it was kind of the opiscit situration we were activly engaining in dicussion our governance | 18:59 |
| sean-k-mooney | but ya its just kind of unfortuentl the the elections happen at what is otherwise a rather busy time | 18:59 |
| JayF | I just see it this way: if you can't get your liasons to vote on a governance change | 19:00 |
| JayF | how would an external contributor get them to vote on a code change? | 19:00 |
| JayF | It's indicative of a problem if a DPL reset is a big ask. | 19:00 |
| sean-k-mooney | it not that its big its that it make dpl more ovherhead then ptl | 19:01 |
| JayF | no, it puts that overhead on the team itself rather than having that overhead on election officials/tc | 19:02 |
| JayF | PTL election == externalized cost | 19:02 |
| JayF | DPL reset == more distributed cost | 19:02 |
| JayF | it feels more expensive to DPL reset because you're removing a thing from someone elses' plate and adding a smaller thing to your own | 19:02 |
| sean-k-mooney | yes and no. | 19:03 |
| sean-k-mooney | may issue with the reset is it make me depenent on wrnagnling a buch of other to do a thing | 19:03 |
| JayF | My previous statement stands that if it's a significant amount of effort to wrangle those liaisons by someone active in the community, an external contributor to that project would have no chance. | 19:04 |
| JayF | So I still see that as a sign of a larger problem with project activity. | 19:04 |
| sean-k-mooney | well that true in general | 19:04 |
| JayF | If we want to have a project be in openstack governance, it needs to have enough activity that a DPL reset is a drop in the bucket. | 19:04 |
| sean-k-mooney | so are we also going to reest all the ptl proejct going forward | 19:05 |
| sean-k-mooney | so that all liasos regarldess of the model have the same trivial -1 | 19:05 |
| JayF | We already do. Ptls have to renominate themselves if they want to run again. | 19:05 |
| sean-k-mooney | i mena teh security relsease and tact sig liaosn for ptl proejcts | 19:06 |
| TheJulia | And if someone is unhappy with that PTL, others are free to run. | 19:06 |
| TheJulia | A PTL could appoint someone else... | 19:06 |
| sean-k-mooney | they do | 19:06 |
| fungi | release liaisons who can't -1 a dpl reset in governance once a cycle also aren't reviewing release changes several times a cycle, leading to more work for the release team | 19:06 |
| sean-k-mooney | i was nova release leaison for 18-24 months | 19:06 |
| sean-k-mooney | while it had a ptl | 19:06 |
| fungi | security liaisons who can't -1 a governance change once a cycle probably also aren't going to look at security vulnerability bugs unless a vmt member spends time tracking them down and hounding them | 19:07 |
| JayF | fungi: <3 this is my point | 19:07 |
| sean-k-mooney | right so what im really askign is why does dpl or ptl matteter | 19:07 |
| sean-k-mooney | if the reset is a good thing why are we not reseting all of them | 19:08 |
| fungi | aren't we resetting all of them? | 19:08 |
| fungi | ptls are reset once a cycle | 19:08 |
| sean-k-mooney | no we only do it for dpl projects | 19:08 |
| sean-k-mooney | we reset ptl but we dont reset the serucity liason on ptl projects | 19:08 |
| fungi | oh, you mean release liaisons for ptl model team. yes that was my comment on the change to track release liaisons for ptl model teams solely in governance, i think they need to be reasserted at the same time as they are for dpl model teams | 19:09 |
| sean-k-mooney | right so the reason DPL feel like more process to me | 19:09 |
| sean-k-mooney | is we require the reasset only for DPL | 19:09 |
| sean-k-mooney | where was we dont for PTL right now | 19:09 |
| sean-k-mooney | if we required that alwasy it would be simpler | 19:10 |
| sean-k-mooney | and not make DPL feel like more work | 19:10 |
| fungi | https://review.opendev.org/c/openstack/governance/+/989156 specifically | 19:10 |
| sean-k-mooney | yes so that is jut moveing the one sthat already existted to store them in the same place | 19:10 |
| sean-k-mooney | which is an imporment in general beause it make this a lot more tansparent | 19:11 |
| fungi | i'm referring to my review comment on it | 19:11 |
| fungi | "The main question I have is logistical in nature, about the refresh process. Will liaisons for PTL teams get a forced refresh once per cycle like they do for DPL?" | 19:11 |
| fungi | i think they should be, but it's an open question the tc will need to decide | 19:11 |
| sean-k-mooney | if it was it would kind of level the playing filed | 19:12 |
| fungi | yes, my arguments in favor of refreshing dpl team liaisons are also applicable to ptl model liaisons | 19:13 |
| sean-k-mooney | but form my perspective a better model woudl be for the tc liason ot check in with the team and dicuss the governace with them once a cycle | 19:13 |
| fungi | realistically, we probably need to retire about half the existing teams, i don't expect we have enough tc members to be effective liaisons for all of them if it will require that degree of team involvement | 19:14 |
| sean-k-mooney | well part of the issue is its easy to miss the patch to the governace repo today | 19:15 |
| fungi | even when we had a larger tc, it was virtually impossible to get enough coverage to have a tc member occasionally attend meetings for every team | 19:15 |
| sean-k-mooney | when i said chasing peopel to reivew it it was mroe i had to go point out that the patch was there asnd ask them to review it | 19:15 |
| JayF | fungi: sean-k-mooney: I am +1 to requiring liason opt-in periodically for PTL projects, too, fwiw. | 19:15 |
| JayF | fungi: sean-k-mooney: Anything at all that can act as a stopper to catch projects with liason gaps or general activity issues. | 19:16 |
| TheJulia | FWIW, I think that is a grand idea because it forces people to re-assert ability engage | 19:16 |
| sean-k-mooney | for what it worth i have tired to advocat for thse tyep of dicsussion in the project i am involed with towrad the end of each cycel. | 19:17 |
| sean-k-mooney | i.e. core team membership, laison for the next release, dpl/ptl | 19:17 |
| sean-k-mooney | usually beofre m3 or after rc1 | 19:18 |
| fungi | i wish we also had a forcing function to make sure that membership rosters for each team's various groups in gerrit and launchpad were revisited at least once a cycle | 19:18 |
| sean-k-mooney | the recent core sec reivew eamil i thinik is soemthign we shoudl also do more often | 19:18 |
| sean-k-mooney | i.e. lookign a tthe memebrship of the launchpad team that see the secrity isseus and making sure they are actully composed of active people | 19:19 |
| sean-k-mooney | fungi: for me i kind of look at that are about m3 - 2-3 weeks but that proably just a me thing | 19:20 |
| sean-k-mooney | that roughly when it feels liek we are comign to the end of a cycle and it a good time to reflect | 19:20 |
| fungi | yeah, i honestly don't care when in the cycle it happens, but it's one of those things that since it doesn't break if it's left unattended to, a lot of teams will put it off indefinitely and then end up many years stale | 19:21 |
| sean-k-mooney | i also think its a good idea to advocate for having more then 1 liason for most roles, it helps with the handoff if the new liason can shadow you for a bit | 19:24 |
| sean-k-mooney | i know that is wishful thinking when getign 1 can be hard | 19:24 |
| sean-k-mooney | but you know bus factor > 1 is a good thing | 19:24 |
| sean-k-mooney | because watcher was swappign form DPL to PTL intentioanlly and the oder of the reset then elections we brifly lost or release liason right durign the release if i recall. | 19:27 |
| sean-k-mooney | i dont reall if that was this cycle ro the one before but i was rotaing out of release liason and new one were takign over i na prior release but the dpl reset ment tha thappend in the midel fo the release period between ff and the final release. | 19:28 |
| sean-k-mooney | hum https://github.com/openstack/governance/blob/master/reference/distributed-project-leadership.rst?plain=1#L183-L186 | 19:33 |
| sean-k-mooney | maybe that was the probel we had | 19:33 |
| sean-k-mooney | i think for wartch ew only had the release liasons in teh governace repo | 19:34 |
| sean-k-mooney | so when we reset back to ptl and ehy were not in the release repo it deactivead our release rights | 19:34 |
| fungi | that process will obviously change with the proposed stack to move release liaison tracking completely into governance | 19:35 |
| fungi | but also it makes it possible to have a release liaison and ptl both in the projects.yaml in governance, so we could still have a seamless transition for that case | 19:36 |
| sean-k-mooney | ya well you coudl do that before | 19:36 |
| fungi | currently the schema doesn't allow it, so switching to ptl means the release liaison has to be removed | 19:37 |
| sean-k-mooney | but i gues sif the reset only reset the leadership type | 19:37 |
| sean-k-mooney | adn current ptl that coudl help | 19:37 |
| sean-k-mooney | its really jsut the fact we are reseting the release liason durign the time of a release that has cause me issues in the past | 19:37 |
| fungi | 989156 makes release liaisons optional for ptl teams rather than forbidden | 19:38 |
| sean-k-mooney | it was not forbiden before | 19:39 |
| fungi | forbidden in the governance projects.yaml | 19:39 |
| sean-k-mooney | ah | 19:39 |
| sean-k-mooney | but not in practice | 19:39 |
| sean-k-mooney | as i noted i was nova release leasons for a cople of releases | 19:39 |
| fungi | that's what i mean about it changing the schema for the file | 19:39 |
| fungi | yes, as release liaison in a ptl model team your only option was to be listed in a file in the openstack/releases repository | 19:40 |
| sean-k-mooney | ack i was not aware that was enfocece by the tooling | 19:40 |
| sean-k-mooney | so reaslisticly the only wya to not have the release issue i had with dpl | 19:41 |
| sean-k-mooney | was to duplciate the leasions in both files | 19:42 |
| sean-k-mooney | which i was not doing | 19:42 |
| fungi | yes, because on switching to ptl model the liaisons *had* to be removed from governance | 19:42 |
| sean-k-mooney | so as watcher release liason for 2025.* | 19:42 |
| fungi | or else the change couldn't merge | 19:42 |
| sean-k-mooney | this was a pain point for me | 19:43 |
| sean-k-mooney | becaus i felt like i neede to chase folk to opt back in or i woudl lose my abilty to get the release done | 19:43 |
| sean-k-mooney | but i could have mitigated that by just adding myself also in the release repo | 19:43 |
| sean-k-mooney | i tought i coudl nto be in both but i ugess i missed that part | 19:44 |
| fungi | yeah, under ptl model you don't strictly need a release liaison listed, since the ptl can also acknowledge release requests | 19:46 |
| sean-k-mooney | no it was jsut a timeing thing https://github.com/openstack/governance/commit/13b4450fe872e5dc494a8cb64d863e98bb27e639 merge august 20th but i was ment o be hadnelign the 2025.2 release work and chandan and joan were going to take over for 2026.1 | 19:48 |
| sean-k-mooney | so when the reset and as a reasutl the update of the laiaosn happend i took effect before we had plan it to goin in effect | 19:49 |
| sean-k-mooney | because the election happen before the actual release and the reset has to happen beofre the eleactions | 19:51 |
| sean-k-mooney | the change of release laison happend at r-5 | 19:51 |
| sean-k-mooney | instead of waht we intneded which was r+1 really or atleat after rc1 | 19:51 |
| sean-k-mooney | same thign when swaping ot ptl for this release https://github.com/openstack/governance/commit/0ee21071b6887a1b1de781c4689898c330141b1b election closed at r-1 | 19:54 |
| sean-k-mooney | but the reset happend at r-5 | 19:55 |
| sean-k-mooney | so for that month or so we didnt have the leiason listed whiel the election happend | 19:55 |
| sean-k-mooney | that is why this has felt like such an inconvicne to do | 19:57 |
| gouthamr | > so for that month or so we didnt have the leiason listed whiel the election happend | 20:01 |
| gouthamr | hey, the release liaison on the releases repo was always intact: | 20:01 |
| gouthamr | https://opendev.org/openstack/releases/src/commit/f90d6fea3c0bac07e9ba0ef8cedc69152018e8d6/data/release_liaisons.yaml#L152-L158 | 20:01 |
| gouthamr | so, release team wasn't blocked by this | 20:02 |
| gouthamr | maybe i don't understand the problem with dropping the liaisons .... if you _need_ the info when a team is switching from DPL to PTL, maybe we could just switch the leadership type and leave the liaisons around for documentation; and have the election change drop the liaison info as well. | 20:05 |
| gouthamr | i understand the process is bothersome, and tkajinam pointed that out too, numerous times/places.. but, do realize the TC is in between a rock and a hard place to judge this stuff; that's why we took this painful route... as a liaison myself to multiple DPL teams, i read the team's meeting logs and try to gauge the team's activity/status.. but, my judgement isn't a substitute for public discussion.. | 20:08 |
| gouthamr | and fungi said switching to PTL is wishful thinking.. i agree | 20:08 |
| gouthamr | we did that for Oslo and Requirements in the past cycle | 20:08 |
| gouthamr | knowing full well that we'll have no PTL candidates | 20:08 |
| gouthamr | we did it anyway to raise the issue that this space is being under-staffed... teams reorganized, the problem didn't go away.. but, i suspect we gathered some eyeballs and some hint of investment | 20:10 |
| fungi | well, actually while i agree with that, what i was really saying was that the implied fallback from dpl to ptl is also wishful thinking | 20:10 |
| fungi | if you can't find volunteers to fill the dpl liaison roles, then who is going to be the ptl? | 20:10 |
| fungi | in reality, the fallback from dpl is inactive, but yeah probably the fallback from ptl is also inactive | 20:11 |
| fungi | er, never mind, i misread what you said and then just restated it all. ignore me! ;) | 20:12 |
| * fungi gets back to doing too many other things at once | 20:13 | |
| gouthamr | :P | 20:13 |
| gouthamr | yes.. dearth of leadership is hence a prime indicator for inactivity; many times the use cases for a project go away, people move on.. but it appears like a slow fade and all these governance measures come into play one day | 20:15 |
| sean-k-mooney | gouthamr: tha twas adde later https://opendev.org/openstack/releases/commit/af22488c043b284f530960a7aec2aa802a4c71e3 | 20:22 |
| sean-k-mooney | after the election | 20:22 |
| sean-k-mooney | gouthamr: we coudl have added it before | 20:23 |
| gouthamr | ahh, I see so that’s a genuine gap | 20:23 |
| sean-k-mooney | gouthamr: the issue we were havign was we didnt knwo you coudl have the lieason in both so we only had it in the governace repo | 20:23 |
| sean-k-mooney | it didnt really impact thing too much becasue we jsut did the release work as normal and asked the release team to approve ectra | 20:24 |
| sean-k-mooney | but ya for the prior on when i was teping down but actully still doing the release work for 2025.2 | 20:24 |
| gouthamr | sean-k-mooney: yes, name recognition usually helps around here :D thanks for noting this.. | 20:24 |
| sean-k-mooney | i basicly took it as a knwoldage transfer opertuhnity becaus i had lost th right but i prepare the patches adn show the new liaons what they need to do | 20:25 |
| gouthamr | sean-k-mooney: since we seem to be trending towards unifying that info, and moving it into governance, we'll make sure that we understand a) who adds this info b) when/how it is refreshed... | 20:25 |
| gouthamr | sean-k-mooney: ++ | 20:25 |
| sean-k-mooney | if the schema does not mechanilly force the liasons to be removed anymore | 20:26 |
| gouthamr | tonyb suggested we move all cross project liaisons in the same way to the governance repo, and it'll help me/us at the VMT too since its better than hunting for info on the wiki currently | 20:26 |
| sean-k-mooney | i woudl suggest that you woudl reset by swapign the model back to ptl and remvoign the ptl | 20:26 |
| sean-k-mooney | for the perod of the election and keep the other liason until the new ptl is elected | 20:26 |
| sean-k-mooney | or perhps jsut do the release liason change seperatly | 20:27 |
| gouthamr | ack, i'd not tie this release liaison removal to elections.. and maybe the VMT will prefer to see the security liaison stay as well | 20:27 |
| sean-k-mooney | so it not betweeen FF and the final release :) | 20:27 |
| gouthamr | yes | 20:27 |
| sean-k-mooney | ya so honetly that was the only one that was a friction point | 20:28 |
| fungi | it'll also help smooth things like tact-sig reviewing openstack project changes in project-config | 20:28 |
| fungi | since we need the ptl or tact-sig liaison to ack changes | 20:28 |
| gouthamr | i see | 20:28 |
| fungi | but starting with release liaisons makes sense to me | 20:29 |
| gouthamr | ++ | 20:29 |
| sean-k-mooney | anyway i dont have an issue with mvoign this to teh governce repo | 20:31 |
| sean-k-mooney | jsut notign the pain poitn we had in 2025.2 adn 2026.1 release window becuase of how we happen to execute it | 20:31 |
| sean-k-mooney | if we had duplciate the info into the release repo we woudl ahve avoided that pain | 20:32 |
| sean-k-mooney | as long as we fix that in the new process all is good | 20:32 |
| gouthamr | ack thanks sean-k-mooney.. | 20:33 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!