| opendevreview | Ghanshyam proposed openstack/governance master: Modify the timeline for project to move to Inactive state https://review.opendev.org/c/openstack/governance/+/908880 | 05:33 |
|---|---|---|
| opendevreview | Ghanshyam proposed openstack/governance master: Mark Murano project inactive https://review.opendev.org/c/openstack/governance/+/908859 | 05:44 |
| elodilles | gmann: thanks o/ | 07:28 |
| *** tosky_ is now known as tosky | 09:48 | |
| fungi | just a heads up, we're getting an increasing number of projects opting out of the central openstack-unmaintained-core model in favor of project-specific groups. it's possible the goals with the central group having fairly open membership and minimal responsibilities have not been well communicated to the wider community | 15:44 |
| JayF | In the case of Ironic, I think it was more out of a sense of wanting to maintain the status-quo of maintaining those older branches, while getting the beneficial change the naming gives us for lowering expectations. | 15:54 |
| JayF | Have we had many of those project groups opt to exclude openstack-unmaintained-core? | 15:54 |
| * JayF notes he still is not going to be at the TC meeting, is traveling for work, in Dallas, and is interacting upstream where/when he can | 15:54 | |
| fungi | kolla was going to, but after explaining the intent of the unmaintained process in detail, they decided to add openstack-unmaintained-core to kolla-unmaintained-core | 15:55 |
| JayF | I think that the more concerning case would be if projects were excluding that group | 15:55 |
| fungi | neutron is now similarly proposing an exclusive acl for neutron-unmaintained-core, and i'm explaining this to them all over again | 15:55 |
| clarkb | JayF: well and more generally we're reinventing the status quo we had previously. But now with more steps | 15:55 |
| JayF | Ack; perhaps worth mentioning in open discussion in the meeting in two hours? | 15:55 |
| fungi | which is why i say, i think this has not been clearly communicated, and it's falling on reviewers for project-config to reiterate it on every new acl change | 15:56 |
| JayF | Seems like someone on TC (or you, but it's not your job) should email with that information | 15:56 |
| jamespage | apologies but I can't make the TC meeting this or next week - I've run through formal-vote topics as appropriate (couple of comments) | 15:57 |
| JayF | clarkb: The name-change project had multiple goals; the most obvious of which was to stop pretending that we did real "maintenance" on the old branches rather than it being an opportunistic thing. That goal is achieved. We should work to reduce effort in implementing this, but I don't want us to declare defeat in the face of a significant vistory | 15:57 |
| JayF | s/vistory/victory/ | 15:57 |
| fungi | i think it would be better for the unmaintained process redux explanation to come from a source of authority over that process, yes. i can at best only explain my interpretation of it | 15:57 |
| fungi | also i was not a proponent of this design, which makes me a poor choice to advocate it (i was in favor of just eoling everything once it reaches end of normal maintenance) | 15:58 |
| JayF | I was only trying to make clear I didn't oppose you sneding such an email; but I agree it's not your responsibility | 15:58 |
| JayF | FYI: I have signed the TC up for the PTG in April. | 16:27 |
| clarkb | JayF: my concern is that the goal of convincing project teams they don't need to be keeping those projects alive is at risk if every project feels they need to keep ownership of this via a special group | 16:28 |
| clarkb | s/keeping those projects alive/keeping those branches alive/ | 16:29 |
| dansmith | this is why I wanted separate trees ;) | 16:29 |
| fungi | this is why i wanted to just eol the branches ;) | 16:43 |
| dansmith | or that :) | 16:43 |
| rosmaita | well, eol-ing the branches was the original proposal | 16:44 |
| dansmith | yup | 16:44 |
| fungi | it did not go over well with the audience at the forum, but most of the people who objected to closing down those branches were also not volunteering to do the work to keep them viable | 16:47 |
| opendevreview | Ghanshyam proposed openstack/governance master: Modify the timeline for project to move to Inactive state https://review.opendev.org/c/openstack/governance/+/908880 | 17:09 |
| opendevreview | Ghanshyam proposed openstack/governance master: Mark Murano project inactive https://review.opendev.org/c/openstack/governance/+/908859 | 17:09 |
| slaweq | Hi JayF, sorry for the late notice but I will not be able to join meeting today | 17:36 |
| rosmaita | tc-members: reminder ... meeting here at 1800 utc (i.e., in 7 minutes) | 17:54 |
| rosmaita | #startmeeting tc | 18:00 |
| opendevmeet | Meeting started Tue Feb 13 18:00:13 2024 UTC and is due to finish in 60 minutes. The chair is rosmaita. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:00 |
| opendevmeet | The meeting name has been set to 'tc' | 18:00 |
| rosmaita | #topic roll call | 18:00 |
| gmann | o/ | 18:00 |
| knikolla | o/ | 18:00 |
| rosmaita | we have 4 excused absences, so we will need all 5 unexcused people to show up or we have to cancel the meeting | 18:00 |
| rosmaita | 0/ | 18:00 |
| rosmaita | i mean, o/ | 18:00 |
| rosmaita | so, let's wait a few minutes | 18:01 |
| rosmaita | i saw dansmith around here earlier today | 18:01 |
| gmann | we can have meeting without quorum also its just we cannot take formal vote/agreement if no quorum | 18:01 |
| fungi | technically you don't have to cancel, right | 18:01 |
| rosmaita | i don't know whether i am happy or sad about that | 18:02 |
| gmann | :) | 18:02 |
| rosmaita | ok, we will proceed as usual and see what happens | 18:02 |
| rosmaita | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 18:02 |
| fungi | since the tc doesn't often make decisions in these meetings, whether the meeting is quorate is mostly only important for satisfying the minimum number of meetings claimed in the charter | 18:02 |
| dansmith | o/ | 18:02 |
| dansmith | sory | 18:02 |
| rosmaita | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee. | 18:02 |
| rosmaita | ok, if we have to do anything official, we can try to round up spotz[m] | 18:03 |
| rosmaita | otherwise, everyone is here, so let's get started | 18:03 |
| gmann | yeah | 18:04 |
| rosmaita | topic Follow up on tracked action items | 18:04 |
| rosmaita | - No action items from Jan 30 meeting. | 18:04 |
| rosmaita | so i guess that's that | 18:04 |
| rosmaita | #topic Gate health check | 18:04 |
| rosmaita | anyone have anything to say? | 18:05 |
| gmann | I did not notice any frequent failure | 18:05 |
| rosmaita | me neither | 18:05 |
| dansmith | really? :) | 18:05 |
| dansmith | granted I've been a little out of the loop this last week, | 18:05 |
| rosmaita | yeah, just a few rechecks here and there on the patches i've looked at | 18:06 |
| dansmith | but I rechecked a glance guest kernel crash myself | 18:06 |
| rosmaita | ok, but that's kind of an act-of-god thing, isn't it? | 18:06 |
| dansmith | nova still seems to be finding plenty of them, but we do run the widest set I think | 18:06 |
| dansmith | eh? | 18:06 |
| rosmaita | i mean there's nothing glance is doing that crashes the kernel, i wouldn't think | 18:07 |
| dansmith | guest kernel crashes have been frequent and getting worse for, what, over a year now.. we've been trying to loop in kernel teams to figure out what's going on but to no avail | 18:07 |
| gmann | act-of-kernal :) | 18:07 |
| dansmith | oh, no I just meant glance being not-nova | 18:07 |
| dansmith | these kernel crashes seem to be way more frequent on volume-based tests, but we have no idea why | 18:07 |
| dansmith | anyway, I was just surprised to hear people thinking things are better, but I don't have much other than that to add :) | 18:09 |
| rosmaita | ok, so sounds like the current situation is "mostly sunny, with scattered guest kernel crashes" | 18:09 |
| rosmaita | ok, let's end this topic on an optimistic note, for once | 18:09 |
| rosmaita | #topic Implementation of Unmaintained branch statuses | 18:10 |
| rosmaita | i don't know that there's anything new here ... saw some discussion in the channel earlier, but maybe that's better for open discussion | 18:10 |
| rosmaita | the next step is moving the pre-yoga branches to Unmaintained | 18:10 |
| rosmaita | but i don't know what the schedule for that is | 18:11 |
| gmann | I saw releasenotes job failing in my tacker change for stable/yoga and bcz it is now unmaintained/yoga | 18:11 |
| gmann | but did not debug yet. this might be case for other projects also? | 18:11 |
| rosmaita | yes, there are bot-generated patches updating that | 18:11 |
| gmann | nice. thanks for info | 18:11 |
| gmann | I will check those | 18:11 |
| rosmaita | https://review.opendev.org/q/topic:%22reno-eom-yoga%22 | 18:12 |
| gmann | ++ | 18:12 |
| fungi | a concern was raised that the redirect on the releases site was still going to stable-named branches in requirements rather than unmaintained, but tonyb has a change up to fix that | 18:12 |
| rosmaita | last i heard, requirements was keeping both stable/y and unmaint/y until things calm down? | 18:13 |
| clarkb | both are needed until stable/y doesn't exist anywhere else | 18:13 |
| clarkb | otherwise the zuul branch association behaviors associate you to master by defaul and you break | 18:13 |
| rosmaita | ok | 18:14 |
| gmann | we still need to move those for devstack/grenade at the end but before requirement | 18:14 |
| fungi | i also brought up that we're seeing an increasing number of projects proposing their individual foo-unmaintained-core groups while excluding openstack-unmaintained-core, and i'm concerned that the rationale for having an open central group where anyone can join and help review/approve changes for the unmaintained branches/projects they care about hasn't been clearly communicated to the | 18:14 |
| fungi | wider community, so it's been falling on the project-config reviewers to reiterate that to each team as they propose an acl update | 18:14 |
| dansmith | yeah it came up in the nova meeting an hour ago, and it seemed like the default suggestion was for a per-project group, | 18:15 |
| rosmaita | well, that's a bummer | 18:15 |
| gmann | but that is ok right? | 18:15 |
| dansmith | but I pointed us to the default being the global group | 18:15 |
| rosmaita | yeah, i thought i was pretty clear about that in the email i sent last month | 18:15 |
| rosmaita | but, i guess not | 18:16 |
| dansmith | definitely seems like the complex arrangement we came up with has generated confusion | 18:16 |
| gmann | but if any project want to create project-wise group it is still fine we just need to tell them we have global group also if that is enough for them | 18:16 |
| rosmaita | "The global openstack-unmaintained-core team will, by default, handle maintenance of unmaintained/yoga branches (both CI and merging patches). If your project wants to have its own <project>-unmaintained-core team, it's allowed, but you have to create it yourself." | 18:16 |
| gmann | are those projects proposing per project group not aware of global group? that may be interested to ask | 18:16 |
| fungi | i suppose it's okay for individual projects to want exclusive control over those branches, but the number of them who have been proposing those changes and their responses to our review comments make it seem like some are under the mistaken impression it's expected of them | 18:16 |
| fungi | i think they're just copying the changes they see other projects propose | 18:17 |
| gmann | ohk | 18:17 |
| clarkb | it also indicates to me that we haven't solved the feeling of obligation around supporting those branches | 18:17 |
| rosmaita | i thought the "create it yourself" would be enough to discourage people | 18:17 |
| dansmith | clarkb: well, the misunderstanding could explain that, but yeah | 18:17 |
| gmann | maybe rosmaita can send it explicitly in ML which you already sent in your original email but might have been not read due to large text or so | 18:17 |
| rosmaita | good idea | 18:18 |
| fungi | at least one ptl said they proposed a group for their team because nobody on the central team had approved the bot-proposed changes for their unmaintained branches yet, and seemed not to realize they could just become part of that central team | 18:18 |
| rosmaita | #action rosmaita send email about the global unmaint group being the default, and that it's open for people to join | 18:18 |
| fungi | it was also brought up that there's no clear explanation for how someone gets to be part of openstack-unmaintained-core or what the process is for applying | 18:18 |
| gmann | and might be they thing it is wider work/responsibility if they become part of global group? | 18:18 |
| gmann | fungi: good point | 18:19 |
| rosmaita | fungi: that's a good point, and i don't know myself, other than to contact current members of that group | 18:19 |
| fungi | being part of openstack-unmaintained-core shouldn't require that you care about every project, i don't expect | 18:19 |
| gmann | fungi: yeah, we should clear that explicitly in documentation | 18:19 |
| gmann | otherwise many PTL might think they need to handle other projects also along with their own | 18:20 |
| fungi | yes, saying clearly that it's okay to only review unmaintained changes for one project might help, that you're not obligated to review everything | 18:20 |
| gmann | yeah | 18:20 |
| rosmaita | well, that's kind of up to the openstack-unmaintained-core team (i mean, to decide what responsibilities are) | 18:21 |
| rosmaita | anyone can +1/-1 unmaintained patches | 18:21 |
| fungi | also some policy like anyone who's a current or former core reviewer for an openstack deliverable can be immediately added to openstack-unmaintained-core on request might help to bootstrap it beyond the current two members | 18:21 |
| fungi | i agree it's for the members of openstack-unmaintained-core to decide how the group is managed, but projects are now seeking information on how it's managed and that hasn't been communicated | 18:22 |
| gmann | we can clarify all these things here #link https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintained-branch-maintenance | 18:23 |
| fungi | and it at least seems like it has become a blocker to some contributors who want to approve patches on those branches | 18:23 |
| gmann | rosmaita: let me know if you want to do otherwise I can push the doc change and we can see if we cover all these in doc | 18:23 |
| * rosmaita is thinking | 18:24 | |
| fungi | and having too much process/bureaucracy around adding people to the group will inevitably lead to the situation we had with the central stable-maint team | 18:24 |
| rosmaita | well, the idea was that it would be a self-maintaining group | 18:25 |
| rosmaita | so i guess what we need is to ask the current members to add a meeting or something so that people know how to contact them | 18:25 |
| fungi | where current members are afraid to add interested participants either because they set the requirements and responsibilities too high, so the individual teams just created their own stable review groups instead | 18:25 |
| rosmaita | let's do this: | 18:26 |
| gmann | but its group for unmaintained branches so less risky than previous stable branch grou[ | 18:26 |
| gmann | group | 18:26 |
| rosmaita | 1 - i will send the email telling people about the general group being the default | 18:26 |
| fungi | yes, which is why i hope they'll just make it open to anyone who's interested and has at least some minimal involvement in openstack | 18:26 |
| rosmaita | 2 - we will encourage elodilles and tonyb to figure out something to tell people about joining | 18:26 |
| fungi | sounds good to me. thanks! | 18:27 |
| rosmaita | ok, i'll just say as part of #1 to watch for a followup email about #2 | 18:27 |
| rosmaita | anything else? | 18:27 |
| fungi | not from me | 18:27 |
| dansmith | rosmaita: maybe also say "you should only opt into a separate group if you want to maintain the unmaintained branches yourself and don't want the larger group to do it for you, otherwise you have no such obligation" | 18:27 |
| rosmaita | good idea | 18:28 |
| gmann | rosmaita: and update the doc also with the expectation and how to get added | 18:28 |
| fungi | don't want the larger group to do it for you and don't want to be part of that larger group yourself | 18:28 |
| rosmaita | tell you what, after the meeting, i will draft my email in an etherpad and won't send it until 2100 utc today | 18:28 |
| rosmaita | and that way people can make suggestions or comments | 18:29 |
| dansmith | fungi: I think that's implied in the "don't want the larger group to be *able* to do it" but yeah.. maybe also reiterate the "just join the larger group if you want to approve things, no need for a separate group" | 18:29 |
| rosmaita | #link https://etherpad.opendev.org/p/unmaintained-global-default | 18:29 |
| rosmaita | ok, moving on | 18:30 |
| rosmaita | #topic Murano project status | 18:30 |
| rosmaita | gmann: that's you | 18:30 |
| gmann | yeah so murano is inactive seeing no response on email, gate fix and fungi mentioned about same in vmt also | 18:30 |
| gmann | no response on security issue is more critical here | 18:31 |
| gmann | and we had discussion in IRC I think yesterday about it and I propose it to mark it Inactive #link https://review.opendev.org/c/openstack/governance/+/908859/3 | 18:31 |
| gmann | and because our current process doc did not explicitly cover about marking project Inactive after milestone-2 which is release tema deadline to do so, I am updating the doc also #link https://review.opendev.org/c/openstack/governance/+/908880/2 | 18:32 |
| gmann | so doc change first and then marking Murano Inactive | 18:32 |
| gmann | we can discuss here if any question/feedback or maybe in gerrit | 18:33 |
| rosmaita | yes, not responding to security issues is really bad | 18:33 |
| rosmaita | thanks for posting those patches | 18:33 |
| fungi | a related question is how the reported vulnerability for it should be handled | 18:33 |
| fungi | right now it's private, with only the vmt coordinator and original reporter posting on it. odds it will be fixed in private are slim, based on the unresponsiveness of the ptl who seems to be the only recently-active member of murano-drivers (they don't have a separate murano-coresec team) | 18:34 |
| fungi | the vmt is technically not even overseeing reports of vulnerabilities in murano, it just happened to get reported directly to us by e-mail | 18:35 |
| rosmaita | in your estimation, does it require a lot of murano knowledge to fix? | 18:35 |
| fungi | it requires more murano knowledge than i have (which is approximately zero), but how much more i'm unable to guess | 18:36 |
| gmann | also, its difficult to validate the fix also when no core around it | 18:37 |
| rosmaita | well, i guess the general VMT policy is that after 90 days or something, it becomes public ... is that right? | 18:37 |
| fungi | i'd be okay with an outcome of switching the report to public, but since the team hasn't delegated that responsibility to the vmt i'd look to the tc to decide if that's an appropriate course of action | 18:37 |
| fungi | that's the vmt's policy for repositories we oversee, but murano isn't one of them | 18:37 |
| rosmaita | i'd say what we could do is (a) make it public, and (b) merge a sentence to the README to all stable branches with a reference to the bug | 18:38 |
| gmann | If project move to Inactive and no response from PTL in coming month or so then I think making it public is good | 18:38 |
| fungi | yeah, also the bug report is only a little over a month old, i'm mainly asking because the original reporter is asking me why there has been no response yet | 18:38 |
| rosmaita | ok, so we have a little less than 2 months to decide | 18:39 |
| fungi | one other thing to keep in mind: while the project has been apparently inactive for a long time, this discussion is coming up in the middle of lunar new year and the current ptl (and only ostensible contributor remaining) may not be near a computer | 18:40 |
| gmann | cool, by that time we will have more clarity if anyone around or new members step up to maintain it | 18:40 |
| fungi | thanks, i'll try to convey that to the reporter in the bug report for now | 18:40 |
| gmann | but ML and gate is broken for long I think first email about inactive was in jan | 18:40 |
| gmann | last I heard/notice PTL was in election only | 18:41 |
| rosmaita | it sounds like we need to plan for munano becoming inactive AND we must make a decision about how to handle the security bug on the stable branches | 18:41 |
| rosmaita | (assuming murano is branched? i don't even know that much about it) | 18:42 |
| gmann | yes | 18:42 |
| rosmaita | everyone: please vote on https://review.opendev.org/c/openstack/governance/+/908859 | 18:42 |
| fungi | it is branched, with stable branches all the way back to train, and no transition to unmaintained, presumably because of having nobody to ack changes for that or eol | 18:43 |
| rosmaita | and please think about strategies for dealing with the security issue | 18:43 |
| rosmaita | fungi: thanks for that info | 18:43 |
| rosmaita | sounds like we should consult with the openstack-unmaintained-core team, but i think we should directly EOL train through yoga for murano | 18:44 |
| rosmaita | because there is no one to opt-in to keeping it Unmaintained | 18:44 |
| rosmaita | #topic Testing runtime for 2024.2 release | 18:45 |
| rosmaita | gmann: that's you again | 18:45 |
| gmann | I pushed change about it and discussion also going on there | 18:45 |
| gmann | I will reply on python 3.12 addition comment in gerrit | 18:45 |
| gmann | other than that nothing specific here to discuss than request for review/feedback in gerrit ot email | 18:46 |
| rosmaita | ok, thank you | 18:46 |
| clarkb | re python3.12 I don't know if any of the distros we have deployed make it installable | 18:47 |
| rosmaita | #link https://review.opendev.org/c/openstack/governance/+/908862 | 18:47 |
| clarkb | you can still theoretically install it from elsewhere though | 18:47 |
| clarkb | historically ubuntu has pushed packages for newer python on the existing LTS but I don't think that has happend yet for 3.12 | 18:47 |
| gmann | yeah, just now commented in gerrit also | 18:48 |
| gmann | Ubuntu 24.04 will have but that is not coming soon at least not before next dev cycle start | 18:48 |
| rosmaita | ok, looks like there will be a healthy discussion on the patch in gerrit | 18:49 |
| rosmaita | #topic 2024.1 TC Tracker | 18:49 |
| gmann | I thin may be 2025.1, next SLURP can be target for py3.12 ? | 18:49 |
| rosmaita | #link https://etherpad.opendev.org/p/tc-2024.1-tracker | 18:49 |
| rosmaita | anyone have anything they'd like to report? | 18:50 |
| dansmith | clarkb: maybe because it breaks so much stuff? :) | 18:50 |
| rosmaita | #topic open discussion | 18:51 |
| rosmaita | i guess we already covered the unmaintained core stuff | 18:51 |
| fungi | yep, sorry if that was mildly off-topic for the unmaintained transition segment | 18:52 |
| rosmaita | are there any other issues (other than guest kernel crashes) on people's minds? | 18:52 |
| rosmaita | apparently not | 18:54 |
| rosmaita | ok, give me a few minutes to write up an email draft on https://etherpad.opendev.org/p/unmaintained-global-default | 18:54 |
| rosmaita | i won't send until after 2100 utc today | 18:54 |
| rosmaita | thanks everyone! | 18:54 |
| rosmaita | #endmeeting | 18:54 |
| opendevmeet | Meeting ended Tue Feb 13 18:54:52 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:54 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2024/tc.2024-02-13-18.00.html | 18:54 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2024/tc.2024-02-13-18.00.txt | 18:54 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2024/tc.2024-02-13-18.00.log.html | 18:54 |
| spotz[m] | o/ | 19:00 |
| spotz[m] | Dammit got the time wrong! | 19:03 |
| rosmaita | and the time change happened like 2 months ago! | 19:03 |
| clarkb | iceland time is basically the same as utc if you need to put it in your calendar | 19:03 |
| spotz[m] | I blame FOSDEM | 19:03 |
| clarkb | I also have a reykjavik clock on my phone | 19:03 |
| spotz[m] | I could have sworn I had an open hour between finance and tc:( | 19:05 |
| spotz[m] | Ok just checked I blew it on my own can’t blame the calendar | 19:06 |
| knikolla | i'm sure a gremlin changed it back so you would doubt yourself. | 19:08 |
| rosmaita | tc-members: email draft is ready for review: https://etherpad.opendev.org/p/unmaintained-global-default | 19:14 |
| spotz[m] | Calendars are hard. Looking | 19:15 |
| spotz[m] | Should be OpenStack vs openstack I can fix if you want | 19:18 |
| dansmith | rosmaita: looks like it covers my points (to the letter in some cases ;P ) | 19:19 |
| rosmaita | :D | 19:19 |
| gmann | lgmt, thanks | 19:19 |
| rosmaita | spotz[m]: the gerrit group name is all lowercase | 19:21 |
| rosmaita | https://review.opendev.org/admin/groups/4d728691952c04b8b2ec828eabc96b98dc124d69 | 19:21 |
| spotz[m] | Ok | 19:22 |
| knikolla | rosmaita: lgtm, very clear and to the point. | 20:23 |
| rosmaita | knikolla: ty | 20:24 |
| JayF | rosmaita: I couldn't come up with good wording for it, but it seems like it might be a good idea to indicate that there's no real responsibility beyond to the patches you approve, in the global unmaintained group | 22:45 |
| rosmaita | JayF: already sent the email, but that would be good for the documentation | 22:47 |
| fungi | could also be something tonyb and elodilles clarify in their upcoming message | 22:57 |
| tonyb | I think we can include that | 23:07 |
| gmann | I think there is more than just approve the patches because project wise maintainers in that group still need to keep their project unmaintained branch CI thing up to date and also validate the backports | 23:09 |
| gmann | they are doing it project specific group or from global group that is what options we are giving to them | 23:10 |
| fungi | well, sure, approving patches does very little good if they can't merge. but they also don't have to maintain testability by themselves. they can approve changes other people have written to fix testing | 23:12 |
| gmann | so who is going to maintain the CI on unmaintained branches ? | 23:13 |
| gmann | my understanding is it is group of people from unmaintained core group either it is from global group or project specific? | 23:14 |
| gmann | or we are saying if you want to take responsibility of CI maintenance of your project unmaintained then you need to create project specific unmaintained core group | 23:15 |
| fungi | if nobody maintains the ci for those branches, changes aren't going to merge, so it does little good to approve them | 23:19 |
| fungi | "maintaining ci" for those branches can also be as simple as removing all the jobs that are failing | 23:20 |
| gmann | sure but we have to be explicit and clear about who is going to maintain the CI there if that is going to be project specific unmaintained core then we should tell projects to create one in such case | 23:20 |
| gmann | that is what we have in doc also "Additionally, each project may have (but is not required to have) a Gerrit team called PROJECTNAME-unmaintained-core to handle all work on that project’s Unmaintained branches." | 23:20 |
| gmann | https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintained-branch-maintenance | 23:20 |
| fungi | i think we can just say that if nobody has the time or desire to sustain the branches sufficiently in order to merge anything, then there's no point in asking to continue to keep them open | 23:21 |
| gmann | we need to make sure we convey the same in email or just direct to this link for that | 23:21 |
| fungi | the whole point of this is that there are no responsibilities. if nobody cares about unmaintained branches they just go away, and that's perfectly fine | 23:22 |
| gmann | that is true I am saying where we are asking people to join unmaintained global group instead of project specific group we should tell them project specific group is someone need to maintain CI | 23:22 |
| fungi | that was the deal we struck with people who wanted to keep the branches around, really. if you don't show up and keep them working, they're going to get deleted. too bad | 23:22 |
| fungi | it's the same whether you're in a global group or a project-specific group. there are no responsibilities really | 23:23 |
| fungi | either things are kept working and you can ask to renew them for another cycle, or they aren't and they get deleted | 23:24 |
| fungi | we're done assuming someone will show up and keeping the lights on just in case they eventually do | 23:24 |
| gmann | I am not talking about that context. I am saying people want to be part of unmaintained group (global or project specific) has volunteer to maintain them | 23:25 |
| gmann | if they do not want they can move away from this group so that it will be clear who all volunteer to maintain them | 23:26 |
| fungi | i don't think they're volunteering for additional responsibility. they're asking for access to do things because they want to have that option | 23:26 |
| gmann | you mean from global group or project specific group or both ? | 23:27 |
| fungi | there should be no expectations in either direction (users can't expect these branches to be maintained, and the people in the review group can't expect the branches to stick around if they don't keep them working) | 23:27 |
| gmann | access of doing things is one thing but maintaining those in one. later one is something we should be clear about here otherwise everyone will be in blank world | 23:27 |
| fungi | well, these branches are not maintained, that's why we call them "unmaintained" | 23:28 |
| gmann | *not maintained by project upstream team* | 23:28 |
| fungi | they're open, and some people might keep testing working and approve some changes on them, or they might not and the branches will get deleted | 23:29 |
| gmann | but they can be maintained by external members user of them or so otherwise we can just delete them | 23:29 |
| gmann | for that I see project specific group can be good and clear message that if you want to be part of that group means you are maintaining it - https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintained-branch-maintenance | 23:29 |
| gmann | and global group can be there for access things and approve if no other members there or so | 23:30 |
| fungi | but what recourse is there if they don't? the branches just get deleted, same as if there wasn't a project-specific group for it | 23:30 |
| fungi | i don't see the distinction, personally | 23:30 |
| gmann | I think that is what we wrote in this doc right - https://docs.openstack.org/project-team-guide/stable-branches.html#unmaintained-branch-maintenance | 23:31 |
| gmann | not sure if that is very explicit or not but i read the same from here especially "...PROJECTNAME-unmaintained-core to handle all work on that project’s Unmaintained branches." | 23:31 |
| fungi | it doesn't say that anyone is expected to do those things, just that they have access to do them | 23:31 |
| gmann | *all work* include CI maintain or so not just approve thing right | 23:32 |
| gmann | 3rd paragraph says that for project specific group | 23:32 |
| fungi | it says "to handle all work" but it doesn't say that the work must be handled | 23:33 |
| fungi | like with just about everything else in openstack, you can't force people to take responsibility. and if they don't, the branches go away | 23:33 |
| fungi | and that's true whether or not they make a special project-specific group for it | 23:34 |
| fungi | i guess what i was trying to get at is that changes to keep testing working (or to remove broken testing) is still changes to those branches, and if you don't have passing ci jobs then nothing else is going to be able to merge, so either you care enough to prioritize that or there's no point in keeping the affected branches open for another cycle and you don't ask to renew their status | 23:40 |
| fungi | you can be in openstack-unmaintained-core or in nova-unmaintained-core and not care about fixing testing for nova's unmaintained/yoga branch, but if nobody else does either then don't ask to keep the branch going next cycle | 23:41 |
| fungi | it seems pretty straightforward to me | 23:42 |
| ianychoi | Hi TC, heading up as an election official - https://review.opendev.org/c/openstack/election/+/905152 proposed by tonyb is pending and I think TC’s consolidated opinion regarding the proposed schedule would unblock the pending. | 23:49 |
| fungi | circling back around to the murano situation, i see andy botting just offered to take over as ptl, so i was looking at what would be involved on the launchpad side of things (because of the current vulnerability report), the https://launchpad.net/murano project is driven and maintained by https://launchpad.net/~murano-drivers which is not owned by https://launchpad.net/~openstack-admins | 23:50 |
| fungi | and the only administrator for that team is no longer around, so we probably can't bootstrap a new ptl there without involving the lp administrators | 23:51 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!