| fungi | clarkb: yeah, we went through that earlier in the conversation, the reason i added signed-off-by to all the change proposal scripts before openstack switched from cla enforcement to dco enforcement is that it was the only way to keep them working | 12:20 |
|---|---|---|
| fungi | i brought that to the attention of the tc at that time, also discussed briefly with jbryce just to make sure there were no concerns with that pragmatic approach | 12:21 |
| fungi | and we discussed that if it did end up leading to confusion, the tc could issue some sort of statement/resolution to clarify it | 12:22 |
| fungi | maybe the line that can be drawn is that it's acceptable for automation in one of our own projects to sign-off its own proposed changes (with corresponding generated-by trailer to document where that script is maintained) because the routines in the script were contributed under the cla or dco, which can be verified from their history in our repositories and the original | 12:30 |
| fungi | developers identified | 12:30 |
| fungi | if someone in openstack develops an llm and supplies all the training data under licenses acceptable to the project and maitains all that in an openstack deliverable under the dco, then it might also be fine for that llm to sign off on its own proposed changes? | 12:31 |
| *** bauzas3 is now known as bauzas | 13:07 | |
| sean-k-mooney | fungi: i dont think that level of isolation is required | 14:38 |
| sean-k-mooney | fungi: i.e. effectiovly from scratch traing of an llm | 14:38 |
| sean-k-mooney | that woudl be incredibly counter productive | 14:39 |
| fungi | i didn't say it's required, i posed it as a scenario of something that might qualify | 14:39 |
| sean-k-mooney | will i think claude or similar coudl qualify we just need to be very clear how to do it correctly and do the disculorus and that at some point in the cain be it review or before there has to be a huma in the loop | 14:40 |
| fungi | then we can work backward from something that would clearly qualify to determine where the line is that means something doesn't qualify | 14:40 |
| sean-k-mooney | i.e. if a humaan descibes the probelam and ask the llm to do the thing its fine if the llm just does it on its own with no human input its not | 14:40 |
| sean-k-mooney | fungi: nividia took an interestin approch with openshell | 14:41 |
| sean-k-mooney | they requrie all contibution to be done by a huma using an llm/agentic flow | 14:42 |
| sean-k-mooney | but they also requrie that the human must understand the code they contibut and apply the dco | 14:42 |
| sean-k-mooney | https://github.com/NVIDIA/OpenShell/blob/main/CONTRIBUTING.md | 14:42 |
| sean-k-mooney | the interprtion being all contibution my be done agenticly btu you must have a humanin the loop | 14:43 |
| fungi | from my perspective, i'd delete "llm" or "ai" from the argument entirely. would we accept changes proposed by software/scripts we've written as a community running within our project infrastructure? well, we do that already. what about a script running on some developer's workstation that auto-proposes changes on their behalf? i dunno... | 14:43 |
| sean-k-mooney | well we already use indiviual script form out desktops in limit csaes | 14:44 |
| sean-k-mooney | like some of the releas patches | 14:44 |
| fungi | do those scripts operate autonomously, or are you initiating them? | 14:44 |
| sean-k-mooney | runing them by hand i.e. the tox target to tage a new release ectra | 14:44 |
| sean-k-mooney | that does 99% of the patch crfeation and you really just wrte the commit message | 14:45 |
| fungi | and are you personally vouching for their output, or are they only vouching for themselves? | 14:45 |
| sean-k-mooney | you are vouching for the output. IMO if you submit it it yoru responsiblity to ensure it correct | 14:45 |
| sean-k-mooney | so again that coming back to "there is a human in the loop" saying it ok | 14:46 |
| fungi | right. now what if it's a script submitting it instead? is that where we draw the line? | 14:46 |
| sean-k-mooney | i dont know. | 14:47 |
| fungi | we do allow that for scripts we maintain as a community which run within the infrastructure we collectively manage based on criteria we've set together | 14:47 |
| sean-k-mooney | there could even be a midel groud where we allow them to be pushed for review but in a draft/wip state or somethign where you ahe to go do somethign or with a spcific hashtag to say "bot proposed" | 14:47 |
| fungi | but also, no matter what gets submitted, and whether by a human directly or some autonomous system, we (today) don't allow automated systems to approve proposed changes to merge, so we always have a human in the loop | 14:48 |
| sean-k-mooney | i doubt that will change anytime in the next decade | 14:49 |
| fungi | so it's really more about what reviewers are comfortable approving, and not about whether these systems are operating entirely independent of any human oversight | 14:50 |
| sean-k-mooney | thre is just too much fo an attack surface or abuse vector | 14:50 |
| sean-k-mooney | fungi: right if a review does not understand the patch even if it form SUPPER_ULTRA_MAX_IQ llm they shoudl not accpet it | 14:51 |
| sean-k-mooney | its instance technial debt even if it works perfectly | 14:51 |
| frickler | tc-members: FYI zun looks terribly broken https://review.opendev.org/c/openstack/zun/+/957410 didn't someone have some kind of contact to the PTL? | 17:12 |
| cardoe | oof | 17:14 |
| fungi | 2026-02-26 was the last successful run of their pep8 job, so exactly a month ago | 17:16 |
| gouthamr | but, other jobs seem to be broken for a bit longer | 17:17 |
| gouthamr | frickler: could you/release team email the openstack-discuss list? hongbin's got an in-progress patch for something else and may already be aware | 17:18 |
| fungi | unit tests seem to be failing on an sqlalchemy behavior change | 17:21 |
| gouthamr | yeah, a deprecated/removed enginefacade | 17:21 |
| gouthamr | and more stuff i think: https://review.opendev.org/c/openstack/zun/+/959295 | 17:22 |
| fungi | last master branch unit tests passed 2026-01-21 | 17:23 |
| fungi | so it's all been broken since long before 17.0.0.0rc1 was tagged and stable/2026.1 branched | 17:26 |
| fungi | we're about out of time for a 17.0.0.0rc2 and so will likely be releasing an entirely broken zun 17.0.0 for 2026.1/gazpacho | 17:27 |
| frickler | yes, somehow it was missed from the CI checks this cycle | 17:28 |
| mnasiadka | So what’s the drill? It’s probably too late to remove it from the release? | 17:29 |
| fungi | it could release 17.0.0 broken and then backport fixes from master to stable/2026.1 for a later 17.0.1 or 17.1.0 | 17:30 |
| fungi | it's one of those "which is the least terrible option?" debates | 17:31 |
| clarkb | release candidates are just that: candidates. I think one option is to indicate that the release candidate process exposed fatal flaws and a final release won't eb made | 17:32 |
| clarkb | this assumes that there isn't a heroic effort to fix it in the interim I guess | 17:32 |
| fungi | yes, also a terrible option, but whether it's more or less terrible than the others is hard to say | 17:32 |
| gouthamr | for this exact issue in the past, we've stalled the oslo.db release and UC update so as to not break a few services | 17:34 |
| fungi | but in that case it was a type:library release-model:cycle-with-intermediary while zun is type:service release-model:cycle-with-rc | 17:36 |
| gouthamr | but we're past all that now. i think we need to post this on openstack-discuss right away and discuss our limited options | 17:36 |
| fungi | probably the least work on the release team is to go ahead and include a broken zun 17.0.0, since release jobs are still working for it | 17:38 |
| clarkb | thats a good point. The metric to optimize for is probably least disruption to the release team and process. And ya making a broken release and documenting that it is broken is probably the thing that does that | 17:41 |
| sean-k-mooney | i had to fix the same thing in cyborg thi cycle | 18:11 |
| sean-k-mooney | it ended up beeing rpetty simple in the yed to adopt the new enginge facade | 18:11 |
| sean-k-mooney | https://review.opendev.org/c/openstack/cyborg/+/974911 | 18:14 |
| sean-k-mooney | that does not negate the fact that even with takashis fix for that sqlachme issue that there are more failrues | 18:16 |
| mnasiadka | And there’s only one maintainer not being overly active looking at git log | 18:16 |
| gmaan | Usually whenever i needed, i add hongbin in gerrit review and he merge things but I have not interacted in recent time | 18:17 |
| gmaan | gouthamr: or sending email also worked for me in past (keeping his personal email also in ML). | 18:18 |
| gouthamr | +1 that's something we could probably do by default whenever the release team finds issues like this.. | 19:20 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!