| opendevreview | Mauricio Harley proposed openstack/governance master: Add PQC Migration popup team https://review.opendev.org/c/openstack/governance/+/982062 | 09:51 |
|---|---|---|
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: [www] Setup 2026.2 and add project data to 2026.1 Gazpacho https://review.opendev.org/c/openstack/openstack-manuals/+/981757 | 12:40 |
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: [www] Set 2026.1 Gazpacho as released https://review.opendev.org/c/openstack/openstack-manuals/+/981758 | 12:40 |
| opendevreview | Elod Illes proposed openstack/openstack-manuals master: Add note for reno link update for release task https://review.opendev.org/c/openstack/openstack-manuals/+/982088 | 13:22 |
| lajoskatona | jbryce_: Hi, (I hope) quick question: For AI there is a whitepaper (https://www.openstack.org/openstack-for-ai-white-paper ) and there was a mail thread started by Kendall / diablorojo: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/X2NL3XFOSW7ZWZBWQJ3M7SJLDFVONQHZ/ | 18:26 |
| lajoskatona | Do you know perhaps that there will be something like an AI ceritficate for Openstack clouds like k8s have from CNCF (perhaps this blogpost : https://techforward.io/cncf-sets-ai-standards-with-certified-kubernetes-program/ )? | 18:27 |
| fungi | if you're currently at kubecon eu, you might be able to corner him in person, i'm not sure | 18:31 |
| lajoskatona | fungi: :-) sadly I am not there | 18:36 |
| fungi | ah, just figured i'd suggest the option. also related, he's probably more distracted than usual this week as a result | 18:37 |
| lajoskatona | fungi: yeah, was just a try as I saw his nick in the list, but my conscious mind already told that this week is not the best week for this question :-) | 18:43 |
| fungi | i've also asked in some internal foundation channels when you brought it up initially on monday, but basically all of those people are away/travelling for obvious reasons | 18:45 |
| clarkb | I do wonder what that would mean in the context of openstack. Is it basically "your cloud is new enough to support pcie passthrough and/or virtual gpu slicing" ? | 18:46 |
| fungi | my personal opinion is that openstack providers should engage with cncf on getting included, and if they run into logistical challenges then we know who to reach out to on their behalf | 18:47 |
| fungi | we're all in this together, cncf are our friends, and openstack is the most common platform for running kubernetes on (regardless of what some megacorps would like you to believe), so it makes sense to collaborate on this effort rather than compete with it | 18:48 |
| lajoskatona | fungi: +1, I hope as we are all under LF umbrella this will be a simple thing, but I am not good at these things just got this question from our prod manager or similar | 19:02 |
| fungi | also it can't hurt to put your product manager in touch with openinfra/cncf foundation staff about stuff like this, you don't always have to play middle-man | 19:05 |
| lajoskatona | fungi: I have tears in my eyes after this sentence :-) Would be x-mass if that ever happens :-) | 19:10 |
| sean-k-mooney | fungi: gmaan mentione dthat our bots are currently addign signed off by to the bot generated patches. which makes snse based on our gerrit requrieemnt but i did want to highlight that that may have some leagal consdieration with the DCO | 19:43 |
| sean-k-mooney | https://github.com/torvalds/linux/blob/bbeb83d3182abe0d245318e274e8531e5dd7a948/Documentation/process/coding-assistants.rst?plain=1#L27-L59 | 19:43 |
| sean-k-mooney | fungi: at least the kernels stance is that legally only humans can certify something under the DCO adn as such bots and i guess script shoudl nto use Signed-off_by | 19:43 |
| gouthamr | they're not AI agents though? | 19:44 |
| sean-k-mooney | right but the same logic applies ot any non human created commit | 19:44 |
| sean-k-mooney | the assertion there isnt that llms cant set it it that only humans can | 19:44 |
| sean-k-mooney | implying the person that ran the scritp to getnerated the comman shoudl be the one that signed it off | 19:45 |
| sean-k-mooney | now i know ssome of our patches are based on merge triggers or perodics | 19:45 |
| sean-k-mooney | so that wont work in that case but jsut a thing i realise earlier today that its not clear that it correct for any of the bot patches to use signed-off-by | 19:46 |
| sean-k-mooney | but in practice its requried for our gerrit config | 19:46 |
| fungi | sean-k-mooney: previously, the gerrit accounts which pushed those commits were pre-added to gerrit internal groups used to reflect users who agreed to the cla, so it's mostly just porting from cla to dco in that regard | 19:47 |
| gouthamr | i agree with that in principle, but, is there similar guidance for auto generated patches at all, without AI .. our AI policy requires explictly requires human in the loop | 19:47 |
| spotz[m] | I haven't seen Jonathan, Allison, Kendal or Helena at all. I've seen Ildiko and Thierry though | 19:47 |
| gouthamr | "We generally expect contributions to be made by a human taking an action" | 19:47 |
| fungi | it's also a means of working around gerrit's dco enforcement, since there's not any configuration i'm aware of for allowing specific accounts to bypass the requirement | 19:48 |
| sean-k-mooney | right my internal assertion is we did not allow contibution to be made by a non human upstream | 19:48 |
| sean-k-mooney | gmans counter point was the bots | 19:48 |
| sean-k-mooney | but llm or not i wanted to get clarity on the offical stance of generated patches | 19:48 |
| sean-k-mooney | hypotectical. i have an ai review tird-party ci | 19:49 |
| sean-k-mooney | it has a gerrit acocunt | 19:49 |
| gouthamr | don’t allow it to submit code changes :) | 19:49 |
| fungi | i don't think the openstack tc has published any such guidance. the openinfra foundation has a policy which applies to openstack | 19:49 |
| sean-k-mooney | my current unerstanding is i cannot implement a feature where on a comment it would cherry pick a patch to a specific branch resovlign any merge conflicts | 19:49 |
| sean-k-mooney | gouthamr: i dont but it has implications for any form of agentic ai or simialr | 19:49 |
| sean-k-mooney | even static script taht woucl cherry pick (where it applies cleanly) | 19:50 |
| sean-k-mooney | woud in theory not be compleint with the DCO unless the commit was signed and sobmited manully by the human | 19:50 |
| sean-k-mooney | correct it at the foundation level https://openinfra.org/legal/ai-policy | 19:51 |
| sean-k-mooney | not within onpenstack itself | 19:51 |
| fungi | to be clear, the current policy is why i adjusted all the scripts pushing patches under those automation accounts to include generated-by trailers | 19:51 |
| sean-k-mooney | yep which i agree with | 19:52 |
| fungi | even though it was technically about ai-oriented automation and not deterministic automation | 19:52 |
| sean-k-mooney | i think that is correct | 19:52 |
| sean-k-mooney | i dont think there really is a diffent between deterministice vs non determinsitc | 19:52 |
| fungi | so back to the original decision, if you personally volunteer to receive all the automatically generated patches and push them to gerrit under your own account so you can add a signed-off-by that doesn't require the script to sign for itself, i'm happy to hook you up ;) | 19:53 |
| sean-k-mooney | the larger question i have really is that uner https://openinfra.org/legal/ai-policy our expection is there is alwasy a huma in the loop before it is pushed for review | 19:53 |
| fungi | otherwise we have to stop using gerrit | 19:54 |
| fungi | 's built-in dco enforcement feature | 19:54 |
| sean-k-mooney | fungi: well im not saying the the bot is nessiarly wrong | 19:54 |
| sean-k-mooney | or bot geenreted patches and the current gerrit enforcement | 19:54 |
| sean-k-mooney | im asking does that have implciation for other tools | 19:55 |
| sean-k-mooney | i.e. a cherry pick both that will automaticlly cherry pick on a comment | 19:55 |
| sean-k-mooney | or any other type of automation llm or not | 19:55 |
| fungi | note that "signed-off-by" is contextual, and openstack gets to decide for itself what someone or something adding that trailer means. so you could just ask for the tc to publish a resolution saying when a script adds signed-off-by it's a means of bypassing internal checks within the code review system that prevents any account from pushing a commit without that trailer | 19:55 |
| fungi | openstack could easily declare that when a human adds a signed-off-by trailer it's an indication that they agree to the terms of the dco, and when an automated system adds a signed-off-by trailer then it's merely a mechanical workaround (like adding those accounts to the cla group was before we switched to the dco) | 19:58 |
| sean-k-mooney | ya that woudl be ok i guess. | 19:58 |
| fungi | and could make an explicit carve-out for deterministic script-generated commits triggered periodically or by explicit events like release publication | 19:59 |
| sean-k-mooney | i just wanted ot undersnad the implication of it in our interpution rather then askign for a change | 19:59 |
| sean-k-mooney | for example in the "no chagne" case you can to the cherry-pick automaticly with a currl to the gerrit endpoint and it will do it for you | 19:59 |
| sean-k-mooney | right so that is deterministic | 20:00 |
| sean-k-mooney | if there is a conficlt llms coudl resovle that in principal but i was trying to see where that woudl land | 20:00 |
| gouthamr | seems like good rationale to me, this area is currently in flux, the board is discussing this: https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.org/thread/B6RFW55FEH2632VD7IEDPCR67TBF7XZQ/ | 20:00 |
| fungi | in my non-lawyer opinion we previously operated on the assumption that entirely script-generated changes are mere transformation of existing data not copyrightable by anyone and falling into the public domain (at least in jurisdictions which have such a concept) | 20:01 |
| sean-k-mooney | like to me a python or bash script that can solf 90% of such fonflict and an llm are identical | 20:01 |
| sean-k-mooney | hum havent read that yet | 20:01 |
| fungi | i totally get where it's a fuzzy line between an llm-based program and any other program generating commits. we have prior art for accepting scripted changes that are automatically proposed by our tooling (after some amount of human review), and i did bring it up in the very earliest discussions the board started having about the need for an "ai policy" years ago, but at the | 20:03 |
| fungi | time they wanted to pretend like those were completely different concepts | 20:03 |
| fungi | to some degree, the aforementioned generated-by trailer use in those scripts was a form of malicious compliance because i felt like it was an unclear distinction | 20:04 |
| fungi | for many years we had already been using routines that based on any reasonable description would qualify as a form of "ai" just as much as an llm | 20:05 |
| fungi | and i personally don't get what all the excitement's about, but i still basically avoid using any llm tools so i'm sure i'm missing out on something great | 20:06 |
| sean-k-mooney | llm dont make work not work. it still requires a lot of human effort and reasonsing. | 20:09 |
| fungi | the few times i've tried to use one, i spent more time telling it what i wanted and correcting its mistakes (and bonking it on the nose with a rolled-up newspaper when it piddled on the carpet) then i would have just doing it myself | 20:09 |
| sean-k-mooney | what it does do is lower the barrier to entrey for those with good locical thinigking and reasoning | 20:09 |
| sean-k-mooney | i find them userful but i treat everytign that comes out of them as a human create patch and engage my core review brain | 20:10 |
| fungi | from what i've seen, it lowers the barrier of entry to the dunning-kruger effect | 20:10 |
| sean-k-mooney | if i did not have year of review expicne i dont think i coudl find them as useful as i do | 20:10 |
| fungi | but then again i'm on the receiving end of too much llm-generated slop from people who don't understand the output, and get bitter when it wastes my valuable time | 20:11 |
| sean-k-mooney | ya, so i think as a maintianer i have the context of the project and can effecitivly express that to the llm and i knwo when what its doing is wrong institivly | 20:12 |
| sean-k-mooney | i think it woudl b ea very diffent story in a code base i dont know | 20:12 |
| sean-k-mooney | in fact the one time i tired to use it to root cause a narly eventlet bug (that turned out to be a cypython one) it lead me down a very wrong path | 20:13 |
| sean-k-mooney | although to be fair ti it it did exaclty what i asked it to. i asked it to reposecue a behvior, and then i asked it to fix the behvior | 20:14 |
| sean-k-mooney | i didnt understand the repoducer was not the same as the bug even if the stack trace was | 20:14 |
| fungi | sadly, too many people think that subsidized access to environment-destroying llm tokens gives them free license to propose changes they don't understand to projects they have zero familiarity with the internals on, and expect that the maintainers' time has no actual value | 20:14 |
| clarkb | I haven't read all the scrollback but it is important to notethat none of our bots are AI systems | 20:15 |
| fungi | i'm hoping that when these "ai" startups are finally pressed to start turning a profit instead of operating on limitless vc capital, the cost of using their services will become a deterrent to this sort of abuse | 20:15 |
| clarkb | they are deterministic tools automating deterministic outcomes | 20:15 |
| clarkb | there is no training data, there is no hallucinating, there are no copyright claims. Its more akin to a compiler | 20:16 |
| clarkb | they take a specific input and create a reproduceable specific output | 20:16 |
| clarkb | this is very different to AI tools generating things out of a massive neural net | 20:16 |
| fungi | clarkb: yeah, to catch you up, the main question there is whether, in the absence of any specific policy about it, adding signed-off-by in those scripts in order to get them into gerrit is against the spirit of the dco | 20:17 |
| clarkb | I don't think so. The DCO says "I have permission to push this" which the system does becuse we gave it permission and because there isn't any real ownership involved | 20:17 |
| clarkb | i'm not a lawyer but I think think those are the two important aspects ownership and permission | 20:18 |
| fungi | yeah, and whether an automated system can declare anything on behalf of itself leads into the realm of existential philosophy | 20:18 |
| clarkb | again I'm not a lawyer: but I think the way to look at it is "what is the risk to the project for accepting these commits?" The reason you apply the DCO is to mitigate risk. The person pushing the code says that they own it and have permission to contribute it. AI/LLMs complicate this because it isn't clear what the ownership is and whether or not you have permission to take the | 20:21 |
| clarkb | contribution. Forcing a human to say "I own it and I have permission" is another mitigation against that even if the LLM did most of the work. WIth these automated synchronization tools I don't think those concerns exist | 20:21 |
| clarkb | but again I'm not a lawyer. But I do think it is a fundamentally different situation when viewed from the perspective of why the DCO is used in the first place | 20:22 |
| sean-k-mooney | clarkb: from my perspetice deremeitstic or not has no impact on "can a non human entity add signed of by" | 20:23 |
| sean-k-mooney | to me a cronjob and a llm reacting to a gerrit comment are identical | 20:24 |
| clarkb | I firmly disagree | 20:24 |
| sean-k-mooney | but taht just my opion | 20:24 |
| clarkb | code generation is not a new thing | 20:24 |
| sean-k-mooney | in the cherry pick case ist also not strictly reuried to add signed fo by if you dont modify the commit | 20:24 |
| clarkb | code generation that comes out of a neural net is | 20:25 |
| sean-k-mooney | clarkb: correct and llm sare jsut code token gnereators | 20:25 |
| clarkb | they behave very differently in terms of expected outputs from the inputs | 20:25 |
| sean-k-mooney | so do compiler form release to release | 20:25 |
| clarkb | yup but if you use the same version of a compiler with the same arguments you will get the same outputs every time | 20:25 |
| fungi | "deterministic" is also a somewhat vague concept for someone with a background in mathematical fields like chaos theory and fractal topology, where determism is merely a factor of knowing the initial state and governing algorithms | 20:25 |
| sean-k-mooney | well with the same seed and inital state llms shoudl be determistic | 20:26 |
| fungi | by some interpretations, every llm is deterministic, yes | 20:26 |
| sean-k-mooney | they sue determistic algrotimes for the inference modulo floating poitn ronding errors | 20:26 |
| clarkb | aiui llms intentionally mix in randomness | 20:27 |
| sean-k-mooney | contrled by a parmter called temperatrue | 20:27 |
| sean-k-mooney | *temperature | 20:27 |
| gouthamr | don't dependabot/renovate other open source non-AI tools do this sorta thing already in other open source projects? | 20:27 |
| fungi | even variables like quantum noise and stray cosmic particles impacting your ram are deterministic depending on how you scope the system and conditions | 20:27 |
| sean-k-mooney | which is a direct refence ot entropy | 20:27 |
| sean-k-mooney | gouthamr: they dont normally add signed off by | 20:28 |
| gouthamr | they do | 20:28 |
| clarkb | gouthamr: yes this isn't a new or novel thing. It is also similar to code generation (which python libraries like the kubernetes or is it openshift library make extensive use of as do bindings for things like protobufs and similar things) | 20:28 |
| fungi | yes, "entropy" is not "randomness" (which depending on your chosen model of physics can be considered fictional) | 20:28 |
| gouthamr | clarkb: yes, i'm hunting for a very similar example | 20:29 |
| clarkb | I think there is a claer set of tools that are on one side of this problem and another set of tools that are on the other. And the differences come down to where the output data originates and whether or not it is determinsticic | 20:29 |
| sean-k-mooney | gouthamr: not in the ssystem i hve seen https://github.com/openstack-k8s-operators/nova-operator/pull/1067/changes/36bca9c837388a0a2f913178d884914b50e2e408 | 20:29 |
| clarkb | in the case of dependabot or our requirements updates a specific tool with specific behavior that doesn't change has been created | 20:29 |
| sean-k-mooney | although perhasp that jsut hiden in the github ui | 20:29 |
| gouthamr | or, DCO isn't required for that repo? | 20:29 |
| sean-k-mooney | it is not | 20:30 |
| clarkb | there is no ownership of the output (there may be ownerships of the inputs like with translations but our translators give us permission to use their work) | 20:30 |
| sean-k-mooney | gouthamr: that is not an openstack repo | 20:30 |
| sean-k-mooney | so you can cofnigure theyse tools to do it but they dont do it universally | 20:30 |
| clarkb | where thinsg get muddy with llms is they have taken the entire work of human kind and synthesize it through a neural net with a hint of randomness to produce something not wholly new or clearly owned | 20:30 |
| clarkb | and that creates a situation where if you're concerned about risk you may wish to mitigate against it. I don't believe the same risk exists wit ht he way we automate certain actions | 20:31 |
| gouthamr | sean-k-mooney: https://github.com/containers/podman/pull/27255/changes/aaf957edf980aa8522bab39669ec656f2af7782e | 20:31 |
| clarkb | but again I'm not a lawyer | 20:31 |
| gouthamr | here's an example ^ | 20:31 |
| clarkb | it is also worth noting that the kernel can decide to treat this one way and we can decide to treat it another | 20:31 |
| sean-k-mooney | gouthamr: yep as i said this i confgurabel in renovate | 20:31 |
| clarkb | there is no hard global rule. Its more a framework with some common expectations | 20:31 |
| gouthamr | clarkb: from this discussion, it appears this is worth clarifying in our policy | 20:32 |
| gouthamr | we're taking the common sense approach. | 20:33 |
| gouthamr | but that's probably confusing as more things show up.. | 20:33 |
| clarkb | to put it another way i think its crazy that no one has problems with incorporating claude generated code outputs with unclear ownership whiel at the same time we are concerned about a tool editing requirements files that can't really be owned. I'm like 80% certain I helped write most of these automated bots too and if anything I would be the owner of the outputs and I'm saying | 20:33 |
| clarkb | its fine | 20:33 |
| clarkb | (and the cla forced us to say it was fine explcitiyl when they were written) | 20:34 |
| clarkb | none of that exists for claude right now but we have no qualms with it | 20:34 |
| gouthamr | Claude explicitly wants to say: "not mine" for lots of reasons :P | 20:34 |
| * gouthamr was kidding, there's nuance there | 20:34 | |
| fungi | though claude does say you're not allowed to use its output to compete comercially with anything its owner decides to go into business doing | 20:34 |
| gouthamr | can't wait for that to be litigated someplace | 20:35 |
| clarkb | if we think about it from the ground up the autoamted bots we have sync requirements related stuff and they sync translations (there may be other cases but these are the big ones I'm aware). I believe the first case was for translations which I was the original author of. When I pushed the code it was under the old CLA so I explicitly gave permission for the project to use the | 20:37 |
| clarkb | code I wrote for this prupose. Then we set up accounts and acls allowing the bot to push the code back to gerrit. Creating the next step of permission | 20:37 |
| clarkb | and our translators are supposed to agree to the cla and now dco when making their contributions to the translation system. So they too have given their permission to use their work. Every step of the way has given claer permission for things to be used within the project | 20:37 |
| clarkb | to me signing the dco under these circumstances is reasonable | 20:38 |
| sean-k-mooney | clarkb: im not objecting to the existing bot change having signed-off-by | 20:39 |
| sean-k-mooney | clarkb: i was highlighti8ng that the linxu docs say "can only be added by humans" and wondering where we draw the line | 20:40 |
| sean-k-mooney | i.e. if i build a cli or corn jobto cherry pick my merged bug patch can it run git review to submit it (adding the the seigne off by if needed) or no? | 20:41 |
| clarkb | sean-k-mooney: I think if the process was not resolving merge conflicts via non deterministic tools like llms then there wouldn't be any issue in doing that from my perspective. It is worth noting taht the tools we have that run today do not resolve conflicts either | 20:42 |
| sean-k-mooney | for now for what its worth if im doing somehting like that i manually drive it adn woudl end up git amendign to add signed-off-by when im runing the test ecrtrea before i push | 20:42 |
| clarkb | there is no judgement involved as would be required in such cases | 20:42 |
| clarkb | also I don't think it should be something you run on your local machine | 20:43 |
| clarkb | it should be something the project owns colelctively via our automation tooling | 20:43 |
| clarkb | if you run it locally then you should be applying your personally signed off by and using your personal account | 20:43 |
| gouthamr | imho, linux docs govern the kernel, not OpenStack code. they're making the distinction for AI generated patches - which is good imo, something we can emulate and continue discussing in our space. sean-k-mooney's bot should create its own gerrit account and use "signed-off-by" - it's required. agree, you can donate the bot to opendev if you'd like to standardize on this process | 20:44 |
| gouthamr | i'd like a cherry-picking bot sometimes, would like to invoke it on a comment and stop doing things manually | 20:44 |
| sean-k-mooney | well it has its own account and techinally email | 20:44 |
| clarkb | you can even have gerrit do it for you | 20:44 |
| clarkb | you just have to decide when to requset gerrit does it | 20:44 |
| sean-k-mooney | clarkb: yep i noted you coudl just curl the api | 20:45 |
| sean-k-mooney | in the case there is no conflict | 20:45 |
| sean-k-mooney | it will do the right thing | 20:45 |
| clarkb | right, and to be clear I think conflict resolution starts to fall into the space where you actually want a human looking at it | 20:45 |
| fungi | while the linux kernel community does follow a very similar review workflow to our own, a major difference is that reviewers also sign off on commits before they're merged, as i understand it, so changes proposed by an automated system wouldn't need to supply their own signed-off-by because there's some other human also vouching for them in the commit message | 20:45 |
| clarkb | so those cases are already out of scope imo | 20:45 |
| fungi | we do our reviewing through labels in gerrit instead | 20:45 |
| fungi | and while those show up in git notes, they're not included in the commit message itself | 20:46 |
| sean-k-mooney | clarkb: im just using the "need conlfict resolution" case as an exmaple of a non trivial action | 20:46 |
| sean-k-mooney | i.e. some change is requried but ya i general agree | 20:46 |
| sean-k-mooney | fungi: ya that is also tree. those labs can be included with a diffent merge strage i.e. the rebase-alwasy one | 20:47 |
| sean-k-mooney | that waht we used to do downstream so that the reviews adn appvoals were tracked in the git and srouce we shipped | 20:48 |
| fungi | or gerrit's edit interface could be used by the approver to add a signed-off-by trailer to a change before approving | 20:48 |
| sean-k-mooney | ignorign the retirger of ci yes. | 20:48 |
| sean-k-mooney | agiain im not askign for a change to our gerrit/zuul | 20:48 |
| sean-k-mooney | just trying to understand waht i can and cant do | 20:49 |
| clarkb | what I would suggest is that any action you are making as an individual contributor from your local machine should be recorded as such. Any actions you want to automate within the community can have dedicated accounts as necessary to make that possible. None of these actions should be performed completely automatically if they apply "judgement" eg fixing merge conflicts or | 20:50 |
| clarkb | adding new code via a system like an llm | 20:50 |
| sean-k-mooney | i have not read eoghans mail on agatic development https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.org/thread/B6RFW55FEH2632VD7IEDPCR67TBF7XZQ/ but that related to why i was asking | 20:50 |
| clarkb | if it works like a compiler (the translation updates are essentially compiling translated strings from one system's format to another) then I don't think there are problems | 20:51 |
| clarkb | note that we also intentionally chose not to auto merge teh translation updates even though we technically could. That keeps a human in the loop | 20:52 |
| clarkb | humans are involved in the process of writing the bot, humans are involved in selecting the translations, and humans are involved in accepting the translations | 20:52 |
| clarkb | the only part we have automated is the bit that converts formats | 20:53 |
| clarkb | we are not using llms to write translations, we don't auto approve, etc | 20:53 |
| sean-k-mooney | well even with "agentic devleopement" whateer that end up meaning i think we are alwasy going to have a huma in the loop on the review/merge side of the change | 20:53 |
| clarkb | right and I think the concern there is it becomes trivial to produce code that I the maintainer am now expected to fix for the "contributor" | 20:54 |
| sean-k-mooney | sure we can have ai reviewer too but i dont think we would grant them +2 or at least not +w rights | 20:54 |
| clarkb | some of the push back there I think is simply for everyone's sanity | 20:54 |
| clarkb | if it took you 30 seconds to generate a 2k line change that adds a new feature but takes me a day to review and test then that imbalance is itself a risk (at the personal not legal level) | 20:55 |
| clarkb | re cherry picking specifically I think this is the advantage to the way gerrit does it of pushing things forwrd rather than backward. They basically say you should be fixing the bugs on the oldest branch still maintained that has the issue. Then you can either forward port as part of the process or they do periodic rollups as part of their release process. The problem with this | 21:04 |
| clarkb | is people already dislike a git history full of merges and when you push things forward like this git history gets really weird | 21:04 |
| clarkb | (I am not advocating for this. I just think it is worth noting that other approaches do alleviate some aspects of the backport pain) | 21:04 |
| sean-k-mooney | ya i dont find backporting really to be a pain unless i have to go 8-11 release back downstream | 21:07 |
| sean-k-mooney | our newest downstream product is still based on antelop and we still have supproted release based on train with some special cusotmer on newton | 21:08 |
| gmaan | long chat :) but I somehow agree that if "signed-off-by" non-human (scripts or llm), then there is no one (no one means no human) responsible for the legal or DCO compliance issues. what i see is human vs non-human. but again we can have different perspective on that :) | 22:55 |
| gmaan | code generation from non-llm or llm is not so different things when we talk about DCO or other legal responsibility | 22:57 |
| clarkb | it is massively different. In the case of translations for example the ownership is of the translations themselves and those are owned by a human with a clear chain of custody | 23:00 |
| clarkb | all the automation is doing is transfering the data from one location and format to another location and format so that the translations can function within our code base | 23:00 |
| clarkb | similarly with the requirements updates I don't think that can be owned. its like a recipe its just a list of facts | 23:00 |
| clarkb | and all we're doing is updating a list of facts. | 23:00 |
| clarkb | But I'm not a lawyer so ya we can disagree :) | 23:01 |
| clarkb | similarly with the cherry picking idea the ownership si retrained by the original commit author and all that would be happening is a transfer of the data from one logical location to another within the code base | 23:02 |
| clarkb | this is very different to llms generating code for features or bugfixes themselves | 23:02 |
| gmaan | true but when those recipe are hacked or do a lot more than what is accepted today then it should be owned by someone | 23:02 |
| clarkb | but no one is doing that | 23:02 |
| clarkb | or rather the bots are not doing that | 23:02 |
| clarkb | if someone (a human) does do updatse themselves then they have ownership | 23:02 |
| clarkb | equating an llm generated features to automatically cherry picking something a human wrote is not a good idea imo | 23:04 |
| gmaan | I mean if bots are updated to fix the bugs even it is just a script code or using llm internally then nobody can challenge them? because there is no difference line on what is accepted and what is not when things comes from non-human | 23:04 |
| clarkb | but that wasn't what the conversation was about | 23:04 |
| clarkb | the conversation was about the existing bots that we have and whether or not they are problematic | 23:05 |
| clarkb | (and my assertion is taht they aren't because the bots themselves aren't doing anything ownable and they have permission to push the updates they do push in cases where the data is owned by someone (not something)) | 23:05 |
| gmaan | that is what I am saying we can evaluate this situation based on what bot doing today but it is more of "can a change signed-off-by non-human ok or not"? | 23:06 |
| gmaan | same as I cannot say xyz llm is not doing anything more than just spell fix so give it exception | 23:07 |
| gmaan | but yeah, i am also not lawyer :) so maybe I am overthinking? do not know... | 23:08 |
| gmaan | it came up when sean-k-mooney in internal meeting mentioned that upstream "signed-off-by" is only allowed by human and I said it is not 100% true | 23:09 |
| clarkb | right and I'm saying I think it is fine because when you sign the DCO you assert a) that you are the entity creating the change and you have permission to submit it (these bots did and do) b) you can contribute the content under the license of the project (again I believe this is the case because the work isnt' actually ownable if rebasing or cherry picking or updating dep | 23:09 |
| clarkb | versions based on pip freeze output) c) the contribution was provided by other people asserting these same conditions (this applies in the translation case and as far as I know we do this) finally d) the contribution itself is public info (which is fine for our bots) | 23:09 |
| clarkb | with LLMs I believe that b and c are potentially problematic because the LLMs apply their own licensing terms to their outputs | 23:10 |
| clarkb | and each one is different so it isn't something that can be decided globally for all LLMs. Instead of trying to police that projects like Linux are saying we don't want to figure that out everything needs to come from a human | 23:11 |
| sean-k-mooney | actuul the conversation was not about the exisign bot really it was what infereicne can we draw form the exisitng bot patterns that woudl impact furue tools and agentic workflows | 23:12 |
| sean-k-mooney | i pointed out that the exisitng bots seam to be setting a precended that signed-off-by does nto nessiarly mean "was create/commited by a human" | 23:12 |
| sean-k-mooney | based on our exisign usage | 23:12 |
| sean-k-mooney | clarkb: llm dont apply terms to ther output in general | 23:13 |
| sean-k-mooney | it the service provider tha tprovies the infernce that does that in the claude code case for example | 23:13 |
| clarkb | I guess its LLM services that primarily do | 23:13 |
| sean-k-mooney | yep | 23:13 |
| gmaan | existing bots are possibly to work in agentic model especially on releases, requirements updates of all different stages | 23:13 |
| gmaan | anyways interesting conversation but need to go pick my son | 23:14 |
| clarkb | sean-k-mooney: looks like self hosted llms also impose license terms | 23:15 |
| clarkb | sean-k-mooney: some being non commercial use only for example | 23:15 |
| clarkb | and others have licenses like apache2 (qwen coder 3 appears to use apache 2) | 23:18 |
| clarkb | fwiw I did some digging and I don't think we can make DCO optional for some users in gerrit. The rules apply during the "receive" action when code is pushed to Gerrit and aren't ref specific and don't take group configuration | 23:26 |
| clarkb | it is basically a requirement or it isn't a requirement | 23:26 |
| clarkb | https://gerrit-review.googlesource.com/Documentation/access-control.html#service_users Gerrit does have the idea of service (aka bot) users but they don't document any special handling for systems like dco or cla enforcement | 23:28 |
| clarkb | and when I looked into gerrit's checking of the signed off by lines to undersatnd how they work in the web ui etc I remember the code being super ancient and not being super complicated either. So ya I don't think this possible if it isn't documented | 23:29 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!