Post by @ell1e@hachyderm.io
@drew i wonder, has anybody ever asked #NetBSD to reconsider the "core can approve slop" clause, or to publish some info on whether core has approved #slop so far?
sounds quite cool though! I'm still hoping somebody might fork an older #Linux #kernel - might be hard to keep that going but it would send a sign.
#LLM #NoSlop #ensloppification #AI #NoAI #FreeSoftware #FOSS #FLOSS #OpenSource
@ell1e @drew They have not done so since the policy was clarified in 2024.
Anyway, it needs clarifying again, since there's some third-party code we're not necessarily ready to remove, upstream has accepted AI contributions, it needs updates, and the decision between shipping slop and shipping vulnerable code to users is a huge catch-22.
@netbsd @drew ah, I see, yes for third-party projects I understand.
But in that case, it would be nice to have some sort of table to understand what is slop free. I think more transparency would make people way more at ease if the guideline needs to be occasionally broken.
(My apologies if this already exist, perhaps it should be linked then on this page: https://www.netbsd.org/developers/commit-guidelines.html after the paragraph talking about LLMs.)
@netbsd @drew after researching NetBSD some more, I think another pain point here might be moving over drivers from FreeBSD, like e.g. here: https://blog.netbsd.org/tnf/entry/wifi_renewal_restarted Since FreeBSD has sadly gone down the slop route, it seems like...
(Basically would be interesting to know how this will be handled in the future!)