> 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.
Who will perform these reviews? When I review a pull request (not as often as I should), I am trying to accomplish two things: (a) make sure that the code is of good quality and does something useful, so that the project is improved by its inclusion, and (b) help train a newer contributor who may one day become a maintainer. Of these, (b) is by far the most important to me, but if I review a vibe-coded pull request I feel like I am at best accomplishing (a). Dan On Wed, May 13, 2026 at 10:31 AM Darafei "Komяpa" Praliaskouski via gdal-dev <[email protected]> wrote: > Hi, > > Would love to share my perspective of someone who vibe codes. This email > is fully organic produced. > I feel like this second change is over-reaction, and the actual issue can > be re-traced and fixed under existing policy. > > I have not brought AI/LLM pull requests to GDAL yet, but I have done that > in other projects, lately on a larger scale. It has been a huge help for > me: previously, I was annoyed at many issues in the software, but lacked > applied skill to fix them across the diverse stack. In the case of PostGIS > I was so annoyed that I had to learn C to fix stuff, and ended up on PSC, > because many people were annoyed, but not many had the luxury to learn C. I > wish I never had to learn C. > > Now, in the last couple weeks, I managed to fix build cache issues in > ESPHome, fix build issues in the wifi7 driver of my new card, fix a cpu > hotspot in htop, fix a metadata evacuation issue in bcachefs, update lora > mesh simulator to validate my new assumptions on how to improve stability > and get one negative and one positive result, configured redundant > multi-isp network, fix all open tickets in h3-pg, and convert an android > projector with calibration camera into a cat toy that plays with the actual > cat. > > Previously this volume of changes would take years, and probably my cat > will get unattended in the list. All this improved my quality of life too. > > Latest PostGIS day had a lot of examples of people using AI/LLM around > GIS. It's early years still so there aren't many road rules yet so people > still bump into each other, but I believe like git solved this for humans > there will come some better solutions and traditions in the future. > > LLMs are also very steerable nowadays. Dropping AGENTS.md into project > root and asking to test it [in which conditions] and to write in existing / > desired style when coming PRs are doing same mistakes over is really > changing what they do. Like, "read AI contributing policy in there: ..." so > LLMs know what to aim for. > > I went so far as created a service that profiles hangs and crashes in the > background and tries to stitch together an upstream patch: > https://fixer.maumap.com/ > > While walking this path, I met a different attitude from maintainers: > - The true "patches welcome": people give actionable feedback and merge > stuff. When they're overloaded, they just reply that they are and pick up > later, when they're free. > - "Fuck AI" - I had software crashed on my computer, got stacktraces, > produced a patch, and got some "it can never happen, fuck your AI > hallucination". Often it is rather bystanders than actual maintainers. > After some discussion it usually got merged. > - "We know better" - a fun thing from OpenAI itself. They don't accept > vibe coded patches (actually any patches) because their position is "we > vibe code better and also can fix closed source servers instead, just give > us prompts as tickets". > - "Peer review first" - especially popular in LLM-related projects. > Patches just hang in there. Some people (or their AIs) pick them up, check, > apply locally, run for a day or two, check if fix/feature is working and > post a "we like this, here's evidences:" on a PR. Maintainers just ignore > PRs until they're comfortable with what's in them. > - "We're not in git[hub] and don't accept PRs there" - annoying one. > Sending patches over email seems very archaic, expecially when you need to > first subscribe somewhere, can't reply to a thread that was there before > you joined, and so on. Sometimes there's a github mirror but PRs are > getting just straight rejected by bot, and you need to go serach where and > how to register and then get replies in some weird way. > -Dead projects, that don't have anyone behind them anymore. I don't know > how to handle that properly without saying "here's my fork, it at least > works here too. > > 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. > > It may also be a good idea to issue something like call for maintainers. > It is okay for Even to not want to look at AI code, it should not be > creating discomfort, and there are definitely people out there who are more > okay with looking at AI code if it improves the FOSSGIS situation (hi!). > > Thanks, > Darafei. > > > > On Wed, May 13, 2026 at 2:19 PM Even Rouault via gdal-dev < > [email protected]> wrote: > >> Howard submitted a substantial update / counter-proposal to my initial >> one. I've taking it, but with amendments re-introducing points of my >> initial version. Please check >> >> Le 12/05/2026 à 13:34, Even Rouault via gdal-dev a écrit : >> > Any further comments before submitting to vote? >> > >> > Le 06/05/2026 à 18:29, Even Rouault via gdal-dev a écrit : >> >> Hi, >> >> >> >> based on the experience gained from the initial policy, I propose to >> >> significantly revise it to drastically limit their use. See >> >> https://github.com/OSGeo/gdal/pull/14500 >> >> >> >> 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 >> > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
