Re: Claude AI code audit of GNUstep core stack — 150 fixes, 12 perf optimizations, all available f or upstream
"[email protected]" via "Developers list for GNUstep, the GNU groupware evironment" <[email protected]> Sat, 18 Jul 2026 10:59:46 +0200
| Newsgroups | gmane.comp.lib.gnustep.devel |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_8423BD79-69DC-422C-A5DD-F8037E6A1E42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Greg, just one question in this regard: Do we have a voice in GNU=E2=80=99s = discussion on that topic (I hope, there is a discussion an not just a = decision by one person, namely RMS)? If so, I hope, we make our = standpoint clear and don=E2=80=99t go onto a witch-hunt against AI = (which would be like a witch hunt against compilers and linkers in the = times when UNIX was still written in assembler). In my opinion AI is = just a (very sophisticated) tool which you need to know, how to use it = and its limitations. Then we can use it sanely and to our advantage. Hoping for the best outcome, Lars > Am 18.07.2026 um 10:23 schrieb Gregory Casamento = <[email protected]>: >=20 > David, >=20 > Sorry for the late reply; work has been very demanding lately. Of = course, any policy they issue will apply to us. I think this is a = reasonable approach for EMACS if they are waiting for guidance from the = GNU Project. >=20 > Until that policy is published, however, I don't think it gives us any = basis for changing GNUstep's existing approach. Once the GNU Project has = issued its guidance, we can evaluate it on its merits, determine whether = and how it applies to GNUstep, and discuss whether any changes are = warranted. >=20 > I believe our current policy provides a practical balance as it = focuses on licensing, provenance, code quality, review, and = maintainability rather than the specific tools contributors use. >=20 > As mentioned in previous emails, I have set a clear line on what is = acceptable, and this was reflected in the discussion a few weeks ago. >=20 > Yours, GC >=20 >=20 > On Wed, Jul 15, 2026 at 4:31=E2=80=AFAM David Chisnall = <[email protected] <mailto:[email protected]>> wrote: >> On 14 Jul 2026, at 22:48, Gregory Casamento <[email protected] = <mailto:[email protected]>> wrote: >> >=20 >> > Based on the discussion, I do not see sufficient consensus or = justification to replace our existing AI policy with a "No-AI" policy = for the GNUstep core libraries. Accordingly, the existing policy will = remain in effect. >>=20 >> Most of the arguments have been covered in other places and it=E2=80=99= s quite surprising that most of the folks in this thread seem unfamiliar = with them, but I would add one thing: >>=20 >> This week, EMACS paused =E2=80=98AI=E2=80=99 contributions because = the GNU project is expected to provide an explicit policy soon. I = presume that policy will apply to GNUstep as well. >>=20 >> David >>=20 >=20 >=20 >=20 > -- > Gregory Casamento > GNUstep Lead Developer / Black Lotus, Principal Consultant > http://www.gnustep.org <http://www.gnustep.org/> - = http://heronsperch.blogspot.com <http://heronsperch.blogspot.com/> > https://www.openhub.net/languages/objective_c --Apple-Mail=_8423BD79-69DC-422C-A5DD-F8037E6A1E42 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" = content=3D"text/html; charset=3Dutf-8"></head><body = style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; = line-break: after-white-space;">Hi Greg,<div><br></div><div>just one = question in this regard: Do we have a voice in GNU=E2=80=99s discussion = on that topic (I hope, there is a discussion an not just a decision by = one person, namely RMS)? If so, I hope, we make our standpoint clear and = don=E2=80=99t go onto a witch-hunt against AI (which would be like a = witch hunt against compilers and linkers in the times when UNIX was = still written in assembler). In my opinion AI is just a (very = sophisticated) tool which you need to know, how to use it and its = limitations. Then we can use it sanely and to our = advantage.</div><div><br></div><div>Hoping for the best = outcome,</div><div><br></div><div><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span>Lars<br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>Am 18.07.2026 um 10:23 schrieb Gregory Casamento = <[email protected]>:</div><br = class=3D"Apple-interchange-newline"><div><div dir=3D"ltr"><div = class=3D"gmail_default" style=3D"font-family:monospace,monospace"><p = class=3D"gmail-isSelectedEnd">David,</p><p = class=3D"gmail-isSelectedEnd">Sorry for the late reply; work has been = very demanding lately. Of course, any policy they issue will apply = to us. I think this is a reasonable approach for EMACS if they are = waiting for guidance from the GNU Project.</p><p = class=3D"gmail-isSelectedEnd">Until that policy is published, however, I = don't think it gives us any basis for changing GNUstep's existing = approach. Once the GNU Project has issued its guidance, we can evaluate = it on its merits, determine whether and how it applies to GNUstep, and = discuss whether any changes are warranted.</p><p = class=3D"gmail-isSelectedEnd">I believe our current policy provides a = practical balance as it focuses on licensing, provenance, code quality, = review, and maintainability rather than the specific tools contributors = use.</p><p class=3D"gmail-isSelectedEnd">As mentioned in previous = emails, I have set a clear line on what is acceptable, and this was = reflected in the discussion a few weeks ago.</p><p>Yours, = GC</p></div></div><br><div class=3D"gmail_quote = gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul = 15, 2026 at 4:31=E2=80=AFAM David Chisnall <<a = href=3D"mailto:[email protected]">[email protected]</a>>= ; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px = 0px 0px 0.8ex;border-left:1px solid = rgb(204,204,204);padding-left:1ex">On 14 Jul 2026, at 22:48, Gregory = Casamento <<a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>> wrote:<br> > <br> > Based on the discussion, I do not see sufficient consensus or = justification to replace our existing AI policy with a "No-AI" policy = for the GNUstep core libraries. Accordingly, the existing policy will = remain in effect.<br> <br> Most of the arguments have been covered in other places and it=E2=80=99s = quite surprising that most of the folks in this thread seem unfamiliar = with them, but I would add one thing:<br> <br> This week, EMACS paused =E2=80=98AI=E2=80=99 contributions because the = GNU project is expected to provide an explicit policy soon. I presume = that policy will apply to GNUstep as well.<br> <br> David<br> <br> </blockquote></div><div><br clear=3D"all"></div><div><br></div><span = class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" = class=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div><div = dir=3D"ltr"><font face=3D"monospace">Gregory Casamento<br>GNUstep Lead = Developer / Black Lotus, Principal Consultant<br><a = href=3D"http://www.gnustep.org/" = target=3D"_blank">http://www.gnustep.org</a> - <a = href=3D"http://heronsperch.blogspot.com/" = target=3D"_blank">http://heronsperch.blogspot.com</a><br></font></div></di= v><div dir=3D"ltr"><font color=3D"#888888" face=3D"monospace"><a = href=3D"https://www.openhub.net/languages/objective_c" = style=3D"color:rgb(17,85,204)" = target=3D"_blank">https://www.openhub.net/languages/objective_c</a></font>= </div></div></div></div> </div></blockquote></div><br></div></body></html>= --Apple-Mail=_8423BD79-69DC-422C-A5DD-F8037E6A1E42--