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
