[gdal-dev] RFC111 AI/LLM tool policy: proposal for a significant revision

[Even Rouault]

>
> 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.