Re: RFC111 AI/LLM tool policy: proposal for a significant revision
Daniel Baston via gdal-dev <[email protected]> Wed, 13 May 2026 11:33:37 -0400
| Newsgroups | gmane.comp.gis.gdal.devel |
|---|---|
| Message-ID | <CA+K_q_oMeT9=Hn0QTyTLJeay-65C85ztFabKxTwqBnpZ9coBFQ@mail.gmail.com> |
--===============8512760852676541400== Content-Type: multipart/alternative; boundary="000000000000d03e790651b4b464" --000000000000d03e790651b4b464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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=E2=80=AFAM Darafei "Kom=D1=8Fpa" Praliaskousk= i 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 PostGI= S > 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 actu= al > 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 giv= e > 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, chec= k, > 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 t= o > 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 an= d > 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 a= nd > 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 additi= on > to testing. After there are like five of them approving without complaint= s, > 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 mo= re > okay with looking at AI code if it improves the FOSSGIS situation (hi!). > > Thanks, > Darafei. > > > > On Wed, May 13, 2026 at 2:19=E2=80=AFPM 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 =C3=A0 13:34, Even Rouault via gdal-dev a =C3=A9crit : >> > Any further comments before submitting to vote? >> > >> > Le 06/05/2026 =C3=A0 18:29, Even Rouault via gdal-dev a =C3=A9crit : >> >> 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 > --000000000000d03e790651b4b464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div></div><div>>=C2=A0Just allow to put any PR into th= is mode, maybe via a tag or comment, and don't look at it until there are some reveiws and their results are=20 fixed.</div><div><br></div><div>Who will perform these reviews? When I=20 review a pull request (not as often as I should), I am trying to=20 accomplish two things: (a) make sure that the code is of good quality=20 and does something useful, so that the project is improved by its=20 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).</div><div><br></div><div>Dan</div></div><br><div class=3D"gmail_quote= gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 1= 3, 2026 at 10:31=E2=80=AFAM Darafei "Kom=D1=8Fpa" Praliaskouski v= ia gdal-dev <<a href=3D"mailto:[email protected]">gdal-dev@lists.= osgeo.org</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"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"l= tr">Hi,<br><br>Would love to share my perspective of someone who vibe codes= . This email is fully organic produced.<br>I feel like this second change i= s over-reaction, and the actual issue can be re-traced and fixed under exis= ting policy.<br><br>I have not brought AI/LLM pull requests to GDAL yet, bu= t 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 softwa= re, but lacked applied skill to fix them across the=C2=A0diverse stack. In = the case of PostGIS I was so annoyed that I had to learn C to fix stuff, an= d ended up on PSC, because many people were annoyed,=C2=A0but not many had = the luxury to learn C. I wish I never had to learn C.<div><br></div><div>No= w, 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 simula= tor to validate my new assumptions on how to improve stability and get one = negative and one positive result, configured redundant multi-isp network, f= ix all open tickets in h3-pg, and convert an android projector with calibra= tion camera into a cat toy that plays with the actual cat.<br><div><br>Prev= iously this volume of changes would take years, and probably my cat will ge= t unattended in the list. All this improved my quality of life too.</div><d= iv><br></div><div>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 sol= ved this for humans there will come some better solutions and traditions in= the future.<br><br>LLMs are also very steerable nowadays. Dropping AGENTS.= md into project root and asking to test it [in which conditions] and to wri= te in existing / desired style when coming PRs are doing same mistakes over= is really changing what they do. Like, "read AI contributing policy i= n there: ..." so LLMs know what to aim for.<br><br>I went so far as cr= eated a service that profiles hangs and crashes in the background and tries= to stitch together an upstream patch:=C2=A0<a href=3D"https://fixer.maumap= .com/" target=3D"_blank">https://fixer.maumap.com/</a><br><br>While walking= this path, I met a different attitude from maintainers:<br>=C2=A0- The tru= e "patches welcome": people give actionable feedback and merge st= uff. When they're overloaded, they just reply that they are and pick up= later, when they're free.<br>=C2=A0- "Fuck AI" - I had softw= are crashed on my computer, got stacktraces, produced a patch, and got some= "it can never happen, fuck your AI hallucination". Often it is r= ather bystanders than actual maintainers. After some discussion it usually = got merged.<br>=C2=A0- "We know better" - a fun thing from OpenAI= itself. They don't accept vibe coded patches (actually any patches) be= cause their position is "we vibe code better and also can fix closed s= ource servers instead, just give us prompts as tickets".</div><div>=C2= =A0- "Peer review first" - especially popular in LLM-related proj= ects. 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. Mainta= iners just ignore PRs until they're comfortable with what's in them= .<br>=C2=A0- "We're not in git[hub] and don't accept PRs there= " - annoying one. Sending patches over email seems very archaic,=C2=A0= 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=C2=A0where and how to register and then get replies in so= me weird way.<br>=C2=A0-Dead projects, that don't have anyone behind th= em anymore. I don't know how to handle that properly without saying &qu= ot;here's my fork, it at least works here too.<br><br>I would love gdal= to be a projct where I can still use AI/LLM to fix the issues that annoy m= e in the same way I do elsewhere. How about reworking this policy change fr= om "no AI" to "need to solve maintainer capacity problem&quo= t;. I think the "Peer review first" policy from the above may act= ually 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 a= re 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 li= kely will be ok to spend some tokens for the automated review in addition t= o testing. After there are like five of them approving without complaints, = maybe it's time to merge.<br><br>It may also be a good idea to issue so= mething 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 t= he FOSSGIS situation (hi!).<br><br>Thanks,<br>Darafei.<br><br><br></div></d= iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att= r">On Wed, May 13, 2026 at 2:19=E2=80=AFPM Even Rouault via gdal-dev <<a= href=3D"mailto:[email protected]" target=3D"_blank">gdal-dev@lists.= osgeo.org</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">Howard submitted a substantial update / counter-proposal to my i= nitial <br> one. I've taking it, but with amendments re-introducing points of my <b= r> initial version. Please check<br> <br> Le 12/05/2026 =C3=A0 13:34, Even Rouault via gdal-dev a =C3=A9crit=C2=A0:<b= r> > Any further comments before submitting to vote?<br> ><br> > Le 06/05/2026 =C3=A0 18:29, Even Rouault via gdal-dev a =C3=A9crit=C2= =A0:<br> >> Hi,<br> >><br> >> based on the experience gained from the initial policy, I propose = to <br> >> significantly revise it to drastically limit their use. See <br> >> <a href=3D"https://github.com/OSGeo/gdal/pull/14500" rel=3D"norefe= rrer" target=3D"_blank">https://github.com/OSGeo/gdal/pull/14500</a><br> >><br> >> Even<br> >><br> -- <br> <a href=3D"http://www.spatialys.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://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">gdal-dev@list= s.osgeo.org</a><br> <a href=3D"https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel=3D"norefe= rrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</= a><br> </blockquote></div> </div> </div> </div> _______________________________________________<br> gdal-dev mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">gdal-dev@list= s.osgeo.org</a><br> <a href=3D"https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel=3D"norefe= rrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</= a><br> </blockquote></div> --000000000000d03e790651b4b464-- --===============8512760852676541400== 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 --===============8512760852676541400==--