| opendevreview | Merged openstack/election master: Close 2025.2 Election Results (TC/PTL) https://review.opendev.org/c/openstack/election/+/942506 | 08:49 |
|---|---|---|
| opendevreview | Slawek Kaplonski proposed openstack/governance master: Add TC/PTL results from 2025.2 election https://review.opendev.org/c/openstack/governance/+/942507 | 09:29 |
| slaweq | tc-members: hi, patch with election results is merged now. I just sent emails to conclude election so I think that ^^ is now good to go also | 09:31 |
| bauzas | slaweq: thanks for the hard work and thanks ian tyoo | 09:51 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: WIP redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 09:55 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: WIP redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 10:04 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: WIP redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 10:08 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Minor fixes for redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 10:09 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Minor fixes for redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 10:20 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Minor fixes for redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 10:34 |
| opendevreview | Ivan Anfimov proposed openstack/openstack-manuals master: Minor fixes for redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 10:35 |
| tkajinam | tc-members: this was pointed out by frickler in the #openstack-release , but since oslo has been switched back to PTL model, no one can approve release proposals due to lack of PTL and the existing liaisons removed . What's your suggestion to fix this ? | 12:53 |
| tkajinam | there are a few regressions we found in the latest oslo releases which are blocking a few projects and there are releases proposed to fix these but again no one can "approve" these from project side | 12:54 |
| frickler | tkajinam: from the discussion yesterday I assumed that gouthamr would comment on those reviews and kind of give them a TC rubber stamp for release-team override. let's wait until later today, worst case I'll just override on my own | 13:06 |
| tkajinam | frickler, oh thanks for sharing that ! and the plan sounds good to me | 13:07 |
| opendevreview | Takashi Kajinami proposed openstack/governance master: Switch back Oslo to DPL model https://review.opendev.org/c/openstack/governance/+/942793 | 13:30 |
| gouthamr | frickler: o/ i've added a follow up comment on https://review.opendev.org/c/openstack/governance/+/942507 .. could you please take another look | 16:06 |
| frickler | gouthamr: hmm, good point about the release liaisons, although we seem to have wildly inconsistent data there, so we'll need to do some cleanup there and possibly some sync check job | 16:32 |
| gouthamr | i know :( for now, it's manual.. | 16:33 |
| fungi | or find a way for the release tooling to look it up dynamically from governance | 16:43 |
| fungi | so it can all be in one place | 16:43 |
| fungi | similar to the discussion about project emerging/inactive status | 16:43 |
| gouthamr | ack; two places is good for continuity with our DPL Reset effort | 16:54 |
| gouthamr | but, we could just adjust the DPL Reset effort as well | 16:54 |
| gmann | it seems all project have identified leaders now https://etherpad.opendev.org/p/2025.2-leaderless | 18:23 |
| fungi | that was faster than usual, great work everyone! | 18:39 |
| gouthamr | gmann: yeah good stuff, we’re pending governance changes.. we can try to wrap that up in a couple of weeks if folks keep up with uploading changes and reviews | 18:49 |
| gouthamr | I’ll send a note to everyone that needs to be appointed reminding them how to go about it | 18:50 |
| gouthamr | tc-members: I’m hoping to workflow https://review.opendev.org/c/openstack/governance/+/942507 | 18:51 |
| gouthamr | last chance for any objections | 18:52 |
| gmann | yeah, paper work takes time but at least we have leaders identified/volunteered for project is good. ++ on sending 4 projects (barbican, Zaqar, Masakari, and OpenStack_Charms) PTL appointment which we can propose or let volunteer to propose. In past we proposed and had +1 from volunteer PTL which speed up the paper work | 18:53 |
| gouthamr | ah makes sense gmann.. candidates proposing the change allows us to ask them questions on gerrit :D which they may otherwise ignore if they were just reviewing changes | 18:55 |
| gouthamr | don’t know, just a bit of past trauma in this department | 18:55 |
| opendevreview | Merged openstack/openstack-manuals master: Minor fixes for redirects https://review.opendev.org/c/openstack/openstack-manuals/+/942770 | 18:59 |
| gmann | yeah, I am not sure how many choices we have for those 'single volunteer leader projects,' but asking questions can be a good reminder about the PTL of responsibility. | 18:59 |
| gouthamr | yeah | 18:59 |
| gmann | *PTL responsibili | 18:59 |
| gouthamr | frickler: unsure you want to retain your RC -1 | 19:00 |
| gouthamr | ideally not if releases are not affected? | 19:01 |
| gouthamr | on this change I meant: https://review.opendev.org/c/openstack/governance/+/942507 | 19:01 |
| gouthamr | There’s language in our house rules that need me to pay attention to RC -1 | 19:02 |
| cardoe | gouthamr: That's my question if we've addressed the -1 | 19:12 |
| gmann | I added comment there, we are mixing the election results + documentation update/fix things. As per house rule it should be confirmation of election results and not the documentation change/fix https://review.opendev.org/c/openstack/governance/+/942507/comment/029df38c_6df9f638/ | 19:14 |
| gmann | any documentation fixes can be done any time after election results are confirmed/merged | 19:14 |
| gouthamr | gmann: i don't think the -1 was for the IRC nick | 19:31 |
| gouthamr | "also I think that the timing is bad, IMO the switchover should happen only after rc1 for 2025.1 is released, since this change does affect whom the release automation will allow to confirm release patches. so my RC-1 is only disapproval of the timing, not the content, I'd suggest to wait for two weeks, then all should be fine" | 19:31 |
| gouthamr | sorry, should just link the comment: https://review.opendev.org/c/openstack/governance/+/942507/comments/8a664c93_9135b97a | 19:32 |
| gmann | gouthamr: ok, then I think we are mixing 3rd thing in election results. | 19:38 |
| gmann | election results are just outcome of elections and proposed/reviewed by the election official which complete the election official work and conclude the election | 19:39 |
| gmann | any process change in TC or undefined TC policy should be handled separately | 19:39 |
| gouthamr | yeah, RC -1 isn't appropriate imo | 19:39 |
| gmann | I commented on the change | 19:40 |
| gouthamr | i'd call it election denial :D but i don't like making political jokes | 19:41 |
| gmann | I agree with the frickler comment but we should handle that separately. I am ok to wait and get go ahead on that from frickler which he might do tomorrow or so | 19:41 |
| gmann | we should discuss and define the PTL terms somewhere explicitly like we did for TC terms | 19:42 |
| gouthamr | yes | 19:42 |
| gmann | IMO, I am in favor of same policy as we have for TC, 'election conclusion is the PTL terms start/end' but there can be debate on that. considering different election model in different country :) but we do not need to follow a specific country election model where newly elected leaders take the role after some time from election are concluded. | 19:45 |
| gouthamr | i think it makes sense to tie it into a release unless the prior PTL isn't available | 19:45 |
| gouthamr | we'll have election results coinciding with RCs, and the release liaisons and PTLs from that release should still see the process through the finish line | 19:46 |
| gmann | we can do that but then we need to hold the election conclusion or at least updating the projects.yaml (which is what frickler comment) and more than that we need to be careful that project leaders understand that. Most of them might thing election finished and new PTL will take things forward. | 19:48 |
| fungi | for most purposes, teams can transition from one ptl to another at whatever speed works best for them since it's mostly a transfer of human authority. automation like release request authorization is the main place where having a set date becomes more useful | 19:49 |
| gmann | but no big deal in both options where later one (new PTL wait for new release cycle start) is little more work/communication otherwise it is just to define it clearly. | 19:49 |
| gmann | I think we should not make it complicated for tooling/release process for that. They should always refer the projects.yaml for any project data anytime. If we want new PTL to wait for new rlease cycle then we should wait to update the project/yaml | 19:50 |
| gmann | means, TC should reflect the project data as correct/latest always it is up to TC when they want to update the things as per policy | 19:51 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!