ltning
trashHeap 
@ltning YEAH, im dissapointed and raged about it for a few days. KINDA a big reversal from what was telegraphed at last BSDCan.
dch 
@trashheap I keep saying this “we haven’t made a decision on this yet” quote me please. But we are working towards this! @ltning
@grahamperrin @dch @ltning I am not trying to "fan flames" so to speak, but perhaps I did overstate.
It HOWEVER does seems accurate to say things have drifted quite a bit from what was discussed at the last BSD Core Team update https://youtu.be/tUmeRqzczhA?si=5X5F8y-3wx28__9W
https://github.com/freebsd/freebsd-src/commit/6495dafd58b94a44fc9bc966ef47d6bc6916f5b9
AND I do feel like I should be allowed to express my disappointment at such events, while not being accused of causing an unnecessary panic.
LLM code IS being accepted today.
Core Team Update June 2025 FreeBSD Developer Summit
@grahamperrin @dch @ltning I have been telling folks here in mastodon and in real life, for months about #FreeBSD's draft policy against LLM code contribution. I resumed using FreeBSD after having spent years away, due in large part to positive indicators like that.
AND in the past couple days multiple FreeBSD committers have alternatively told me "no decision has been made" or discussed at length in replies of how soon LLM in code reviews by some members will be done, and describing generative AI in floss as an arms race that FreeBSD cannot afford to loose out in.
FreeBSD has already made one popular list of FLOSS software accepting LLM code. (Rightly or wrongly).
I am frustrated that there is no clear communication on this point to the "people in the pews" who are concerned about this; and a little tired of feeling like people are telling me I am wrong for expressing my disappointment, in the midst of this chaos.
Users are trying to figure out how to keep their software stack slop free today.
Graham Perrin@trashheap I see no chaos.
@grahamperrin Chaos being short for:
A lack of clear public messaging, and different freebsd committers seemingly telegraphing very different realities on the ground.
that's not chaotic.
Agree to disagree. It certainly feels that way with all the folks replying to me lately.
AND again thanks for telling me how to feel about this.
Jay 🚩 
@trashheap @grahamperrin I don't know about #FreeBSD but #NetBSD has policy of not accepting AI/LLM generated code
TomAoki@jaypatelani @trashheap @grahamperrin
Out of curiosity, does NetBSD project reject to import codes from (already existed and imported from before any AI appears) upstream project if any of the codes happen to include AI-generated codes, even if it's 1 line of diff?
If so, is it just the very commit by AI only? Or dispose the whole contributed code of the upstream project and look for alternative (or re-implement by themselves)?
Rejecting slip-in AI codes from upstream project means whichever of above.
I think this kind of policies (reject AI codes or not, for example) should be applied to any codes that the project itself (here, NetBSD or FreeBSD on original post) is the "upstream".
IMHO, rejecting per-commit from upstream is nonsense for not-so-huge projects like *BSD. Letting upstream decide and take responsibility, then, decide whether keep on using the project as upstream or not would be realistic.
And in case OpenZFS, it's toooooooooooo huge, complexed and important to reject it. Don't blame FreeBSD. Ask OpenZFS project for NOT to accept AI codes.
@TomAoki thanks, one additional point: I would not ask OpenZFS to reject the type of code that it already accepts.
To avoid any possible confusion: I mean <https://github.com/openzfs/zfs/commit/6495dafd58b94a44fc9bc966ef47d6bc6916f5b9> as the supposedly offensive example.
I see nothing sloppy or offensive.
The two reviewers and the signatory are eminently well-qualified.
Cc @jaypatelani
@grahamperrin @jaypatelani
Thanks!
The commit message looks well-documented.
Putting already-noted copyright risks / hazards aside, I think why AI-slops are called AI-slops would be because the codes by AI are often too hard to read / understand what it is doing and making code review (especially on upstream that received [don't mean accepted here] the PR) hard, or worse, impossible both on quality and quantity. This is one of the reason why reviewing by natural human submitter before submitting PR is important and mandatory.
And more, good (important here!) "natural human" submitter has good habit to look for any other related PRs are already exist and submit only when there's none and if any, leave comment on existing PRs, but how many AI submitters do so? Submissions SHALL not be automated at least for now.
Cannot tell about details, I've requested to review a short internal document (not a code, though) written using AI.
Parts related with common, widely used things looks mostly fine, but parts related with uncommon, product-specific things had a plenty of mistakes, mis-understandings, thus, unusable.
I've pushed it back with a plenty of fixes (half rewritten) and comments for product-specific parts and a little fixes and additional notes for common parts for the short document.
This would be like something reviewers at upstreams are forced now and why they don't want AI slops. Too heavy-loaded for reviewers.