Re: RFC111 AI/LLM tool policy: proposal for a significant revision

Chris Toney via gdal-dev <[email protected]> Wed, 13 May 2026 10:45:02 -0600
Newsgroups gmane.comp.gis.gdal.devel
Message-ID <CALRbqORxSOTY=GTMtcHA0JDp08pJe4oDUoFFp7BF2oQXQNq3iA@mail.gmail.com>
--===============8692655633338241522==
Content-Type: multipart/alternative; boundary="0000000000001ff5ed0651b5b417"

--0000000000001ff5ed0651b5b417
Content-Type: text/plain; charset="UTF-8"

I'm positive on the latest revisions (non-voting opinion). The "Rationale"
text added by Howard addresses a lot of what's being discussed here.

Chris

On Wed, May 13, 2026, 9:47 AM Even Rouault via gdal-dev <
[email protected]> wrote:

> >
> > I would love gdal to be a projct where I can still use AI/LLM to fix
> > the issues that annoy me in the same way I do elsewhere. How about
> > reworking this policy change from "no AI" to "need to solve maintainer
> > capacity problem". I think the "Peer review first" policy from the
> > above may actually adjust it better. Just allow to put any PR into
> > this mode, maybe via a tag or comment, and don't look at it until
> > there are some reveiws and their results are fixed. People who have
> > coded something for the project are likely using it, can test, it
> > should not be annoying for them as it's not them doing the local build
> > nowadays, just their llm, and they also likely will be ok to spend
> > some tokens for the automated review in addition to testing. After
> > there are like five of them approving without complaints, maybe it's
> > time to merge.
> You over-estimate the size of the GDAL reviewing community. Unless I
> miss something, I'm aware of:
> -  3 main "vocal"  (in the sense they write comments, or explicitly
> approve a PR) reviewers in the developer category: myself, Dan and
> Alessandro
> - Jukka with his "power user" hat commenting on functionality,
> documentation, etc.
> - Paul Harwood on C# issues
> - and to a lesser extent a few other people (Michael Sumner, Chris
> Toney, ...) who might occasionally comment on particular topics of interest
> (sorry if I missed someone. definitely not intentional!)
>
> There has  *never* been >= 5 people approving a PR. When we get at least
> one explicit approval, that's already an achievement. I regularly have
> to self-approve my own most ancient PRs when the queue of
> pending ones grows too much.
>
> >
> > It may also be a good idea to issue something like call for maintainers.
>
> Can that actually work ? Anyone is certainly welcome to review in their
> own capacity, but maintainers don't grow spontaneously. On a software
> large like GDAL, it is a many years process (took me 5-7 years to feel
> comfortable claiming that role). And you only go into that position by
> also making changes (bug fixes, enhancements, refactoring), and doing it
> the hard way so that you actually *learn* something in the process about
> the code base, its written and unwritten oddities and habits. Learning
> requires effort. I don't buy a single second that anyone can become a
> (competent) maintainer by only contributing vibe coded pull requests.
> Unless you're OK with your code base becoming progressively a LLM-only
> territory.
>
> That LLM are super convenient for creating likely/plausible code is a
> fact. That this is a good thing for the long term viability of both the
> code base and the community is much more arguable.
>
> Even
>
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> gdal-dev mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

--0000000000001ff5ed0651b5b417
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I&#39;m positive on the latest revisions (non-voting opin=
ion).=C2=A0The &quot;Rationale&quot; text added by Howard addresses a lot o=
f what&#39;s being discussed here.<div dir=3D"auto"><br></div><div dir=3D"a=
uto">Chris=C2=A0</div></div><br><div class=3D"gmail_quote gmail_quote_conta=
iner"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 13, 2026, 9:47 AM E=
ven Rouault via gdal-dev &lt;<a href=3D"mailto:[email protected]">gd=
[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">&gt;<br>
&gt; I would love gdal to be a projct where I can still use AI/LLM to fix <=
br>
&gt; the issues that annoy me in the same way I do elsewhere. How about <br=
>
&gt; reworking this policy change from &quot;no AI&quot; to &quot;need to s=
olve maintainer <br>
&gt; capacity problem&quot;. I think the &quot;Peer review first&quot; poli=
cy from the <br>
&gt; above may actually adjust it better. Just allow to put any PR into <br=
>
&gt; this mode, maybe via a tag or comment, and don&#39;t look at it until =
<br>
&gt; there are some reveiws and their results are fixed. People who have <b=
r>
&gt; coded something for the project are likely using it, can test, it <br>
&gt; should not be annoying for them as it&#39;s not them doing the local b=
uild <br>
&gt; nowadays, just their llm, and they also likely will be ok to spend <br=
>
&gt; some tokens for the automated review in addition to testing. After <br=
>
&gt; there are like five of them approving without complaints, maybe it&#39=
;s <br>
&gt; time to merge.<br>
You over-estimate the size of the GDAL reviewing community. Unless I <br>
miss something, I&#39;m aware of:<br>
-=C2=A0 3 main &quot;vocal&quot;=C2=A0 (in the sense they write comments, o=
r explicitly <br>
approve a PR) reviewers in the developer category: myself, Dan and <br>
Alessandro<br>
- Jukka with his &quot;power user&quot; hat commenting on functionality, <b=
r>
documentation, etc.<br>
- Paul Harwood on C# issues<br>
- and to a lesser extent a few other people (Michael Sumner, Chris <br>
Toney, ...) who might occasionally comment on particular topics of interest=
<br>
(sorry if I missed someone. definitely not intentional!)<br>
<br>
There has=C2=A0 *never*=C2=A0been &gt;=3D 5 people approving a PR. When we =
get at least <br>
one explicit approval, that&#39;s already an achievement. I regularly have =
<br>
to=C2=A0self-approve my own most ancient PRs when the queue=C2=A0of <br>
pending=C2=A0ones=C2=A0grows too much.<br>
<br>
&gt;<br>
&gt; It may also be a good idea to issue something like call for maintainer=
s.<br>
<br>
Can that actually work ? Anyone is certainly welcome to=C2=A0review in thei=
r <br>
own capacity, but maintainers don&#39;t grow spontaneously. On a software <=
br>
large like GDAL, it is a many years process (took me 5-7 years to feel <br>
comfortable claiming that role). And you only go into that position by <br>
also making changes (bug fixes, enhancements, refactoring), and doing it <b=
r>
the hard way so that you actually *learn* something in the process about <b=
r>
the code base, its written and unwritten=C2=A0oddities and habits. Learning=
 <br>
requires effort. I don&#39;t buy a single second=C2=A0that anyone can becom=
e a <br>
(competent) maintainer by=C2=A0only contributing=C2=A0vibe coded pull reque=
sts. <br>
Unless you&#39;re OK with your code base becoming progressively=C2=A0a LLM-=
only <br>
territory.<br>
<br>
That LLM are super convenient for creating=C2=A0likely/plausible code is a =
<br>
fact. That this is a good thing for the long term viability=C2=A0of both th=
e <br>
code base and the community is much more arguable.<br>
<br>
Even<br>
<br>
<br>
-- <br>
<a href=3D"http://www.spatialys.com" rel=3D"noreferrer noreferrer" target=
=3D"_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank" rel=3D"norefe=
rrer">[email protected]</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo=
/gdal-dev</a><br>
</blockquote></div>

--0000000000001ff5ed0651b5b417--

--===============8692655633338241522==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

--===============8692655633338241522==--