| *** elodilles_pto is now known as elodilles | 05:53 | |
| *** bauzas0 is now known as bauzas | 09:45 | |
| tkajinam | This might be a dump question (honestly I'm not quite familiar with recent AI models to generate codes) but is there any reasonable way to confirm that code generated by a specific AI model is compatible with Apache 2.0 ? | 12:48 |
|---|---|---|
| tkajinam | I was reading the policy published at https://openinfra.org/legal/ai-policy . it declares the policy but idk how I can confirm a proposed change is compliant with that policy, especially for the licensing point | 12:50 |
| fungi | tkajinam: i think the llm has to be trained exclusively on license-compatible examples for that to be guaranteed | 13:03 |
| fungi | that might be more a question for the openinfra foundation board of directors though, since they're the ones who chose that policy | 13:03 |
| fungi | TheJulia: gmaan: spotz[m]: maybe some of you know some example implementations that fit the requirement? | 13:04 |
| tkajinam | fungi, I agree but I'm unsure how that can/should be confirmed during the review process. | 13:11 |
| tkajinam | my immediate question is whether I can approve a patch with "generated-by: calude sonnet 4" without any additional information, but I'm hoping that we get more detailed check lists for llm models as I expect people may try new models in short span | 13:11 |
| fungi | oh, as a reviewer? i don't think you can. basically the contributor signing off on the commit per the dco is asserting this to be true | 13:12 |
| TheJulia | That was largely around hoping to set a stage for someone to create such a model and for such models to be leveraged. Where LLM creators went is more towards general applicability and tools went more towards an assistive model as opposed to a "generate everything" use model. Ultimately the only way to know is to have insight into the training model or the model creator offering controls to be able to assert specific behavior | 13:12 |
| TheJulia | or preference. FWIW, we have an update to the policy which is in the progress of being voted upon which better maps to this reality. | 13:12 |
| fungi | tkajinam: probably the best you can do as a reviewer when seeing a generated-by trailer in a commit is to remind the contributor of the policy's requirements | 13:13 |
| TheJulia | Ultimately, all you can really do is engage the submitter and seek clarifying questions, but as with many things you have to take some of upon faith and the purpose of the tag is to also make it easy to identify the tool's use in the commit log *should* there ever be a need to remove such usage. | 13:14 |
| fungi | but i agree that we could stand to provide better guidance to reviewers on how to deal with these sorts of proposed changes, so far the guidance has focused primarily on people proposing changes that were created with the aid of an llm | 13:15 |
| fungi | and yes, that guidance is basically all on "the honor system" so we can really only trust that people proposing changes are being truthful (at least the fact that they declared it at all is helpful, they didn't try to hide it and pretend they wrote it completely on their own) | 13:16 |
| fungi | and this is really not that much different from trusting a contributor not to copy code from some other random open source project and stick it in a change asserting it's their work | 13:17 |
| TheJulia | fungi: exactly, its not a reviewers role to verify, but to extend trust if everything seems reasonable | 13:19 |
| fungi | tkajinam: if it helps, the current policy's "contributor checklist" section includes recommendations to provide further context in the commit message, code comments or review discussion. if the change doesn't indicate how the tool was involved in its creation, then as a reviewer i'd ask the author to clarify (and point them to the policy's recommendations about that so they | 13:21 |
| fungi | remember to do so in the future) | 13:21 |
| fungi | looks like that's precisely what the first bullet in the reviewer checklist section suggests to do as well | 13:22 |
| fungi | the example commit message below there does a pretty good job of demonstrating that too | 13:24 |
| TheJulia | FWIW, there is a strong possibility that the label really should be assisted-by, and not generated-by once the new policy is approved. claude is much more about thoughts, fragments/ideas which leans itself towards assistive as your helping shape it overall. You can also do things like suggest it to reference and use existing context in repositories you indicate. | 13:28 |
| TheJulia | (of course, it all depends on *how* one uses it, which is why we sought for folks to be more clear in their commit messages) | 13:32 |
| tkajinam | fungi, https://review.opendev.org/c/openstack/heat/+/955286 is where this question started | 14:09 |
| fungi | TheJulia: unless you ask claude to manage your production product rollout... https://xcancel.com/jasonlk/status/1946069562723897802 ;) | 14:11 |
| TheJulia | lol | 14:11 |
| spotz[m] | Thanks for posting that tkajinam my guess is Julia is correct and if the assisted-by was in place that would the appropriate tag used | 14:11 |
| tkajinam | fungi TheJulia, thx. I think I have more clear idea about the base concept behind the policy and it makes more sense to me know | 14:12 |
| tkajinam | s/know/now/ | 14:13 |
| tkajinam | fungi, yeah I totally agree with this > this is really not that much different from trusting a contributor not to copy code from some other random open source project ... | 14:14 |
| tkajinam | I'd probably leave that change until the new policy is approved and we get more detailed guidance (hopefully). | 14:16 |
| opendevreview | Merged openstack/service-types-authority master: Apply ruff https://review.opendev.org/c/openstack/service-types-authority/+/953562 | 17:07 |
| opendevreview | Merged openstack/service-types-authority master: Post-ruff follow-ups https://review.opendev.org/c/openstack/service-types-authority/+/955175 | 17:14 |
| opendevreview | Wesley Hershberger proposed openstack/contributor-guide master: Add stable backports process to "Using Gerrit" https://review.opendev.org/c/openstack/contributor-guide/+/955525 | 20:25 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!