From julien.cabieces at oslandia.com Wed Apr 1 00:34:56 2026 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Wed, 01 Apr 2026 09:34:56 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> (Vincent Picavet via's message of "Wed, 1 Apr 2026 07:38:23 +0200") References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: <87cy0jf80v.fsf@julienlaptop.home> Hi, Thank you Nyall for raising this topic. I don't have well established position on this and I don't think there is a good obvious solution here. I'm also deeply concerned about the increased number of AI Pull Requests, often of poor quality. I have also lost time trying to review some of these... But I don't like having different rules for core developers and non core developers. We would be allowed to use a (supposedly) powerful tool, but not new contributors ? I don't like the message that we send to the community. It doesn't seem very welcoming, and people could rightfully say that we are gate keeping. So, If we don't want people proposing AI Pull Requests, I'd prefer banning AI Pull Requests at all. Maybe we could allow the chatbot use but not the code generation? But that's maybe the position of someone who actually doesn't use code generation... In any case, I'd like we stay welcoming and rename the "AI slop" label and its tooltip to something more neutral ("AI generated", "This PR contains AI generated code and needs to be thoroughly reviewed" ? ). Especially when the contributor has explicitly written that he used AI and how he used it. Regards, Julien > Hi, > > I second all the wise words from Even. I am particularly worried by > the impact it would have on growing our contributor base. QGIS already > has a problem with welcoming new contributors, and a policy giving > more special rights to core contributors will only make the situation > worse. Especially while the rules for core contributors are not really > well defined. A retired core contributor could launch an agent to > throw slop PRs at QGIS while a recurrent non-core contributor would > not even be allowed to review his own code with an LLM ? > > I also note that the current situation is bad for our community > atmosphere : the "AI slop" label seems really offensive for newcomers > if not sustained with explanation and clear rules on expectations. I > have recently seen contributors feeling bad after their work has been > marked as slop without any discussion and care. > > I have already casted my opinion recently, but let me restate it : I personally think we should ban any LLM-generated code entirely from QGIS codebase. > > Right now the legal risk is really high, and while there is still no > real legal law case which would indicate that we actually have the > right to include LLM-generated code as GPL into an OpenSource software > as QGIS, each week show new signs that this topic is risky ( supreme > court refusing to handle copyright issue, new laws coming for AI legal > control in France and Europe, the chardet debacle, new law cases and > settlements, wikipedia banning AI-aided contributions?). > > We should keep a look at Debian policy. For now they said it was too early for a position, but I guess as for all risks, when in doubt then no doubt. > > I would be in favor of having a - at least - temporary ban on AI-generated code for all. > > Vincent > > > On 01/04/2026 03:28, Even Rouault via QGIS-Developer wrote: >> Nyall, >> >> As often with that topic, I'm undecided about the best course of action. >> >> For the sake of the discussion, let me play a bit the devil advocate so we have counter points to consider: >> >> - restricting AI tool use to core contributors will make the process >> of becoming core contributor harder. Core contributors would be able >> to improve their capabilities further (questionable claim in terms >> of quality. But in quantity&speed, definitely), which will make it >> harder to grow new core contributors.?There's a high chance the new >> generation learning coding today will not be able to produce any >> working code without such tools (like I'm 100% dependent on Valgrind >> to write working non-trivial C++ code). >> >> - besides the issue with new comers to the project, we most >> certainly have regular experienced contributors who haven't the >> status of core contributor, probably because nobody thought about >> proposing them (btw, I've no idea how to determine who is a core >> contributor and who isn't...? is there a public list somewhere >> ?). Why would they be discriminated further? >> >> - I would say that we should restrict your proposal even further: >> "only core contributors are allowed to use AI tools, only in the >> areas where they (feel they) are experts? ", possibly relaxed with >> "or for contributions involving non-production code (e.g. CI scripts >> (*), etc.)". If I use a AI tool in a part of QGIS I've never >> touched, there's a high risk I will produce low quality code with >> it. >> >> - There's an increased risk that non-core contributors would still >> use AI tools, but without telling us. Naive ones will be easily >> caught; smarter?ones will go under?our detection radar. But is there >> a difference between good/non-perfect/bad code written with or >> without AI assistance that still passes CI and human review...??At >> the PR unitary level, I'd say none.?The issue is more the about the >> increased volume?of bad contributions with AI help that can saturate >> our review bandwidth. >> >> - Side point: I'm wondering if the nature of the tool would make a >> difference. I haven't personally used AI tools that can operate on a >> whole code base (Claude code and the like), only chat tools that can >> work/produce limited code fragments. I'd suspect the former are the >> ones where you can vibe code an entire feature, whereas with chatty >> ones, you need to iterate much more and thus have hopefully more >> critical eye. On the other hand, maybe tools that operate at the >> whole code base level can have a better global view... Likely none >> of those approaches is fundamentally better than the other >> one. Different drawbacks. >> >> To me it looks like we are caught in an arm race we haven't decided >> to be part of but can't easily escape.? So, half joking/half >> serious,?let's use AI tools to detect bad AI output ?!? (ignoring >> who has used the tool). I suspect that AI companies would love such >> outcome...? Or maybe, until the AI industry collapses entirely, >> let's temporarily go back to sending patches on 3.5 inches floppy >> disks (1.44 MB ones only, not extended 2.88 MB ones)? through (post) >> mail. >> >> At the same time I'm writing this, I'm caught in a situation where >> I'm questioning the need for a GDAL PR whose quality isn't >> necessarily bad (I haven't done the in-depth analysis), but which is >> likely not strictly needed (premature optimization/complication), >> and would have most certainly not be submitted at all if AI didn't >> exist. From my experience with recent AI assisted PRs to GDAL, >> that's actually the main problem. Too much code being written in a >> too short period of time, that will make us totally dependent on AI >> tools to be able to contribute further. >> >> So, all in all, not opposed to your proposal, but we need to be careful how we phrase it to not scare away non-core contributors or increase unwanted discrimination. >> >> Even >> >> (*) Because I've just played this afternoon with Gemini chat to come >> up with some python clang AST code to write custom code checkers to >> verify project specific code rules (like pairing Reference() in >> constructor and Release() in destructor). The result is >> .. well... AI typical. Mostly sort of works after a couple >> iterations, but definitely not something that would be of the >> quality that clang-tidy or similar serious tools would expect. But >> good enough for the purpose it was created. Or at least I was >> tricked into believing it was good enough... >> > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From denis.rouzaud at gmail.com Wed Apr 1 01:37:16 2026 From: denis.rouzaud at gmail.com (Denis Rouzaud) Date: Wed, 1 Apr 2026 10:37:16 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: <87cy0jf80v.fsf@julienlaptop.home> References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> <87cy0jf80v.fsf@julienlaptop.home> Message-ID: Hi everyone, I am personally a user of AI-generated code. I find it works exceptionally well for medium-sized libraries, especially in terms of quality of code produced and for writing tests, despite the quantity of code as observed by others. Regarding QGIS, I have mixed feelings. It works great for the migration of settings: since it's a repetitive task, I could fine-tune a precise prompt which works well while it still requires some attention to review everything. The challenge was really to give all the tiny details, which in the end translates to the capability of grasping (and writing) the whole complexity. For more complex and isolated tasks, while the explanations from it always sound super convincing, I agree that it's still quite often not relevant if not completely wrong in some parts of it. And it takes a lot of time to detect this because it's well hidden in the complexity. (But this statement would have been the same for small librairies a couple of months ago. So, where will we be in a couple of months?) >From my experience, I think the most important thing is to ensure these two points: - I have reviewed every single line of code. - I fully understand all the code produced. In my opinion, checking these two boxes is more important than knowing whether or not AI was used, which is not as black and white either (as already stated, there is a quite wide brand of usage from code completion to full automatic coding). Like cheating/doping in sports, it's a bit subjective. I also share the concerns of not introducing a differentiation between the type of authors to avoid frustration. So I'd be in favor of introducing the 2 checkboxes above and fine tuning the AI use checkbox (not sure exactly how, but to give a better vision on how it has been used). Kind regards, Denis Rouzaud Le mer. 1 avr. 2026 ? 09:35, Julien Cabieces via QGIS-Developer < qgis-developer at lists.osgeo.org> a ?crit : > > Hi, > > Thank you Nyall for raising this topic. I don't have well established > position on this and I don't think there is a good obvious solution > here. > > I'm also deeply concerned about the increased number of AI Pull Requests, > often of poor quality. I have also lost time trying to review some of > these... > > But I don't like having different rules for core developers and non core > developers. We would be allowed to use a (supposedly) powerful tool, but > not new contributors ? I don't like the message that we send to the > community. It doesn't seem very welcoming, and people could rightfully > say that we are gate keeping. > > So, If we don't want people proposing AI Pull Requests, I'd prefer > banning AI Pull Requests at all. Maybe we could allow the chatbot use but > not > the code generation? But that's maybe the position of someone who actually > doesn't use code generation... > > In any case, I'd like we stay welcoming and rename the "AI slop" label > and its tooltip to something more neutral ("AI generated", "This PR > contains AI generated code and needs to be thoroughly reviewed" ? ). > > Especially when the contributor has explicitly written that he used AI > and how he used it. > > Regards, > Julien > > > > > > > Hi, > > > > I second all the wise words from Even. I am particularly worried by > > the impact it would have on growing our contributor base. QGIS already > > has a problem with welcoming new contributors, and a policy giving > > more special rights to core contributors will only make the situation > > worse. Especially while the rules for core contributors are not really > > well defined. A retired core contributor could launch an agent to > > throw slop PRs at QGIS while a recurrent non-core contributor would > > not even be allowed to review his own code with an LLM ? > > > > I also note that the current situation is bad for our community > > atmosphere : the "AI slop" label seems really offensive for newcomers > > if not sustained with explanation and clear rules on expectations. I > > have recently seen contributors feeling bad after their work has been > > marked as slop without any discussion and care. > > > > I have already casted my opinion recently, but let me restate it : I > personally think we should ban any LLM-generated code entirely from QGIS > codebase. > > > > Right now the legal risk is really high, and while there is still no > > real legal law case which would indicate that we actually have the > > right to include LLM-generated code as GPL into an OpenSource software > > as QGIS, each week show new signs that this topic is risky ( supreme > > court refusing to handle copyright issue, new laws coming for AI legal > > control in France and Europe, the chardet debacle, new law cases and > > settlements, wikipedia banning AI-aided contributions?). > > > > We should keep a look at Debian policy. For now they said it was too > early for a position, but I guess as for all risks, when in doubt then no > doubt. > > > > I would be in favor of having a - at least - temporary ban on > AI-generated code for all. > > > > Vincent > > > > > > On 01/04/2026 03:28, Even Rouault via QGIS-Developer wrote: > >> Nyall, > >> > >> As often with that topic, I'm undecided about the best course of action. > >> > >> For the sake of the discussion, let me play a bit the devil advocate so > we have counter points to consider: > >> > >> - restricting AI tool use to core contributors will make the process > >> of becoming core contributor harder. Core contributors would be able > >> to improve their capabilities further (questionable claim in terms > >> of quality. But in quantity&speed, definitely), which will make it > >> harder to grow new core contributors. There's a high chance the new > >> generation learning coding today will not be able to produce any > >> working code without such tools (like I'm 100% dependent on Valgrind > >> to write working non-trivial C++ code). > >> > >> - besides the issue with new comers to the project, we most > >> certainly have regular experienced contributors who haven't the > >> status of core contributor, probably because nobody thought about > >> proposing them (btw, I've no idea how to determine who is a core > >> contributor and who isn't... is there a public list somewhere > >> ?). Why would they be discriminated further? > >> > >> - I would say that we should restrict your proposal even further: > >> "only core contributors are allowed to use AI tools, only in the > >> areas where they (feel they) are experts ", possibly relaxed with > >> "or for contributions involving non-production code (e.g. CI scripts > >> (*), etc.)". If I use a AI tool in a part of QGIS I've never > >> touched, there's a high risk I will produce low quality code with > >> it. > >> > >> - There's an increased risk that non-core contributors would still > >> use AI tools, but without telling us. Naive ones will be easily > >> caught; smarter ones will go under our detection radar. But is there > >> a difference between good/non-perfect/bad code written with or > >> without AI assistance that still passes CI and human review...? At > >> the PR unitary level, I'd say none. The issue is more the about the > >> increased volume of bad contributions with AI help that can saturate > >> our review bandwidth. > >> > >> - Side point: I'm wondering if the nature of the tool would make a > >> difference. I haven't personally used AI tools that can operate on a > >> whole code base (Claude code and the like), only chat tools that can > >> work/produce limited code fragments. I'd suspect the former are the > >> ones where you can vibe code an entire feature, whereas with chatty > >> ones, you need to iterate much more and thus have hopefully more > >> critical eye. On the other hand, maybe tools that operate at the > >> whole code base level can have a better global view... Likely none > >> of those approaches is fundamentally better than the other > >> one. Different drawbacks. > >> > >> To me it looks like we are caught in an arm race we haven't decided > >> to be part of but can't easily escape. So, half joking/half > >> serious, let's use AI tools to detect bad AI output ?!? (ignoring > >> who has used the tool). I suspect that AI companies would love such > >> outcome... Or maybe, until the AI industry collapses entirely, > >> let's temporarily go back to sending patches on 3.5 inches floppy > >> disks (1.44 MB ones only, not extended 2.88 MB ones) through (post) > >> mail. > >> > >> At the same time I'm writing this, I'm caught in a situation where > >> I'm questioning the need for a GDAL PR whose quality isn't > >> necessarily bad (I haven't done the in-depth analysis), but which is > >> likely not strictly needed (premature optimization/complication), > >> and would have most certainly not be submitted at all if AI didn't > >> exist. From my experience with recent AI assisted PRs to GDAL, > >> that's actually the main problem. Too much code being written in a > >> too short period of time, that will make us totally dependent on AI > >> tools to be able to contribute further. > >> > >> So, all in all, not opposed to your proposal, but we need to be careful > how we phrase it to not scare away non-core contributors or increase > unwanted discrimination. > >> > >> Even > >> > >> (*) Because I've just played this afternoon with Gemini chat to come > >> up with some python clang AST code to write custom code checkers to > >> verify project specific code rules (like pairing Reference() in > >> constructor and Release() in destructor). The result is > >> .. well... AI typical. Mostly sort of works after a couple > >> iterations, but definitely not something that would be of the > >> quality that clang-tidy or similar serious tools would expect. But > >> good enough for the purpose it was created. Or at least I was > >> tricked into believing it was good enough... > >> > > _______________________________________________ > > QGIS-Developer mailing list > > QGIS-Developer at lists.osgeo.org > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > -- > > Julien Cabieces > Senior Developer at Oslandia > julien.cabieces at oslandia.com > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apasotti at gmail.com Wed Apr 1 02:02:08 2026 From: apasotti at gmail.com (Alessandro Pasotti) Date: Wed, 1 Apr 2026 11:02:08 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> <87cy0jf80v.fsf@julienlaptop.home> Message-ID: Hi, I am currently using Copilot as an autocompleter/copy-paster on steroids, I find it useful to generate repetitive tasks (like handling the different cases of a switch statement) and for writing test cases but I've never tried to generate a full class or a full method. Knowing its limitations I think it speeds up my work but I have to carefully review every single line because sometimes it "hallucinates" badly. I don't feel that we have an IP issue for this kind of usage: the generated code it too trivial and too limited in the amount to be considered an infringement and also I noticed that 99% of the times it basically copy-pastes code from the other parts of QGIS or GDAL and many times it's code I've written myself. Regarding the policy in QGIS I also believe that the main goal is to reduce the SNR (signal-noise-ratio) in the PRs, given the limited time the reviewers have. I think a total ban is not enforceable and probably not useful at all, also I don't feel right that only core developers could use these tools. I second Denis' idea that the important thing is that the contributor checks that: - I have reviewed every single line of code. - I fully understand all the code produced. I would probably summarize that in the rule "do not submit anything that I could not have written myself without any AI tool", not sure how this could be enforced though but I think that if someone is caught cheating the current policy should cover the case. Cheers Alessandro Pasotti On Wed, Apr 1, 2026 at 10:37?AM Denis Rouzaud via QGIS-Developer wrote: > > Hi everyone, > > I am personally a user of AI-generated code. I find it works exceptionally well for medium-sized libraries, especially in terms of quality of code produced and for writing tests, despite the quantity of code as observed by others. > > Regarding QGIS, I have mixed feelings. It works great for the migration of settings: since it's a repetitive task, I could fine-tune a precise prompt which works well while it still requires some attention to review everything. The challenge was really to give all the tiny details, which in the end translates to the capability of grasping (and writing) the whole complexity. > For more complex and isolated tasks, while the explanations from it always sound super convincing, I agree that it's still quite often not relevant if not completely wrong in some parts of it. And it takes a lot of time to detect this because it's well hidden in the complexity. > > (But this statement would have been the same for small librairies a couple of months ago. So, where will we be in a couple of months?) > > From my experience, I think the most important thing is to ensure these two points: > - I have reviewed every single line of code. > - I fully understand all the code produced. > In my opinion, checking these two boxes is more important than knowing whether or not AI was used, which is not as black and white either (as already stated, there is a quite wide brand of usage from code completion to full automatic coding). Like cheating/doping in sports, it's a bit subjective. > > I also share the concerns of not introducing a differentiation between the type of authors to avoid frustration. > So I'd be in favor of introducing the 2 checkboxes above and fine tuning the AI use checkbox (not sure exactly how, but to give a better vision on how it has been used). > > Kind regards, > > Denis Rouzaud > > > Le mer. 1 avr. 2026 ? 09:35, Julien Cabieces via QGIS-Developer a ?crit : >> >> >> Hi, >> >> Thank you Nyall for raising this topic. I don't have well established >> position on this and I don't think there is a good obvious solution >> here. >> >> I'm also deeply concerned about the increased number of AI Pull Requests, >> often of poor quality. I have also lost time trying to review some of >> these... >> >> But I don't like having different rules for core developers and non core >> developers. We would be allowed to use a (supposedly) powerful tool, but >> not new contributors ? I don't like the message that we send to the >> community. It doesn't seem very welcoming, and people could rightfully >> say that we are gate keeping. >> >> So, If we don't want people proposing AI Pull Requests, I'd prefer >> banning AI Pull Requests at all. Maybe we could allow the chatbot use but not >> the code generation? But that's maybe the position of someone who actually >> doesn't use code generation... >> >> In any case, I'd like we stay welcoming and rename the "AI slop" label >> and its tooltip to something more neutral ("AI generated", "This PR >> contains AI generated code and needs to be thoroughly reviewed" ? ). >> >> Especially when the contributor has explicitly written that he used AI >> and how he used it. >> >> Regards, >> Julien >> >> >> >> >> >> > Hi, >> > >> > I second all the wise words from Even. I am particularly worried by >> > the impact it would have on growing our contributor base. QGIS already >> > has a problem with welcoming new contributors, and a policy giving >> > more special rights to core contributors will only make the situation >> > worse. Especially while the rules for core contributors are not really >> > well defined. A retired core contributor could launch an agent to >> > throw slop PRs at QGIS while a recurrent non-core contributor would >> > not even be allowed to review his own code with an LLM ? >> > >> > I also note that the current situation is bad for our community >> > atmosphere : the "AI slop" label seems really offensive for newcomers >> > if not sustained with explanation and clear rules on expectations. I >> > have recently seen contributors feeling bad after their work has been >> > marked as slop without any discussion and care. >> > >> > I have already casted my opinion recently, but let me restate it : I personally think we should ban any LLM-generated code entirely from QGIS codebase. >> > >> > Right now the legal risk is really high, and while there is still no >> > real legal law case which would indicate that we actually have the >> > right to include LLM-generated code as GPL into an OpenSource software >> > as QGIS, each week show new signs that this topic is risky ( supreme >> > court refusing to handle copyright issue, new laws coming for AI legal >> > control in France and Europe, the chardet debacle, new law cases and >> > settlements, wikipedia banning AI-aided contributions?). >> > >> > We should keep a look at Debian policy. For now they said it was too early for a position, but I guess as for all risks, when in doubt then no doubt. >> > >> > I would be in favor of having a - at least - temporary ban on AI-generated code for all. >> > >> > Vincent >> > >> > >> > On 01/04/2026 03:28, Even Rouault via QGIS-Developer wrote: >> >> Nyall, >> >> >> >> As often with that topic, I'm undecided about the best course of action. >> >> >> >> For the sake of the discussion, let me play a bit the devil advocate so we have counter points to consider: >> >> >> >> - restricting AI tool use to core contributors will make the process >> >> of becoming core contributor harder. Core contributors would be able >> >> to improve their capabilities further (questionable claim in terms >> >> of quality. But in quantity&speed, definitely), which will make it >> >> harder to grow new core contributors. There's a high chance the new >> >> generation learning coding today will not be able to produce any >> >> working code without such tools (like I'm 100% dependent on Valgrind >> >> to write working non-trivial C++ code). >> >> >> >> - besides the issue with new comers to the project, we most >> >> certainly have regular experienced contributors who haven't the >> >> status of core contributor, probably because nobody thought about >> >> proposing them (btw, I've no idea how to determine who is a core >> >> contributor and who isn't... is there a public list somewhere >> >> ?). Why would they be discriminated further? >> >> >> >> - I would say that we should restrict your proposal even further: >> >> "only core contributors are allowed to use AI tools, only in the >> >> areas where they (feel they) are experts ", possibly relaxed with >> >> "or for contributions involving non-production code (e.g. CI scripts >> >> (*), etc.)". If I use a AI tool in a part of QGIS I've never >> >> touched, there's a high risk I will produce low quality code with >> >> it. >> >> >> >> - There's an increased risk that non-core contributors would still >> >> use AI tools, but without telling us. Naive ones will be easily >> >> caught; smarter ones will go under our detection radar. But is there >> >> a difference between good/non-perfect/bad code written with or >> >> without AI assistance that still passes CI and human review...? At >> >> the PR unitary level, I'd say none. The issue is more the about the >> >> increased volume of bad contributions with AI help that can saturate >> >> our review bandwidth. >> >> >> >> - Side point: I'm wondering if the nature of the tool would make a >> >> difference. I haven't personally used AI tools that can operate on a >> >> whole code base (Claude code and the like), only chat tools that can >> >> work/produce limited code fragments. I'd suspect the former are the >> >> ones where you can vibe code an entire feature, whereas with chatty >> >> ones, you need to iterate much more and thus have hopefully more >> >> critical eye. On the other hand, maybe tools that operate at the >> >> whole code base level can have a better global view... Likely none >> >> of those approaches is fundamentally better than the other >> >> one. Different drawbacks. >> >> >> >> To me it looks like we are caught in an arm race we haven't decided >> >> to be part of but can't easily escape. So, half joking/half >> >> serious, let's use AI tools to detect bad AI output ?!? (ignoring >> >> who has used the tool). I suspect that AI companies would love such >> >> outcome... Or maybe, until the AI industry collapses entirely, >> >> let's temporarily go back to sending patches on 3.5 inches floppy >> >> disks (1.44 MB ones only, not extended 2.88 MB ones) through (post) >> >> mail. >> >> >> >> At the same time I'm writing this, I'm caught in a situation where >> >> I'm questioning the need for a GDAL PR whose quality isn't >> >> necessarily bad (I haven't done the in-depth analysis), but which is >> >> likely not strictly needed (premature optimization/complication), >> >> and would have most certainly not be submitted at all if AI didn't >> >> exist. From my experience with recent AI assisted PRs to GDAL, >> >> that's actually the main problem. Too much code being written in a >> >> too short period of time, that will make us totally dependent on AI >> >> tools to be able to contribute further. >> >> >> >> So, all in all, not opposed to your proposal, but we need to be careful how we phrase it to not scare away non-core contributors or increase unwanted discrimination. >> >> >> >> Even >> >> >> >> (*) Because I've just played this afternoon with Gemini chat to come >> >> up with some python clang AST code to write custom code checkers to >> >> verify project specific code rules (like pairing Reference() in >> >> constructor and Release() in destructor). The result is >> >> .. well... AI typical. Mostly sort of works after a couple >> >> iterations, but definitely not something that would be of the >> >> quality that clang-tidy or similar serious tools would expect. But >> >> good enough for the purpose it was created. Or at least I was >> >> tricked into believing it was good enough... >> >> >> > _______________________________________________ >> > QGIS-Developer mailing list >> > QGIS-Developer at lists.osgeo.org >> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> -- >> >> Julien Cabieces >> Senior Developer at Oslandia >> julien.cabieces at oslandia.com >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it From benoit.de.mezzo at oslandia.com Wed Apr 1 02:45:54 2026 From: benoit.de.mezzo at oslandia.com (Benoit D.-M.) Date: Wed, 1 Apr 2026 11:45:54 +0200 Subject: [QGIS-Developer] QEP 412: 3d editing support Message-ID: <87a5cf76-9cbd-4301-ac71-4bacf87cc6f5@oslandia.com> Hi everyone, Up for QEP 412 (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/367) ! I will call for a vote by the end of the week! Regards. From regis.haubourg at gmail.com Wed Apr 1 04:30:56 2026 From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=) Date: Wed, 1 Apr 2026 13:30:56 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> <87cy0jf80v.fsf@julienlaptop.home> Message-ID: <26cd8d77-6ced-4ae8-b8a7-038198b4a986@gmail.com> Hi all, I'm happy that this discussion arises in such a constructive way ## Regarding the "AI slop" Github label, I had a look at the marked PR and issues. We clearly have students and beginners launching 7 PR in a fex days. This is AI slop. But we also have some long time contributors like Marcu that use AI as a way to try to get into core contribution, with full disclosure and explicitly mentioning mentoring with core devs in local hackfest. I have hard time finding out who is behind a PR, sometimes from long time contributors and friends, so I would propose that we encourage contributors to use clear usernames To sum up this triaging topic, I'd be in favor of : - a neutral "AI generated"? label - a second "PR Slop !! " label reserved to tag bad behavior only - Incentives over the community to introduce itself and take care that reviewers can easily identify the PR/Issue author to a real person. The authors must understand we can't make an investigation on each discussion to identify contributors, and they may badly be tagged? as "Slop" involuntarily. ## On the AI use ban For reference, I found this repo starting to lists the projects that stated antiAI policies : https://github.com/thatshubham/no-ai? Libreoffice You probably saw Copilot inserting ads into PR's where asked for review last week. As always in open source, if we accept AI reviews, we probably should take care of preserving our independence and our capacity to move away from GH/Microsoft ecosystem that locks us in. So whatever we choose, let's keep in mind our independence and capacity to migrate somewhere else. You also saw the dramatic 90 % service continuity from Github. AI in highly complex environments is a danger.? This seconds the idea that we can't let vibe code do massive changes to the core, from core contributor or not. I would also add to our policy that no direct contribution to the repo is accepted from an AI agent. Which is inlined with the "human in the loop" policy. I wouldn't like to see Github copilot's or Claude avatar in the lists of the contributors. So I have no hard point of view here. But if I understand well current jurisprudence, we are fully responsible of IP infringement in our code base, whatever the tool we use. I would suggest we back our backs by setting up scanners in our CI and IDE to catch potential dependencies or source code infringements.?? SCANOSS pretends to be able to catch snippets level licence infringement at least. ?I know they are weak tools. But maybe they could be a proof of good will for the future to defend us? Lastly, Collabora? proposes an alternative way that could work. https://www.collaboraonline.com/blog/tdf-ejects-its-core-developers/ Let's get rid of humans. Happy 1st April all :) Cheers Bien cordialement, R?gis Haubourg On 01/04/2026 11:02, Alessandro Pasotti via QGIS-Developer wrote: > Hi, > > I am currently using Copilot as an autocompleter/copy-paster on > steroids, I find it useful to generate repetitive tasks (like handling > the different cases of a switch statement) and for writing test cases > but I've never tried to generate a full class or a full method. > > Knowing its limitations I think it speeds up my work but I have to > carefully review every single line because sometimes it "hallucinates" > badly. > > I don't feel that we have an IP issue for this kind of usage: the > generated code it too trivial and too limited in the amount to be > considered an infringement and also I noticed that 99% of the times it > basically copy-pastes code from the other parts of QGIS or GDAL and > many times it's code I've written myself. > > Regarding the policy in QGIS I also believe that the main goal is to > reduce the SNR (signal-noise-ratio) in the PRs, given the limited time > the reviewers have. > > I think a total ban is not enforceable and probably not useful at all, > also I don't feel right that only core developers could use these > tools. > > I second Denis' idea that the important thing is that the contributor > checks that: > - I have reviewed every single line of code. > - I fully understand all the code produced. > > I would probably summarize that in the rule "do not submit anything > that I could not have written myself without any AI tool", not sure > how this could be enforced though but I think that if someone is > caught cheating the current policy should cover the case. > > Cheers > > Alessandro Pasotti > > > > On Wed, Apr 1, 2026 at 10:37?AM Denis Rouzaud via QGIS-Developer > wrote: >> Hi everyone, >> >> I am personally a user of AI-generated code. I find it works exceptionally well for medium-sized libraries, especially in terms of quality of code produced and for writing tests, despite the quantity of code as observed by others. >> >> Regarding QGIS, I have mixed feelings. It works great for the migration of settings: since it's a repetitive task, I could fine-tune a precise prompt which works well while it still requires some attention to review everything. The challenge was really to give all the tiny details, which in the end translates to the capability of grasping (and writing) the whole complexity. >> For more complex and isolated tasks, while the explanations from it always sound super convincing, I agree that it's still quite often not relevant if not completely wrong in some parts of it. And it takes a lot of time to detect this because it's well hidden in the complexity. >> >> (But this statement would have been the same for small librairies a couple of months ago. So, where will we be in a couple of months?) >> >> From my experience, I think the most important thing is to ensure these two points: >> - I have reviewed every single line of code. >> - I fully understand all the code produced. >> In my opinion, checking these two boxes is more important than knowing whether or not AI was used, which is not as black and white either (as already stated, there is a quite wide brand of usage from code completion to full automatic coding). Like cheating/doping in sports, it's a bit subjective. >> >> I also share the concerns of not introducing a differentiation between the type of authors to avoid frustration. >> So I'd be in favor of introducing the 2 checkboxes above and fine tuning the AI use checkbox (not sure exactly how, but to give a better vision on how it has been used). >> >> Kind regards, >> >> Denis Rouzaud >> >> >> Le mer. 1 avr. 2026 ? 09:35, Julien Cabieces via QGIS-Developer a ?crit : >>> >>> Hi, >>> >>> Thank you Nyall for raising this topic. I don't have well established >>> position on this and I don't think there is a good obvious solution >>> here. >>> >>> I'm also deeply concerned about the increased number of AI Pull Requests, >>> often of poor quality. I have also lost time trying to review some of >>> these... >>> >>> But I don't like having different rules for core developers and non core >>> developers. We would be allowed to use a (supposedly) powerful tool, but >>> not new contributors ? I don't like the message that we send to the >>> community. It doesn't seem very welcoming, and people could rightfully >>> say that we are gate keeping. >>> >>> So, If we don't want people proposing AI Pull Requests, I'd prefer >>> banning AI Pull Requests at all. Maybe we could allow the chatbot use but not >>> the code generation? But that's maybe the position of someone who actually >>> doesn't use code generation... >>> >>> In any case, I'd like we stay welcoming and rename the "AI slop" label >>> and its tooltip to something more neutral ("AI generated", "This PR >>> contains AI generated code and needs to be thoroughly reviewed" ? ). >>> >>> Especially when the contributor has explicitly written that he used AI >>> and how he used it. >>> >>> Regards, >>> Julien >>> >>> >>> >>> >>> >>>> Hi, >>>> >>>> I second all the wise words from Even. I am particularly worried by >>>> the impact it would have on growing our contributor base. QGIS already >>>> has a problem with welcoming new contributors, and a policy giving >>>> more special rights to core contributors will only make the situation >>>> worse. Especially while the rules for core contributors are not really >>>> well defined. A retired core contributor could launch an agent to >>>> throw slop PRs at QGIS while a recurrent non-core contributor would >>>> not even be allowed to review his own code with an LLM ? >>>> >>>> I also note that the current situation is bad for our community >>>> atmosphere : the "AI slop" label seems really offensive for newcomers >>>> if not sustained with explanation and clear rules on expectations. I >>>> have recently seen contributors feeling bad after their work has been >>>> marked as slop without any discussion and care. >>>> >>>> I have already casted my opinion recently, but let me restate it : I personally think we should ban any LLM-generated code entirely from QGIS codebase. >>>> >>>> Right now the legal risk is really high, and while there is still no >>>> real legal law case which would indicate that we actually have the >>>> right to include LLM-generated code as GPL into an OpenSource software >>>> as QGIS, each week show new signs that this topic is risky ( supreme >>>> court refusing to handle copyright issue, new laws coming for AI legal >>>> control in France and Europe, the chardet debacle, new law cases and >>>> settlements, wikipedia banning AI-aided contributions?). >>>> >>>> We should keep a look at Debian policy. For now they said it was too early for a position, but I guess as for all risks, when in doubt then no doubt. >>>> >>>> I would be in favor of having a - at least - temporary ban on AI-generated code for all. >>>> >>>> Vincent >>>> >>>> >>>> On 01/04/2026 03:28, Even Rouault via QGIS-Developer wrote: >>>>> Nyall, >>>>> >>>>> As often with that topic, I'm undecided about the best course of action. >>>>> >>>>> For the sake of the discussion, let me play a bit the devil advocate so we have counter points to consider: >>>>> >>>>> - restricting AI tool use to core contributors will make the process >>>>> of becoming core contributor harder. Core contributors would be able >>>>> to improve their capabilities further (questionable claim in terms >>>>> of quality. But in quantity&speed, definitely), which will make it >>>>> harder to grow new core contributors. There's a high chance the new >>>>> generation learning coding today will not be able to produce any >>>>> working code without such tools (like I'm 100% dependent on Valgrind >>>>> to write working non-trivial C++ code). >>>>> >>>>> - besides the issue with new comers to the project, we most >>>>> certainly have regular experienced contributors who haven't the >>>>> status of core contributor, probably because nobody thought about >>>>> proposing them (btw, I've no idea how to determine who is a core >>>>> contributor and who isn't... is there a public list somewhere >>>>> ?). Why would they be discriminated further? >>>>> >>>>> - I would say that we should restrict your proposal even further: >>>>> "only core contributors are allowed to use AI tools, only in the >>>>> areas where they (feel they) are experts ", possibly relaxed with >>>>> "or for contributions involving non-production code (e.g. CI scripts >>>>> (*), etc.)". If I use a AI tool in a part of QGIS I've never >>>>> touched, there's a high risk I will produce low quality code with >>>>> it. >>>>> >>>>> - There's an increased risk that non-core contributors would still >>>>> use AI tools, but without telling us. Naive ones will be easily >>>>> caught; smarter ones will go under our detection radar. But is there >>>>> a difference between good/non-perfect/bad code written with or >>>>> without AI assistance that still passes CI and human review...? At >>>>> the PR unitary level, I'd say none. The issue is more the about the >>>>> increased volume of bad contributions with AI help that can saturate >>>>> our review bandwidth. >>>>> >>>>> - Side point: I'm wondering if the nature of the tool would make a >>>>> difference. I haven't personally used AI tools that can operate on a >>>>> whole code base (Claude code and the like), only chat tools that can >>>>> work/produce limited code fragments. I'd suspect the former are the >>>>> ones where you can vibe code an entire feature, whereas with chatty >>>>> ones, you need to iterate much more and thus have hopefully more >>>>> critical eye. On the other hand, maybe tools that operate at the >>>>> whole code base level can have a better global view... Likely none >>>>> of those approaches is fundamentally better than the other >>>>> one. Different drawbacks. >>>>> >>>>> To me it looks like we are caught in an arm race we haven't decided >>>>> to be part of but can't easily escape. So, half joking/half >>>>> serious, let's use AI tools to detect bad AI output ?!? (ignoring >>>>> who has used the tool). I suspect that AI companies would love such >>>>> outcome... Or maybe, until the AI industry collapses entirely, >>>>> let's temporarily go back to sending patches on 3.5 inches floppy >>>>> disks (1.44 MB ones only, not extended 2.88 MB ones) through (post) >>>>> mail. >>>>> >>>>> At the same time I'm writing this, I'm caught in a situation where >>>>> I'm questioning the need for a GDAL PR whose quality isn't >>>>> necessarily bad (I haven't done the in-depth analysis), but which is >>>>> likely not strictly needed (premature optimization/complication), >>>>> and would have most certainly not be submitted at all if AI didn't >>>>> exist. From my experience with recent AI assisted PRs to GDAL, >>>>> that's actually the main problem. Too much code being written in a >>>>> too short period of time, that will make us totally dependent on AI >>>>> tools to be able to contribute further. >>>>> >>>>> So, all in all, not opposed to your proposal, but we need to be careful how we phrase it to not scare away non-core contributors or increase unwanted discrimination. >>>>> >>>>> Even >>>>> >>>>> (*) Because I've just played this afternoon with Gemini chat to come >>>>> up with some python clang AST code to write custom code checkers to >>>>> verify project specific code rules (like pairing Reference() in >>>>> constructor and Release() in destructor). The result is >>>>> .. well... AI typical. Mostly sort of works after a couple >>>>> iterations, but definitely not something that would be of the >>>>> quality that clang-tidy or similar serious tools would expect. But >>>>> good enough for the purpose it was created. Or at least I was >>>>> tricked into believing it was good enough... >>>>> >>>> _______________________________________________ >>>> QGIS-Developer mailing list >>>> QGIS-Developer at lists.osgeo.org >>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> -- >>> >>> Julien Cabieces >>> Senior Developer at Oslandia >>> julien.cabieces at oslandia.com >>> _______________________________________________ >>> QGIS-Developer mailing list >>> QGIS-Developer at lists.osgeo.org >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > From gdt at lexort.com Wed Apr 1 04:47:08 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 01 Apr 2026 07:47:08 -0400 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> (Vincent Picavet via's message of "Wed, 1 Apr 2026 07:38:23 +0200") References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: I should be clear that really I lean to "no AI contributions, at least for now" - the legal situation is unsettled, as is the social situation, and declining to engage while others figure it out seems best. What I really meant is that compared to where we are now, restricting contributions to those with a track record and human relationships is a positive incremental step. However, I see the lack of equal treatment as a a bug. As for concern about new contributors and what amounts to "the kids these days just want to vibe code and if we aren't ok with that they won't play with us", I think that's ok to defer worrying about. If that's really how it is, the Free Software world has much bigger problems well beyond the scope of any one project. From regis.haubourg at gmail.com Wed Apr 1 04:52:42 2026 From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=) Date: Wed, 1 Apr 2026 13:52:42 +0200 Subject: [QGIS-Developer] Reduced compatibility with old PosgreSQL/PostGIS databases in v. 4.0.0 In-Reply-To: References: <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com> Message-ID: Hi, This is pretty simple, QGIS queries a bunch of things against the catalog system table to understand the capabilities of the server, tables, access privileges and so on.?This query fails because pg_is_in_recovery() function does not exist in postgres 8.4. on QGIS side, it hasn't changed since 2 years: https://github.com/qgis/QGIS/commit/d3474e4e2f258676c75bba874485b816b262acc2 This has nothing to do with the URI. GDAL does not need as many system queries because it is not a GUI tool, so there is less chances it breaks. This has changed between 3.34 and 3.40, to fix a crash https://github.com/qgis/QGIS/pull/57810 So, it is probable we don't add a If statement to handle PG 8.4. This function landed in 9.0 in postgres. Cheers R?gis Haubourg On 31/03/2026 22:00, Carlo A. Bertelli (Charta s.r.l.) wrote: > Thanks to everyone for replying so?quickly to this problem. > I totally agree with?you about the necessity to upgrade PostgreSQL and > I think it's not a good idea to risk adding bugs to a foundation > library as GDAL. > Anyway, I tried version 3.12.3 and it supports reading from a table > and writing to it without problems. But something changed at least on > version 4.0.0 for MacOS. > While the DBManager recognized the table structure, the datasource > browser doesn't and complains: > > Error retrieving fields information for uri: bname='mydb' > host=db.myclientshost.com ?port=5432 > user='mypooruser' sslmode=disable checkPrimaryKeyUnicity='O' > table="oneschema". "mypolytable" > > when browsing fields. > Maybe it has something to do with *uri: *bname?which obviously means > *uri: dbname* but the typo would break something if it is used in the > code. > This is the PostGIS error I get when retrieving this layer: > > 2026-03-31T21:39:29 ? ? WARNING ?Erroneous query: SELECT > has_table_privilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() > ,has_any_column_privilege('"oneschema". > "mypolytable"','INSERT'),has_table_privilege('"oneschema". > "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". > "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function > pg_is_in_recovery() does not exist > ? ? ? ? ? ? ?LINE 1: ...vilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_r... > ? ? ? ? ? ? ? ^ > ? ? ? ? ? ? ?HINT: No function matches the given name and argument > types. You might need to add explicit type casts. > ? ? ? ? ? ? ?] > 2026-03-31T21:39:29 ? ? WARNING ? ?Unable to determine table > access privileges for the "oneschema". "mypolytable" relation. > ? ? ? ? ? ? ?The error message from the database was: > ? ? ? ? ? ? ?ERROR: function pg_is_in_recovery() does not exist > ? ? ? ? ? ? ?LINE 1: ...vilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_r... > ? ? ? ? ? ? ? ^ > ? ? ? ? ? ? ?HINT: No function matches the given name and argument > types. You might need to add explicit type casts. > ? ? ? ? ? ? ?. > ? ? ? ? ? ? ?SQL: SELECT has_table_privilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() > ,has_any_column_privilege('"oneschema". > "mypolytable"','INSERT'),has_table_privilege('"oneschema". > "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". > "mypolytable"','UPDATE'),'f' > 2026-03-31T21:39:29 ? ? WARNING ? ?Erroneous query: SELECT > has_table_privilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() > ,has_any_column_privilege('"oneschema". > "mypolytable"','INSERT'),has_table_privilege('"oneschema". > "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". > "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function > pg_is_in_recovery() does not exist > ? ? ? ? ? ? ?LINE 1: ...vilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_r... > ? ? ? ? ? ? ? ^ > ? ? ? ? ? ? ?HINT: No function matches the given name and argument > types. You might need to add explicit type casts. > ? ? ? ? ? ? ?] > 2026-03-31T21:39:29 ? ? WARNING ? ?Unable to determine table > access privileges for the "oneschema". "mypolytable" relation. > ? ? ? ? ? ? ?The error message from the database was: > ? ? ? ? ? ? ?ERROR: function pg_is_in_recovery() does not exist > ? ? ? ? ? ? ?LINE 1: ...vilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_r... > ? ? ? ? ? ? ? ^ > ? ? ? ? ? ? ?HINT: No function matches the given name and argument > types. You might need to add explicit type casts. > ? ? ? ? ? ? ?. > ? ? ? ? ? ? ?SQL: SELECT has_table_privilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() > ,has_any_column_privilege('"oneschema". > "mypolytable"','INSERT'),has_table_privilege('"oneschema". > "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". > "mypolytable"','UPDATE'),'f' > 2026-03-31T21:46:13 ? ? WARNING ? ?Erroneous query: SELECT > has_table_privilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() > ,has_any_column_privilege('"oneschema". > "mypolytable"','INSERT'),has_table_privilege('"oneschema". > "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". > "mypolytable"','UPDATE'),has_column_privilege('"oneschema". > "mypolytable"','GEOMETRY','UPDATE') returned 7 [ERROR: function > pg_is_in_recovery() does not exist > ? ? ? ? ? ? ?LINE 1: ...vilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_r... > ? ? ? ? ? ? ? ^ > ? ? ? ? ? ? ?HINT: No function matches the given name and argument > types. You might need to add explicit type casts. > ? ? ? ? ? ? ?] > 2026-03-31T21:46:13 ? ? WARNING ? ?Unable to determine table > access privileges for the "oneschema". "mypolytable" relation. > ? ? ? ? ? ? ?The error message from the database was: > ? ? ? ? ? ? ?ERROR: function pg_is_in_recovery() does not exist > ? ? ? ? ? ? ?LINE 1: ...vilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_r... > ? ? ? ? ? ? ? ^ > ? ? ? ? ? ? ?HINT: No function matches the given name and argument > types. You might need to add explicit type casts. > ? ? ? ? ? ? ?. > ? ? ? ? ? ? ?SQL: SELECT has_table_privilege('"oneschema". > "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() > ,has_any_column_privilege('"oneschema". > "mypolytable"','INSERT'),has_table_privilege('"oneschema". > "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". > "mypolytable"','UPDATE'),has_column_privilege('"oneschema". > "mypolytable"','GEOMETRY','UPDATE') > > > while getting the same data by gdalinfo does not need any special > privilege. I should be able to understand what this repeated error > means on the SQL side, but it seems a complete nonsense to me. I'm > sure someone would detect the reason for it. > Is there a way to mitigate it? I was trying to use a virtual ogr file > to handle misbehaving columns; I could convert some specific table to > Spatialite, but I think solving my problem could be useful to someone > else. > Thanks in advance for any hint provided. > c > > On Tue, Mar 31, 2026 at 8:26?PM R?gis Haubourg via QGIS-Developer > wrote: > > 9.1 has reached end of life 10 years ago! > I'm with Even here. A Postgres server out of maintenance period > must be > considered insecure and outdated and must totally be upgraded anyway. > > Cheer, R?gis > > On 31/03/2026 18:14, Stefanos Natsis via QGIS-Developer wrote: > > One breaking change I'm aware of in QGIS 4 is that we've used the > > `CREATE TABLE IF NOT EXISTS` idiom for the `qgis_projects` table > (for > > storing projects in the database) which was introduced in > PostgreSQL 9.1 > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uclaros at gmail.com Wed Apr 1 06:03:30 2026 From: uclaros at gmail.com (Stefanos Natsis) Date: Wed, 1 Apr 2026 16:03:30 +0300 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: Hi all, I'm on the same page with Nyall on this one. While not perfect, a no AI policy will improve the SnR of new PRs and that's important granted that we already struggle with a queue of ~100 PRs! > QGIS already has a problem with welcoming new contributors, and a policy giving more special rights to core contributors will only make the situation worse. I strongly disagree with this opinion, especially before the inflow of AI assisted PRs. It's actually quite the contrary, QGIS is so welcoming to new contributors that we are starting to face issues with AI contributions! Yes, sometimes PRs stay in the queue for too long, however reviews are helpful and not dismissive. It is sane and healthy to not treat core contributors or seasoned veterans the same as newcomers. Core contributors are by definition trusted so they can use the 'risky' tools. This is not gatekeeping in the same way that it is not gatekeeping to limit commit rights to core contributors only. We could still adapt this to requiring a minimum of let's say 50 merged PRs before AI tools are allowed. Of course, since this is not enforceable, practically anyone can still use AI tools to review his code, or even generate new code and we won't know, and that will be OK, as long as the code is good! Overall SnR will be improved though, as anyone wanting to contribute will need to put more effort into it. Best Stefanos On Wed, 1 Apr 2026 at 14:47, Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > I should be clear that really I lean to "no AI contributions, at least > for now" - the legal situation is unsettled, as is the social situation, > and declining to engage while others figure it out seems best. > > What I really meant is that compared to where we are now, restricting > contributions to those with a track record and human relationships is a > positive incremental step. However, I see the lack of equal treatment > as a a bug. > > > As for concern about new contributors and what amounts to "the kids > these days just want to vibe code and if we aren't ok with that they > won't play with us", I think that's ok to defer worrying about. If > that's really how it is, the Free Software world has much bigger > problems well beyond the scope of any one project. > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlo.bertelli at gmail.com Wed Apr 1 08:54:46 2026 From: carlo.bertelli at gmail.com (Carlo A. Bertelli (Charta s.r.l.)) Date: Wed, 1 Apr 2026 17:54:46 +0200 Subject: [QGIS-Developer] Reduced compatibility with old PosgreSQL/PostGIS databases in v. 4.0.0 In-Reply-To: References: <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com> Message-ID: Thanks for the explanation. Maybe I could create a function on the database just to send something sufficiently appeasing to QGIS. Buona Pasqua! c On Wed, Apr 1, 2026 at 1:52?PM R?gis Haubourg wrote: > Hi, > > This is pretty simple, > > QGIS queries a bunch of things against the catalog system table to > understand the capabilities of the server, tables, access privileges and so > on. This query fails because pg_is_in_recovery() function does not exist in > postgres 8.4. on QGIS side, it hasn't changed since 2 years: > https://github.com/qgis/QGIS/commit/d3474e4e2f258676c75bba874485b816b262acc2 > > > This has nothing to do with the URI. > > GDAL does not need as many system queries because it is not a GUI tool, so > there is less chances it breaks. > > This has changed between 3.34 and 3.40, to fix a crash > https://github.com/qgis/QGIS/pull/57810 > > So, it is probable we don't add a If statement to handle PG 8.4. This > function landed in 9.0 in postgres. > > > Cheers > R?gis Haubourg > > On 31/03/2026 22:00, Carlo A. Bertelli (Charta s.r.l.) wrote: > > Thanks to everyone for replying so quickly to this problem. > I totally agree with you about the necessity to upgrade PostgreSQL and I > think it's not a good idea to risk adding bugs to a foundation library as > GDAL. > Anyway, I tried version 3.12.3 and it supports reading from a table and > writing to it without problems. But something changed at least on version > 4.0.0 for MacOS. > While the DBManager recognized the table structure, the datasource browser > doesn't and complains: > >> Error retrieving fields information for uri: bname='mydb' host=d >> b.myclientshost.com port=5432 user='mypooruser' sslmode=disable >> checkPrimaryKeyUnicity='O' table="oneschema". "mypolytable" > > when browsing fields. > Maybe it has something to do with *uri: *bname which obviously means *uri: > dbname* but the typo would break something if it is used in the code. > This is the PostGIS error I get when retrieving this layer: > > 2026-03-31T21:39:29 WARNING Erroneous query: SELECT >> has_table_privilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >> ,has_any_column_privilege('"oneschema". >> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >> "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function >> pg_is_in_recovery() does not exist >> LINE 1: ...vilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_r... >> ^ >> HINT: No function matches the given name and argument types. >> You might need to add explicit type casts. >> ] >> 2026-03-31T21:39:29 WARNING Unable to determine table access >> privileges for the "oneschema". "mypolytable" relation. >> The error message from the database was: >> ERROR: function pg_is_in_recovery() does not exist >> LINE 1: ...vilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_r... >> ^ >> HINT: No function matches the given name and argument types. >> You might need to add explicit type casts. >> . >> SQL: SELECT has_table_privilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >> ,has_any_column_privilege('"oneschema". >> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >> "mypolytable"','UPDATE'),'f' >> 2026-03-31T21:39:29 WARNING Erroneous query: SELECT >> has_table_privilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >> ,has_any_column_privilege('"oneschema". >> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >> "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function >> pg_is_in_recovery() does not exist >> LINE 1: ...vilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_r... >> ^ >> HINT: No function matches the given name and argument types. >> You might need to add explicit type casts. >> ] >> 2026-03-31T21:39:29 WARNING Unable to determine table access >> privileges for the "oneschema". "mypolytable" relation. >> The error message from the database was: >> ERROR: function pg_is_in_recovery() does not exist >> LINE 1: ...vilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_r... >> ^ >> HINT: No function matches the given name and argument types. >> You might need to add explicit type casts. >> . >> SQL: SELECT has_table_privilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >> ,has_any_column_privilege('"oneschema". >> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >> "mypolytable"','UPDATE'),'f' >> 2026-03-31T21:46:13 WARNING Erroneous query: SELECT >> has_table_privilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >> ,has_any_column_privilege('"oneschema". >> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >> "mypolytable"','UPDATE'),has_column_privilege('"oneschema". >> "mypolytable"','GEOMETRY','UPDATE') returned 7 [ERROR: function >> pg_is_in_recovery() does not exist >> LINE 1: ...vilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_r... >> ^ >> HINT: No function matches the given name and argument types. >> You might need to add explicit type casts. >> ] >> 2026-03-31T21:46:13 WARNING Unable to determine table access >> privileges for the "oneschema". "mypolytable" relation. >> The error message from the database was: >> ERROR: function pg_is_in_recovery() does not exist >> LINE 1: ...vilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_r... >> ^ >> HINT: No function matches the given name and argument types. >> You might need to add explicit type casts. >> . >> SQL: SELECT has_table_privilege('"oneschema". >> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >> ,has_any_column_privilege('"oneschema". >> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >> "mypolytable"','UPDATE'),has_column_privilege('"oneschema". >> "mypolytable"','GEOMETRY','UPDATE') > > > while getting the same data by gdalinfo does not need any special > privilege. I should be able to understand what this repeated error means on > the SQL side, but it seems a complete nonsense to me. I'm sure someone > would detect the reason for it. > Is there a way to mitigate it? I was trying to use a virtual ogr file to > handle misbehaving columns; I could convert some specific table to > Spatialite, but I think solving my problem could be useful to someone else. > Thanks in advance for any hint provided. > c > > On Tue, Mar 31, 2026 at 8:26?PM R?gis Haubourg via QGIS-Developer < > qgis-developer at lists.osgeo.org> wrote: > >> 9.1 has reached end of life 10 years ago! >> I'm with Even here. A Postgres server out of maintenance period must be >> considered insecure and outdated and must totally be upgraded anyway. >> >> Cheer, R?gis >> >> On 31/03/2026 18:14, Stefanos Natsis via QGIS-Developer wrote: >> > One breaking change I'm aware of in QGIS 4 is that we've used the >> > `CREATE TABLE IF NOT EXISTS` idiom for the `qgis_projects` table (for >> > storing projects in the database) which was introduced in PostgreSQL 9.1 >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlo.bertelli at gmail.com Wed Apr 1 09:50:21 2026 From: carlo.bertelli at gmail.com (Carlo A. Bertelli (Charta s.r.l.)) Date: Wed, 1 Apr 2026 18:50:21 +0200 Subject: [QGIS-Developer] Reduced compatibility with old PosgreSQL/PostGIS databases in v. 4.0.0 In-Reply-To: References: <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com> Message-ID: I just added CREATE OR REPLACE FUNCTION pg_is_in_recovery() RETURNS boolean LANGUAGE sql AS $$ SELECT false; $$; to the 8.4 database (it will never be in recovery anyway ;.)). I think there are other quirks, but I can at least display the map. Thanks for the hint provided. On Wed, Apr 1, 2026 at 5:54?PM Carlo A. Bertelli (Charta s.r.l.) < carlo.bertelli at gmail.com> wrote: > Thanks for the explanation. Maybe I could create a function on the > database just to send something sufficiently appeasing to QGIS. > Buona Pasqua! > c > > On Wed, Apr 1, 2026 at 1:52?PM R?gis Haubourg > wrote: > >> Hi, >> >> This is pretty simple, >> >> QGIS queries a bunch of things against the catalog system table to >> understand the capabilities of the server, tables, access privileges and so >> on. This query fails because pg_is_in_recovery() function does not exist in >> postgres 8.4. on QGIS side, it hasn't changed since 2 years: >> https://github.com/qgis/QGIS/commit/d3474e4e2f258676c75bba874485b816b262acc2 >> >> >> This has nothing to do with the URI. >> >> GDAL does not need as many system queries because it is not a GUI tool, >> so there is less chances it breaks. >> >> This has changed between 3.34 and 3.40, to fix a crash >> https://github.com/qgis/QGIS/pull/57810 >> >> So, it is probable we don't add a If statement to handle PG 8.4. This >> function landed in 9.0 in postgres. >> >> >> Cheers >> R?gis Haubourg >> >> On 31/03/2026 22:00, Carlo A. Bertelli (Charta s.r.l.) wrote: >> >> Thanks to everyone for replying so quickly to this problem. >> I totally agree with you about the necessity to upgrade PostgreSQL and I >> think it's not a good idea to risk adding bugs to a foundation library as >> GDAL. >> Anyway, I tried version 3.12.3 and it supports reading from a table and >> writing to it without problems. But something changed at least on version >> 4.0.0 for MacOS. >> While the DBManager recognized the table structure, the datasource >> browser doesn't and complains: >> >>> Error retrieving fields information for uri: bname='mydb' host=d >>> b.myclientshost.com port=5432 user='mypooruser' sslmode=disable >>> checkPrimaryKeyUnicity='O' table="oneschema". "mypolytable" >> >> when browsing fields. >> Maybe it has something to do with *uri: *bname which obviously means *uri: >> dbname* but the typo would break something if it is used in the code. >> This is the PostGIS error I get when retrieving this layer: >> >> 2026-03-31T21:39:29 WARNING Erroneous query: SELECT >>> has_table_privilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >>> ,has_any_column_privilege('"oneschema". >>> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >>> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >>> "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function >>> pg_is_in_recovery() does not exist >>> LINE 1: ...vilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_r... >>> ^ >>> HINT: No function matches the given name and argument >>> types. You might need to add explicit type casts. >>> ] >>> 2026-03-31T21:39:29 WARNING Unable to determine table access >>> privileges for the "oneschema". "mypolytable" relation. >>> The error message from the database was: >>> ERROR: function pg_is_in_recovery() does not exist >>> LINE 1: ...vilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_r... >>> ^ >>> HINT: No function matches the given name and argument >>> types. You might need to add explicit type casts. >>> . >>> SQL: SELECT has_table_privilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >>> ,has_any_column_privilege('"oneschema". >>> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >>> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >>> "mypolytable"','UPDATE'),'f' >>> 2026-03-31T21:39:29 WARNING Erroneous query: SELECT >>> has_table_privilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >>> ,has_any_column_privilege('"oneschema". >>> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >>> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >>> "mypolytable"','UPDATE'),'f' returned 7 [ERROR: function >>> pg_is_in_recovery() does not exist >>> LINE 1: ...vilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_r... >>> ^ >>> HINT: No function matches the given name and argument >>> types. You might need to add explicit type casts. >>> ] >>> 2026-03-31T21:39:29 WARNING Unable to determine table access >>> privileges for the "oneschema". "mypolytable" relation. >>> The error message from the database was: >>> ERROR: function pg_is_in_recovery() does not exist >>> LINE 1: ...vilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_r... >>> ^ >>> HINT: No function matches the given name and argument >>> types. You might need to add explicit type casts. >>> . >>> SQL: SELECT has_table_privilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >>> ,has_any_column_privilege('"oneschema". >>> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >>> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >>> "mypolytable"','UPDATE'),'f' >>> 2026-03-31T21:46:13 WARNING Erroneous query: SELECT >>> has_table_privilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >>> ,has_any_column_privilege('"oneschema". >>> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >>> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >>> "mypolytable"','UPDATE'),has_column_privilege('"oneschema". >>> "mypolytable"','GEOMETRY','UPDATE') returned 7 [ERROR: function >>> pg_is_in_recovery() does not exist >>> LINE 1: ...vilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_r... >>> ^ >>> HINT: No function matches the given name and argument >>> types. You might need to add explicit type casts. >>> ] >>> 2026-03-31T21:46:13 WARNING Unable to determine table access >>> privileges for the "oneschema". "mypolytable" relation. >>> The error message from the database was: >>> ERROR: function pg_is_in_recovery() does not exist >>> LINE 1: ...vilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_r... >>> ^ >>> HINT: No function matches the given name and argument >>> types. You might need to add explicit type casts. >>> . >>> SQL: SELECT has_table_privilege('"oneschema". >>> "mypolytable"','SELECT'),pg_is_in_recovery(),current_schema() >>> ,has_any_column_privilege('"oneschema". >>> "mypolytable"','INSERT'),has_table_privilege('"oneschema". >>> "mypolytable"','DELETE'),has_any_column_privilege('"oneschema". >>> "mypolytable"','UPDATE'),has_column_privilege('"oneschema". >>> "mypolytable"','GEOMETRY','UPDATE') >> >> >> while getting the same data by gdalinfo does not need any special >> privilege. I should be able to understand what this repeated error means on >> the SQL side, but it seems a complete nonsense to me. I'm sure someone >> would detect the reason for it. >> Is there a way to mitigate it? I was trying to use a virtual ogr file to >> handle misbehaving columns; I could convert some specific table to >> Spatialite, but I think solving my problem could be useful to someone else. >> Thanks in advance for any hint provided. >> c >> >> On Tue, Mar 31, 2026 at 8:26?PM R?gis Haubourg via QGIS-Developer < >> qgis-developer at lists.osgeo.org> wrote: >> >>> 9.1 has reached end of life 10 years ago! >>> I'm with Even here. A Postgres server out of maintenance period must be >>> considered insecure and outdated and must totally be upgraded anyway. >>> >>> Cheer, R?gis >>> >>> On 31/03/2026 18:14, Stefanos Natsis via QGIS-Developer wrote: >>> > One breaking change I'm aware of in QGIS 4 is that we've used the >>> > `CREATE TABLE IF NOT EXISTS` idiom for the `qgis_projects` table (for >>> > storing projects in the database) which was introduced in PostgreSQL >>> 9.1 >>> _______________________________________________ >>> QGIS-Developer mailing list >>> QGIS-Developer at lists.osgeo.org >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From regis.haubourg at gmail.com Wed Apr 1 09:58:32 2026 From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=) Date: Wed, 1 Apr 2026 18:58:32 +0200 Subject: [QGIS-Developer] Reduced compatibility with old PosgreSQL/PostGIS databases in v. 4.0.0 In-Reply-To: References: <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com> Message-ID: <3b45d712-d3e2-40e6-a5db-b8c50cc1bc74@gmail.com> Congratulations, you found the workaround of the decade ! (published on purpose on April's fool? ) More seriously, please rush your IT departement or DBA to upgrade. You will also benefit a lot of speed and feature improvements. Bien cordialement, R?gis Haubourg On 01/04/2026 18:50, Carlo A. Bertelli (Charta s.r.l.) wrote: > > AS $$ From carlo.bertelli at gmail.com Wed Apr 1 13:14:52 2026 From: carlo.bertelli at gmail.com (Carlo A. Bertelli (Charta s.r.l.)) Date: Wed, 1 Apr 2026 22:14:52 +0200 Subject: [QGIS-Developer] Reduced compatibility with old PosgreSQL/PostGIS databases in v. 4.0.0 In-Reply-To: <3b45d712-d3e2-40e6-a5db-b8c50cc1bc74@gmail.com> References: <915f2f31-ab22-46d8-9b14-44b2cd795341@spatialys.com> <3b45d712-d3e2-40e6-a5db-b8c50cc1bc74@gmail.com> Message-ID: Yes, I will. Meanwhile, I thank you all for this, it will let me work on this database while I get the upgrade. Good Easter. c On Wed, Apr 1, 2026 at 6:58?PM R?gis Haubourg wrote: > Congratulations, you found the workaround of the decade ! (published on > purpose on April's fool? ) > > More seriously, please rush your IT departement or DBA to upgrade. You > will also benefit a lot of speed and feature improvements. > > Bien cordialement, > R?gis Haubourg > > On 01/04/2026 18:50, Carlo A. Bertelli (Charta s.r.l.) wrote: > > > > AS $$ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin.buira at gmail.com Wed Apr 1 13:57:41 2026 From: valentin.buira at gmail.com (Valentin Buira) Date: Wed, 1 Apr 2026 22:57:41 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: Hi, Personally, I am -1 on this one, but not because I think AI contributions are good, quite the contrary. But because the cure (banning AI LLM) could be worse than the disease. Let me explain. To me the situation is a bit similar to the alcohol prohibition law. While the intent to reduce alcohol consumption was good, the unintended consequences were the rise of organized crime. If we ban outright AI contributions, people will not stop using them, *they will stop disclaiming their use of AI tools*. We will end up with a lot of "stealth" AI PR. And I suspect spending much more time chasing the liars. Even in the long term, let's imagine the lawmakers decide AI generated code is not compatible with GPL licence, it would be much easier to scrape this code if each PRs with AI are correctly flagged today. With our current AI tools policy at least people are not afraid to disclaim their use of AI. We also run the risk of mistaking a genuinely new contributor to an AI agent parrot. It happened before with the Slop label, I don't see why it would not happen with banning new AI contributions. But I agree we need to do something about PR flooding, I actually like the idea of Even: > So, half joking/half serious, let's > use AI tools to detect bad AI output ?!? I would add to the suggestions: * to detect IA accounts they usually have a "too pretty" github profile, too many technologies, too many emojis etc.. * I would like to suggest one more than may seem unusual at first; It would be to add more "good first issue" so we can funnel new contributors energy to these lower risk issues but that are still interesting to have in QGIS. And requires new contributors to complete at least one while letting use time to sort which contributor is worth taking reviewer time and which contributor is a LLM parrot. The state of IA LLM is changing rapidly. I appreciate that we can have this discussion and that we can periodically update our policy towards AI. But for now my position is to keep our disclaimer policy and wait and see. I would be very curious about the outcome of the total ban on other FOSS projects in a year from now. Finally, concerning the label, I would like to note the label is not named 'AI Slop' but 'Slop /!\/!\' which I think is worse and could be seen as a personal attack on their works. I got lucky to join the QGIS project before the advent of AI tools, but I don't think I would have liked to be labeled as we do today for new contributors. So I second the suggestion raised earlier in the thread to rename the label to something more neutral like "AI generated" or "AI Warning" Kind regards, Valentin Le mer. 1 avr. 2026 ? 15:04, Stefanos Natsis via QGIS-Developer a ?crit : > > Hi all, > > I'm on the same page with Nyall on this one. While not perfect, a no AI policy will improve the SnR of new PRs and that's important granted that we already struggle with a queue of ~100 PRs! > > > QGIS already has a problem with welcoming new contributors, and a policy giving more special rights to core contributors will only make the situation worse. > > I strongly disagree with this opinion, especially before the inflow of AI assisted PRs. It's actually quite the contrary, QGIS is so welcoming to new contributors that we are starting to face issues with AI contributions! Yes, sometimes PRs stay in the queue for too long, however reviews are helpful and not dismissive. > > It is sane and healthy to not treat core contributors or seasoned veterans the same as newcomers. Core contributors are by definition trusted so they can use the 'risky' tools. This is not gatekeeping in the same way that it is not gatekeeping to limit commit rights to core contributors only. We could still adapt this to requiring a minimum of let's say 50 merged PRs before AI tools are allowed. > > Of course, since this is not enforceable, practically anyone can still use AI tools to review his code, or even generate new code and we won't know, and that will be OK, as long as the code is good! > Overall SnR will be improved though, as anyone wanting to contribute will need to put more effort into it. > > Best > Stefanos > > On Wed, 1 Apr 2026 at 14:47, Greg Troxel via QGIS-Developer wrote: >> >> I should be clear that really I lean to "no AI contributions, at least >> for now" - the legal situation is unsettled, as is the social situation, >> and declining to engage while others figure it out seems best. >> >> What I really meant is that compared to where we are now, restricting >> contributions to those with a track record and human relationships is a >> positive incremental step. However, I see the lack of equal treatment >> as a a bug. >> >> >> As for concern about new contributors and what amounts to "the kids >> these days just want to vibe code and if we aren't ok with that they >> won't play with us", I think that's ok to defer worrying about. If >> that's really how it is, the Free Software world has much bigger >> problems well beyond the scope of any one project. >> >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer From alexander.bruy at gmail.com Thu Apr 2 00:14:15 2026 From: alexander.bruy at gmail.com (Alexander Bruy) Date: Thu, 2 Apr 2026 08:14:15 +0100 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: Hi all, I'm not sure what would be the best solution here. While I support Nyall and Stefanos statements about reducing SNR, I also agree with Alessandro that ban of AI use is not enforceable. I also second Stefanos' disagreement about the statement that QGIS has a problem with being welcoming to new contributors. As someone who started contributing when one had to send patches to a core developer by email or attach them to a ticket in Trac, I'd say currently barriers for newcomers are much lower. There are a lot of guides, documentation, code reviewing tools that help and make things much easier. As for the code review process, I always see how core devs help new contributors to finalize and polish their work, not discarding or gatekeeping them. While I do not have a strong opinion on what would be the best solution here: a complete ban of the AI tools or something else. But l can't agree with the statement that enforcing some limitations will drive people from disclosing AI use. From what I can see, some already do this despite the fact that we have a corresponding checkbox in the PR template, for example at least some of these pull-requests - https://github.com/qgis/QGIS/pulls?q=is%3Apr+author%3Aabinayasiva29-web+is%3Aclosed, - https://github.com/qgis/QGIS/pulls?q=is%3Apr+author%3Asidhansu10+is%3Aclosed were submitted after we started to ask for AI use disclosure and authors often were not open about it even when asked directly in the comments. Probably, as proposed in previous emails, we can ask contributors to confirm that they have checked and understand code, but again there is no real way to enforce this. We will be relying on their good will and honesty anyway, as we do now. ??, 1 ????. 2026??. ? 14:03 Stefanos Natsis via QGIS-Developer ????: > > Hi all, > > I'm on the same page with Nyall on this one. While not perfect, a no AI policy will improve the SnR of new PRs and that's important granted that we already struggle with a queue of ~100 PRs! > > > QGIS already has a problem with welcoming new contributors, and a policy giving more special rights to core contributors will only make the situation worse. > > I strongly disagree with this opinion, especially before the inflow of AI assisted PRs. It's actually quite the contrary, QGIS is so welcoming to new contributors that we are starting to face issues with AI contributions! Yes, sometimes PRs stay in the queue for too long, however reviews are helpful and not dismissive. > > It is sane and healthy to not treat core contributors or seasoned veterans the same as newcomers. Core contributors are by definition trusted so they can use the 'risky' tools. This is not gatekeeping in the same way that it is not gatekeeping to limit commit rights to core contributors only. We could still adapt this to requiring a minimum of let's say 50 merged PRs before AI tools are allowed. > > Of course, since this is not enforceable, practically anyone can still use AI tools to review his code, or even generate new code and we won't know, and that will be OK, as long as the code is good! > Overall SnR will be improved though, as anyone wanting to contribute will need to put more effort into it. > > Best > Stefanos -- Alexander Bruy From apasotti at gmail.com Thu Apr 2 01:10:46 2026 From: apasotti at gmail.com (Alessandro Pasotti) Date: Thu, 2 Apr 2026 10:10:46 +0200 Subject: [QGIS-Developer] Announcing QEP 414: QGIS Server OAPIF JSON-FG and FlatGeobuf support Message-ID: Hi, I am pleased to announce that there is a new QEP about enhancing QGIS Server OAPIF output with two additional formats JSON-FG and FlatGeobuf https://github.com/qgis/QGIS-Enhancement-Proposals/pull/371 Rendered view here: https://github.com/elpaso/QGIS-Enhancement-Proposals/blob/qep-414-server-oapif-jsonfg-flatgeobuf/qep-414-server-oapif-jsonfg-flatgeobuf.md Looking forward to reading your comments! Cheers. -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it From valentin.buira at gmail.com Thu Apr 2 05:53:58 2026 From: valentin.buira at gmail.com (Valentin Buira) Date: Thu, 2 Apr 2026 14:53:58 +0200 Subject: [QGIS-Developer] Announcing QEP 415: Refactor the evaluation of processing model with a dependency graph Message-ID: Hi devs, I just posted a new QEP about refactoring the evaluation of processing model with a dependency graph. With the aim to have some immediate performance gains as well as long term improvements to the model designer. Please see https://githqgis-developer at lists.osgeo.orgub.com/qgis/QGIS-Enhancement-Proposals/pull/372 This QEP will be submit as part of the QGIS.org grant program Thanks for any feedback and cheers, Valentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at opengis.ch Thu Apr 2 07:30:07 2026 From: david at opengis.ch (David Signer) Date: Thu, 2 Apr 2026 16:30:07 +0200 Subject: [QGIS-Developer] QEP 416: Expression filter on vector layers Message-ID: Hi there As already announced once on this mailing list, I want to propose a new filter possibility for vector layers. https://github.com/qgis/QGIS-Enhancement-Proposals/pull/373 See this QEP about the new filter option on vector layers similar to the query builder, accessible via Layer > Filter. This enables us to filter all types of vector layers according to QGIS expressions and use elements such as variables, custom functions and more. Thanks for your feedback and Happy Easter Dave --- David Signer Senior Developer & INTERLIS Architect | Team QGIS & Industry Solutions david at opengis.ch OPENGIS.ch -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Apr 3 11:03:53 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 3 Apr 2026 20:03:53 +0200 Subject: [QGIS-Developer] ETRS89-XXX fallouts (aka PROJ 9.8.0 related issues) Message-ID: Hi, Not a QGIS bug, but just to make you aware that we (PROJ) are seeing several reports from European users that are facing issues with the deployment of the new ETRS89-XXX datums in the EPSG database that is provided with PROJ 9.8.0, instead of previous use of generic ETRS89 datum ensemble, in particular for datum transformations between those new datums and existing national datums. https://github.com/OSGeo/PROJ/pull/4736 has a few examples of such issues. If there are other cases, please report (as PROJ tickets) so we can report back to EPSG. It could be wise for OSGeo4W installers to downgrade to 9.7.1 in the mean time, especially for QGIS 3.44 build (didn't check which PROJ version it used) Even -- http://www.spatialys.com My software is free, but my time generally not. From denis.rouzaud at gmail.com Tue Apr 7 05:37:49 2026 From: denis.rouzaud at gmail.com (Denis Rouzaud) Date: Tue, 7 Apr 2026 14:37:49 +0200 Subject: [QGIS-Developer] Call for vote on QEP 407 "Introduce a data viewer for the model designer" In-Reply-To: References: Message-ID: Hi all, Just a small reminder that this QEP is open to voting and has not yet received any. Since Valentin is from the same company, I would like to avoid voting myself on this one :) https://github.com/qgis/QGIS-Enhancement-Proposals/pull/359 Cheers, Denis Le lun. 23 f?vr. 2026 ? 21:47, Valentin Buira via QGIS-Developer < qgis-developer at lists.osgeo.org> a ?crit : > Hi all, > > The QEP 407 about adding a data viewer in the model designer has now passed the two-week threshold, and is now in a state ready for voting. > Thank you everyone for your comments and your suggestions on the QEP. > > Please cast your votes in the pull request : > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/359 > > Thanks in advance for taking the time to vote > > Kind regards, > Valentin > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Thu Apr 9 00:14:37 2026 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Thu, 09 Apr 2026 09:14:37 +0200 Subject: [QGIS-Developer] Announcing QEP 417: Replace SIP_FACTORY with std::unique_ptr Message-ID: <87a4vcip0i.fsf@julienlaptop.home> Hi all, I just posted a new QEP about replacing SIP_FACTORY with std::unique_ptr [0] This QEP will be submitted to the QGIS.org grant program Regards, Julien [0] https://github.com/qgis/QGIS-Enhancement-Proposals/pull/374 -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From valentin.buira at gmail.com Thu Apr 9 07:17:19 2026 From: valentin.buira at gmail.com (Valentin Buira) Date: Thu, 9 Apr 2026 16:17:19 +0200 Subject: [QGIS-Developer] QEP 418: Better versioning for ".model3" file Message-ID: Hi all, I just posted a new QEP about the ".model3" format used to store processing models, and how to improve the versioning of it. Please see https://github.com/qgis/QGIS-Enhancement-Proposals/pull/375 for the complete QEP This QEP will be submitted as part of the QGIS.org grant program Thanks for any feedbacks, cheers, Valentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dongwei.sun at slrconsulting.com Thu Apr 9 08:47:11 2026 From: dongwei.sun at slrconsulting.com (Dongwei Sun) Date: Thu, 9 Apr 2026 15:47:11 +0000 Subject: [QGIS-Developer] QGIS QA System/Procedure Message-ID: Dear QGIS team, I am a groundwater modeler from SLR Consulting. I am currently working on a software plan for QGIS version 3.34.1 per company policy before using it on project. I am wondering if there is any formal quality assurance system/procedure for QGIS? Also, I am wondering if there is any suggested installation verifications for the users? Any insight would be greatly appreciated. Thank you, Dongwei Dongwei Sun Groundwater Modeler - M +1 4373412136 E dongwei.sun at slrconsulting.com SLR Consulting (Canada) Ltd. 55 University Avenue, Suite 501, Toronto, ON, Canada M5J 2H7 ?Confidentiality Notice and Disclaimer ?This communication and any attachment(s) contain information which is confidential and may also be legally privileged. It is intended for the exclusive use of the recipient(s) to whom it is addressed. If you have received this communication in error, please e-mail us by return e-mail and then delete the e-mail from your system together with any copies of it. Any views or opinions are solely those of the author and do not represent those of SLR International Corporation, or any of its subsidiaries, unless specifically stated. SLR is committed to the responsible and ethical use of relevant technologies including artificial intelligence (AI). If you have any questions or concerns, please contact us directly. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image882488.png Type: image/png Size: 2260 bytes Desc: image882488.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image216274.png Type: image/png Size: 4674 bytes Desc: image216274.png URL: From clhermansen at gmail.com Thu Apr 9 09:12:07 2026 From: clhermansen at gmail.com (chris hermansen) Date: Thu, 9 Apr 2026 09:12:07 -0700 Subject: [QGIS-Developer] QGIS QA System/Procedure In-Reply-To: References: Message-ID: Dongwei, On Thu, Apr 9, 2026, 08:47 Dongwei Sun via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Dear QGIS team, > > I am a groundwater modeler from SLR Consulting. I am currently working on > a software plan for QGIS version 3.34.1 per company policy before using it > on project. I am wondering if there is any formal quality assurance > system/procedure for QGIS? > > Also, I am wondering if there is any suggested installation verifications > for the users? > > Any insight would be greatly appreciated. > > Dongwei Sun > Groundwater Modeler > ? > M > Perhaps this web page that describes the QGIS release process may help you. https://qgis.org/resources/roadmap/ > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Thu Apr 9 19:18:09 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Fri, 10 Apr 2026 12:18:09 +1000 Subject: [QGIS-Developer] Announcing QEP 419: Improved Wayland compatibility Message-ID: Over the last couple of years, most Linux distributions and desktop environments have been transitioning from the legacy X11 display server to the Wayland standard. The transition has reached a stage where many environments are now completely dropping support for the X11 server. This presents a challenge to Linux QGIS users, as the current QGIS versions have limitations and bugs when run in a Wayland environment. QEP 419 aims to address these limitations in the "best possible" way, given the (many!) constraints of Wayland. Please see full details of the proposal at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/376. Discussion and comments welcome! This QEP will be submitted as part of the QGIS.org grant program Nyall -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Thu Apr 9 19:46:34 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Fri, 10 Apr 2026 12:46:34 +1000 Subject: [QGIS-Developer] Announcing QEP 420: Restore the print layout HTML item for QGIS 4 Message-ID: An ongoing pain point for the QGIS project was QGIS 3.x's reliance on the Qt Webkit library. This library has long been deprecated by the Qt maintainers, and was finally completely removed in Qt 6. A direct consequence of this is that functionality which relied on Qt Webkit has been dropped in QGIS 4.0. This includes: - The print layout HTML item - The HTML annotation item This project will resurrect the print layout HTML item. The underlying low-level changes will also facilitate a potential replacement for the HTML annotation item, but this is out-of-scope for the current project. Note that the functionality required for the QGIS HTML item is also required for some third-party QGIS plugins, such as the DataPlotly plugin. These plugins are currently broken on QGIS 4.x as a result. Please see full details of the proposal at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/377. Discussion and comments welcome! This QEP will be submitted as part of the QGIS.org grant program Nyall -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at qgis.org Thu Apr 9 21:55:16 2026 From: andreas at qgis.org (Andreas Neumann) Date: Fri, 10 Apr 2026 06:55:16 +0200 Subject: [QGIS-Developer] [Qgis-user] Announcing QEP 419: Improved Wayland compatibility In-Reply-To: References: Message-ID: Hi Nyall, Thank you for this initiative. Sounds useful to me. As a reminder: we still have a significant number of consulting/development hours at KDAB available to support such an effort, if it is useful to reach the goal. Greetings, Andreas On Fri, 10 Apr 2026 at 04:18, Nyall Dawson via QGIS-User < qgis-user at lists.osgeo.org> wrote: > Over the last couple of years, most Linux distributions and desktop > environments have been transitioning from the legacy X11 display server to > the Wayland standard. The transition has reached a stage where many > environments are now completely dropping support for the X11 server. > > This presents a challenge to Linux QGIS users, as the current QGIS > versions have limitations and bugs when run in a Wayland environment. > > QEP 419 aims to address these limitations in the "best possible" way, > given the (many!) constraints of Wayland. > > Please see full details of the proposal at > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/376. Discussion > and comments welcome! > > This QEP will be submitted as part of the QGIS.org grant program > > Nyall > > _______________________________________________ > QGIS-User mailing list > QGIS-User at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > -- -- Andreas Neumann QGIS.ORG board member (treasurer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From nirvn.asia at gmail.com Fri Apr 10 03:01:31 2026 From: nirvn.asia at gmail.com (Mathieu Pellerin) Date: Fri, 10 Apr 2026 17:01:31 +0700 Subject: [QGIS-Developer] QEP 409: Attribute Form QML Widget Editing Capabilities Message-ID: Greetings all, This is to inform the developers mailing list of a QEP - https://github.com/qgis/QGIS-Enhancement-Proposals/pull/364 - which I had opened on February 1st, 2026. The QEP proposes to add editing capabilities for attributes form QML editor widgets. While it's been there for a while and @signedav added some comments, more discussion would be most welcome prior to calling for the vote. Best, Mathieu -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Apr 10 06:12:16 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 10 Apr 2026 15:12:16 +0200 Subject: [QGIS-Developer] PROJ 9.8.1 is released Message-ID: It?s my pleasure to announce the release of PROJ 9.8.1! The release includes a few updates, bug fixes and a major regression fix for ETRS89-related coordinates operations. See the release notes below. Download the archives here: https://download.osgeo.org/proj/proj-9.8.1.tar.gz https://download.osgeo.org/proj/proj-9.8.1.zip /Even ## 9.8.1 ### Warning It was discovered after the PROJ 9.8.0 release that several EPSG updates introduced after EPSG v12.033 - notably the introduction of national realizations of ETRS89 (ETRS89-XXX [?] where XXX is the 3-letter ISO country code) - caused backward incompatibilities in some workflows involving the ETRS89 CRS. In particular, transformations between ETRS89 and national CRSs based on other datums are known to be affected for Austria, Belgium, Catalonia, the Netherlands, Romania, and Serbia. See #4736 for more details. While we intend to resume tracking the latest EPSG releases in future PROJ versions, the safest solution identified so far to address these regressions is to **revert the EPSG related content of its database from EPSG v12.049 to v12.029**, where v12.029 was the version distributed with PROJ 9.7.1 As a consequence of this revert, the EPSG datum and CRS records introduced in PROJ 9.8.0, which are mostly related to the new ETRS89-XXX datum and CRS, are no longer available in PROJ 9.8.1. ### Updates * Database: **Revert content from EPSG v12.049 to v12.029** (#4741). ? See above warning for more details. * CMake: handle deprecated SQLite::SQLite3 target in CMake 4.3 (#4694) ### Bug Fixes * Make sure that epoch is set in more scenarios of time-dependent transformations (#4688) * pj_obj_create: use database context if already open for grid name resolution (#4703) * Chain vertical CRS transformations through intermediate same-datum vertical CRS (#4711) ? Helps for example for **EPSG:5705** (Baltic 1977 height) to **EPSG:5706** (Caspian depth) ? by using intermediate operation from Baltic 1977 height to Caspian *height* * gie: various fixes around crs_src/crs_dst support and bootstrap ? test/gie/epsg_grid.gie and test/gie/epsg_no_grid.gie (#4740) -- http://www.spatialys.com My software is free, but my time generally not. From lova at kartoza.com Fri Apr 10 07:00:00 2026 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 10 Apr 2026 17:00:00 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from March 23 to April 10th, 2026 Message-ID: Hello everyone, Please find some highlights regarding the development and maintenance of the QGIS Websites for the last two weeks, from March 23 to April 10th, 2026. I will include the progress made during February and early March in our upcoming sprint video on the QGIS YouTube channel. *QGIS.org:* - Pin Honorary members on top [New PR] - Add VerifiedApps.txt for Flatpak application verification [Deployed] - Add changes from pathmapper [Deployed] - Swap Stripe and Payrexx donation widgets in download and thank you pages [Deployed] - Fix OS autodetect on download page [Deployed] *QGIS Plugins:* - Add security scan status indicators in the plugins details page [New PR] - Add social authentication using django-allauth [New PR] - Add Plugin Publishing Guidelines page and update sidebar links [New PR] - Add FAQ section on plugin version numbering convention [New PR] - Only show latest unapproved version in the reviews list [Deployed] - Fix error sorting my plugins with latest_version_date [Deployed] - Add validation for backslashes in ZIP file names [Deployed] *QGIS Planet:* - Fix shortname casing for Auchindown subscriber [New PR] *QGIS Infrastructure:* - We had a Sprint with Tim and Ivan during the week of March 23rd. We've addressed some issues with our upcoming infrastructure configurations - We also deployed a new self-hosted GitHub actions runner for our configuration - We migrated the download mirrors (dl1, dl2, dl3 and dl4) to dedicated servers - We tested deploying a host to production Have a nice weekend, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Apr 10 15:24:13 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 11 Apr 2026 00:24:13 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: Message-ID: Nyall, Actually, I deeply sympathize with your position after having received 3 Claude-generated GDAL PRs today (haven't time yet to read the 3rd one). Human maintainers aren't just able to cope with that. It is so disturbing and nerve-breaking to read code that looks plausible, but you've that instinct it must be somehow wrong and you have to figure out how and where exactly. And it's sometimes damn painful to figure that. It is not like 100% human code was immune to be wrong, but the failure modes are different. Interestingly, I observe those tools are actually "good" at adding "working" hacks in already too much hacky/complicated code. Whereas a human reaction would have been "what a mess!" and would have started by refactoring it. So if you aren't careful enough, you may end up in a code base that only machines can maintain (likely that's the whole plot). Maybe that's the future of our "industry" (after all, we rarely look at assembly code nowadays....) ? I'd wish that we could go back to times where that stuff didn't exist. Maybe time to open that bar at Foo pass (https://en.wikipedia.org/wiki/Foo_Pass) that we discussed with Matthias around a beer in Vienna a couple years ago. Orders will be registered on punch cards. In vino veritas! (l'abus d'alcool est dangereux pour la sant?, et tout ?a - soft beverages also available on request) Nothing constructive to propose of course. Shear ranting :-) Even Le 01/04/2026 ? 01:24, Nyall Dawson via QGIS-Developer a ?crit?: > Hi list, > > I'd like to float an idea for discussion: that we explicitly block all > AI based contributions from non-core developers. > > As background, currently we have the "human in the loop" policy in > place regarding AI contributions (see > https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md > ). This policy was already locked in, with the feeling that it was a > good first step that we could later refine and build upon. > > I've been giving this a lot of thought, and I personally now think > that we need to further tighten our AI policy. To be clear upfront, I > am not approaching this from societal or environmental > perspectives,?but rather from my own direct experience with using and > testing these tools. In my direct experience, regardless of the tool > used (including Claude, gemini, etc), the results are NOT reliable in > all situations. There's still massive amounts of hallucinations, > missteps, convoluted?and unstable code generated. > > Yes, in the *right hands* these tools can be a time saver. But to do > this safely you *have* to have a thorough understanding of the code > you're working on. And that doesn't mean just understanding the small > piece of the code that you're feeding into the tool, but rather a wide > understanding of the WHOLE codebase and architecture. > > QGIS isn't some little toy hobby project that's appropriate for people > to learn open-source, git, vibe coding, or to build their personal > portfolio from. It's a *professional tool* which is used for real > world applications, and those applications potentially impact projects > with million $$ budgets, or with potential risk to human life and > safety. That's not hyperbole -- it's exactly what GIS is for! > > So, as a practical way to protect the QGIS application and its users, > I think we could refine our AI policy to be "contributions using AI > tools for development are banned for all non-core contributors". > > By wording things this way, we don't explicitly prevent AI driven > development from all contributors. Rather we limit it to the subset of > contributors who we've formally recognised as having an extensive > understanding of QGIS code, architectural design and development > practices. These contributors are those who *do* have the skills > required to critically analyse the output of LLMs and guide them when > the results they give are unsuitable. > > I fully admit that this isn't a perfect policy. But I can't think of > any other practical way to differentiate AI developed contributions > which HAVE been critically assessed vs someone just slopping together > a fix for their immediate needs. It would be a ridiculously huge > burden and responsibility on the overworked review team to expect them > to do this at review time ?. > > Soo.... before I try to propose it as a formal revision to QEP 408, > what's everyones thoughts on this? Does anyone have any alternative > policy ideas to propose? > > Nyall > > > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://www.spatialys.com My software is free, but my time generally not. From delazj at gmail.com Fri Apr 10 23:14:19 2026 From: delazj at gmail.com (DelazJ) Date: Sat, 11 Apr 2026 08:14:19 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: Hi, I'd like to sidestep a bit and actually comment on the project being welcoming or not. As Alexander explained earlier, there are many efforts and many resources out there to help anyone onboard and contribute (code?) to QGIS. This is true. But easiness is a matter of experience. For someone that made it the hard way, things may look easier today. For someone that is beginning, there still may be difficulties that we no longer see because we are already inside the circle. I've experienced this a few times in recent years, having to collaborate and share responsibilities in the docs repo. But being welcoming is not only a technical matter. It is also (and mainly?) about interaction, how we talk to each other, how we help each other, how we onboard new comers. In this thread, there have been concerns mentioned about the "Slop!" label not being welcoming. I don't know if that word has different meanings in English but the translation I am aware of is, at best not tasty, and generally offending for an intellectual production. Suggestion for relabeling and for a description have been made. Was there any action to improve the situation? None. The label is still there weeks later. The matter is not about whether you think it is not offending someone that just drops code from an AI; it is about whether it may offend someone that made some real efforts to contribute and use the AI as support (the same thing some core devs claimed they do). If there's a single person that can be offended, I'd say we must adapt our vocabulary. We are not interacting with machines. (Not yet). And as mentioned by some devs, that already happened to real and known people, not first time contributors, we encourage at French users meeting to open PR. So my question to core developers (or anyone that has rights on labels editing in the code repo) : what does it take to you to reword appropriately that label ? Let's keep being the most welcoming as possible! Kind regards, Harrissou Le 1 avril 2026 15:03:30 GMT+02:00, Stefanos Natsis via QGIS-Developer a ?crit?: >Hi all, > >I'm on the same page with Nyall on this one. While not perfect, a no AI >policy will improve the SnR of new PRs and that's important granted that we >already struggle with a queue of ~100 PRs! > >> QGIS already has a problem with welcoming new contributors, and a policy >giving more special rights to core contributors will only make the >situation worse. > >I strongly disagree with this opinion, especially before the inflow of AI >assisted PRs. It's actually quite the contrary, QGIS is so welcoming to new >contributors that we are starting to face issues with AI contributions! >Yes, sometimes PRs stay in the queue for too long, however reviews are >helpful and not dismissive. > >It is sane and healthy to not treat core contributors or seasoned veterans >the same as newcomers. Core contributors are by definition trusted so they >can use the 'risky' tools. This is not gatekeeping in the same way that it >is not gatekeeping to limit commit rights to core contributors only. We >could still adapt this to requiring a minimum of let's say 50 merged PRs >before AI tools are allowed. > >Of course, since this is not enforceable, practically anyone can still use >AI tools to review his code, or even generate new code and we won't know, >and that will be OK, as long as the code is good! >Overall SnR will be improved though, as anyone wanting to contribute will >need to put more effort into it. > >Best >Stefanos > >On Wed, 1 Apr 2026 at 14:47, Greg Troxel via QGIS-Developer < >qgis-developer at lists.osgeo.org> wrote: > >> I should be clear that really I lean to "no AI contributions, at least >> for now" - the legal situation is unsettled, as is the social situation, >> and declining to engage while others figure it out seems best. >> >> What I really meant is that compared to where we are now, restricting >> contributions to those with a track record and human relationships is a >> positive incremental step. However, I see the lack of equal treatment >> as a a bug. >> >> >> As for concern about new contributors and what amounts to "the kids >> these days just want to vibe code and if we aren't ok with that they >> won't play with us", I think that's ok to defer worrying about. If >> that's really how it is, the Free Software world has much bigger >> problems well beyond the scope of any one project. >> >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at opengis.ch Sat Apr 11 00:17:58 2026 From: matthias at opengis.ch (Matthias Kuhn) Date: Sat, 11 Apr 2026 09:17:58 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: Hi Harrissou, I fully support a renaming for the reasons given in your mail. I do not think appearing dismissive will help to offer an increased protection from low quality AI contributions but will have an effect on potential sustainable contributors. Kind regards Matthias On Sat, Apr 11, 2026 at 8:14?AM DelazJ via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi, > I'd like to sidestep a bit and actually comment on the project being > welcoming or not. > As Alexander explained earlier, there are many efforts and many resources > out there to help anyone onboard and contribute (code?) to QGIS. This is > true. But easiness is a matter of experience. For someone that made it the > hard way, things may look easier today. For someone that is beginning, > there still may be difficulties that we no longer see because we are > already inside the circle. I've experienced this a few times in recent > years, having to collaborate and share responsibilities in the docs repo. > > But being welcoming is not only a technical matter. It is also (and > mainly?) about interaction, how we talk to each other, how we help each > other, how we onboard new comers. > In this thread, there have been concerns mentioned about the "Slop!" label > not being welcoming. I don't know if that word has different meanings in > English but the translation I am aware of is, at best not tasty, and > generally offending for an intellectual production. Suggestion for > relabeling and for a description have been made. Was there any action to > improve the situation? None. The label is still there weeks later. The > matter is not about whether you think it is not offending someone that just > drops code from an AI; it is about whether it may offend someone that made > some real efforts to contribute and use the AI as support (the same thing > some core devs claimed they do). If there's a single person that can be > offended, I'd say we must adapt our vocabulary. We are not interacting with > machines. (Not yet). And as mentioned by some devs, that already happened > to real and known people, not first time contributors, we encourage at > French users meeting to open PR. > > So my question to core developers (or anyone that has rights on labels > editing in the code repo) : what does it take to you to reword > appropriately that label ? > > Let's keep being the most welcoming as possible! > > Kind regards, > Harrissou > > > Le 1 avril 2026 15:03:30 GMT+02:00, Stefanos Natsis via QGIS-Developer < > qgis-developer at lists.osgeo.org> a ?crit : > >> Hi all, >> >> I'm on the same page with Nyall on this one. While not perfect, a no AI >> policy will improve the SnR of new PRs and that's important granted that we >> already struggle with a queue of ~100 PRs! >> >> > QGIS already has a problem with welcoming new contributors, and a >> policy giving more special rights to core contributors will only make the >> situation worse. >> >> I strongly disagree with this opinion, especially before the inflow of AI >> assisted PRs. It's actually quite the contrary, QGIS is so welcoming to new >> contributors that we are starting to face issues with AI contributions! >> Yes, sometimes PRs stay in the queue for too long, however reviews are >> helpful and not dismissive. >> >> It is sane and healthy to not treat core contributors or seasoned >> veterans the same as newcomers. Core contributors are by definition trusted >> so they can use the 'risky' tools. This is not gatekeeping in the same way >> that it is not gatekeeping to limit commit rights to core contributors >> only. We could still adapt this to requiring a minimum of let's say 50 >> merged PRs before AI tools are allowed. >> >> Of course, since this is not enforceable, practically anyone can still >> use AI tools to review his code, or even generate new code and we won't >> know, and that will be OK, as long as the code is good! >> Overall SnR will be improved though, as anyone wanting to contribute will >> need to put more effort into it. >> >> Best >> Stefanos >> >> On Wed, 1 Apr 2026 at 14:47, Greg Troxel via QGIS-Developer < >> qgis-developer at lists.osgeo.org> wrote: >> >>> I should be clear that really I lean to "no AI contributions, at least >>> for now" - the legal situation is unsettled, as is the social situation, >>> and declining to engage while others figure it out seems best. >>> >>> What I really meant is that compared to where we are now, restricting >>> contributions to those with a track record and human relationships is a >>> positive incremental step. However, I see the lack of equal treatment >>> as a a bug. >>> >>> >>> As for concern about new contributors and what amounts to "the kids >>> these days just want to vibe code and if we aren't ok with that they >>> won't play with us", I think that's ok to defer worrying about. If >>> that's really how it is, the Free Software world has much bigger >>> problems well beyond the scope of any one project. >>> >>> _______________________________________________ >>> QGIS-Developer mailing list >>> QGIS-Developer at lists.osgeo.org >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Sat Apr 11 01:20:36 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Sat, 11 Apr 2026 18:20:36 +1000 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: On Sat, 11 Apr 2026 at 16:15, DelazJ via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi, > I'd like to sidestep a bit and actually comment on the project being > welcoming or not. > As Alexander explained earlier, there are many efforts and many resources > out there to help anyone onboard and contribute (code?) to QGIS. This is > true. But easiness is a matter of experience. For someone that made it the > hard way, things may look easier today. For someone that is beginning, > there still may be difficulties that we no longer see because we are > already inside the circle. I've experienced this a few times in recent > years, having to collaborate and share responsibilities in the docs repo. > > But being welcoming is not only a technical matter. It is also (and > mainly?) about interaction, how we talk to each other, how we help each > other, how we onboard new comers. > In this thread, there have been concerns mentioned about the "Slop!" label > not being welcoming. I don't know if that word has different meanings in > English but the translation I am aware of is, at best not tasty, and > generally offending for an intellectual production. Suggestion for > relabeling and for a description have been made. Was there any action to > improve the situation? None. The label is still there weeks later. The > matter is not about whether you think it is not offending someone that just > drops code from an AI; it is about whether it may offend someone that made > some real efforts to contribute and use the AI as support (the same thing > some core devs claimed they do). If there's a single person that can be > offended, I'd say we must adapt our vocabulary. We are not interacting with > machines. (Not yet). And as mentioned by some devs, that already happened > to real and known people, not first time contributors, we encourage at > French users meeting to open PR. > > So my question to core developers (or anyone that has rights on labels > editing in the code repo) : what does it take to you to reword > appropriately that label ? > Advance warning: Emotional reply. Why, as a society, can we recognise that it's generally a BAD THING that AI has destroyed the livelihoods of graphic artists and musicians, but are BLIND to the impact it is having on professional software developers? Why MUST we be welcoming and warm to the people who are vandalising OUR form of art, and making it impossible for us to continue in the industry that we've devoted our lives to? I'm sorry, but I have absolutely NO sympathy for a new ai-slop contributor to open source. Just like I have no sympathy toward someone flooding spotify with AI written music, making it impossible for real artists to make a living. Screw that. It's already thankless enough to be an open source maintainer. Now it's even worse. Look after the people who have devoted YEARS of their lives to open source, or you'll lose those. /me out Nyall > > Let's keep being the most welcoming as possible! > > Kind regards, > Harrissou > > > Le 1 avril 2026 15:03:30 GMT+02:00, Stefanos Natsis via QGIS-Developer < > qgis-developer at lists.osgeo.org> a ?crit : > >> Hi all, >> >> I'm on the same page with Nyall on this one. While not perfect, a no AI >> policy will improve the SnR of new PRs and that's important granted that we >> already struggle with a queue of ~100 PRs! >> >> > QGIS already has a problem with welcoming new contributors, and a >> policy giving more special rights to core contributors will only make the >> situation worse. >> >> I strongly disagree with this opinion, especially before the inflow of AI >> assisted PRs. It's actually quite the contrary, QGIS is so welcoming to new >> contributors that we are starting to face issues with AI contributions! >> Yes, sometimes PRs stay in the queue for too long, however reviews are >> helpful and not dismissive. >> >> It is sane and healthy to not treat core contributors or seasoned >> veterans the same as newcomers. Core contributors are by definition trusted >> so they can use the 'risky' tools. This is not gatekeeping in the same way >> that it is not gatekeeping to limit commit rights to core contributors >> only. We could still adapt this to requiring a minimum of let's say 50 >> merged PRs before AI tools are allowed. >> >> Of course, since this is not enforceable, practically anyone can still >> use AI tools to review his code, or even generate new code and we won't >> know, and that will be OK, as long as the code is good! >> Overall SnR will be improved though, as anyone wanting to contribute will >> need to put more effort into it. >> >> Best >> Stefanos >> >> On Wed, 1 Apr 2026 at 14:47, Greg Troxel via QGIS-Developer < >> qgis-developer at lists.osgeo.org> wrote: >> >>> I should be clear that really I lean to "no AI contributions, at least >>> for now" - the legal situation is unsettled, as is the social situation, >>> and declining to engage while others figure it out seems best. >>> >>> What I really meant is that compared to where we are now, restricting >>> contributions to those with a track record and human relationships is a >>> positive incremental step. However, I see the lack of equal treatment >>> as a a bug. >>> >>> >>> As for concern about new contributors and what amounts to "the kids >>> these days just want to vibe code and if we aren't ok with that they >>> won't play with us", I think that's ok to defer worrying about. If >>> that's really how it is, the Free Software world has much bigger >>> problems well beyond the scope of any one project. >>> >>> _______________________________________________ >>> QGIS-Developer mailing list >>> QGIS-Developer at lists.osgeo.org >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From royroge at outlook.com Sat Apr 11 01:39:20 2026 From: royroge at outlook.com (Roy) Date: Sat, 11 Apr 2026 10:39:20 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: On Sat, 2026-04-11 at 18:20 +1000, Nyall Dawson via QGIS-Developer wrote: > > > > Advance warning: Emotional reply. > > Why, as a society, can we recognise that it's generally a BAD THING > that AI has destroyed the livelihoods of graphic artists and > musicians, but are BLIND to the impact it is having on professional > software developers? Why MUST we be welcoming and warm to the people > who are vandalising OUR form of art, and making it impossible for us > to continue in the industry that we've devoted our lives to?? > > I'm sorry, but I have absolutely NO sympathy for a new ai-slop > contributor to open source. Just like I have no sympathy toward > someone flooding spotify with AI written music, making it impossible > for real artists to make a living. > > Screw that. It's already thankless enough to be an open source > maintainer. Now it's even worse. > > Look after the people who have devoted YEARS of their lives to open > source, or you'll lose those. > > /me out > I understand what you?re saying. I?m just a regular user, but I truly appreciate your work and I agree with you completely. Thank you again, Nyall. From even.rouault at spatialys.com Sat Apr 11 04:28:28 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 11 Apr 2026 13:28:28 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: <0a67dda6-438a-43d6-8f44-bd145e933518@spatialys.com> I've renamed to more neutral "AI assisted", with comment "AI assisted coding involved. Review with extreme scepticism" Le 11/04/2026 ? 08:14, DelazJ via QGIS-Developer a ?crit?: > Hi, > I'd like to sidestep a bit and actually comment on the project being > welcoming or not. > As Alexander explained earlier, there are many efforts and many > resources out there to help anyone onboard and contribute (code?) to > QGIS. This is true. But easiness is a matter of experience. For > someone that made it the hard way, things may look easier today. For > someone that is beginning, there still may be difficulties that we no > longer see because we are already inside the circle. I've experienced > this a few times in recent years, having to collaborate and share > responsibilities in the docs repo. > > But being welcoming is not only a technical matter. It is also (and > mainly?) about interaction, how we talk to each other, how we help > each other, how we onboard new comers. > In this thread, there have been concerns mentioned about the "Slop!" > label not being welcoming. I don't know if that word has different > meanings in English but the translation I am aware of is, at best not > tasty, and generally offending for an intellectual production. > Suggestion for relabeling and for a description have been made. Was > there any action to improve the situation? None. The label is still > there weeks later. The matter is not about whether you think it is not > offending someone that just drops code from an AI; it is about whether > it may offend someone that made some real efforts to contribute and > use the AI as support (the same thing some core devs claimed they do). > If there's a single person that can be offended, I'd say we must adapt > our vocabulary. We are not interacting with machines. (Not yet). And > as mentioned by some devs, that already happened to real and known > people, not first time contributors, we encourage at French users > meeting to open PR. > > So my question to core developers (or anyone that has rights on labels > editing in the code repo) : what does it take to you to reword > appropriately that label ? > > Let's keep being the most welcoming as possible! > > Kind regards, > Harrissou > > > Le 1 avril 2026 15:03:30 GMT+02:00, Stefanos Natsis via QGIS-Developer > a ?crit?: > > Hi all, > > I'm on the same page with Nyall on this one. While not perfect, a > no AI policy will improve the SnR of new PRs and that's important > granted that we already struggle with a queue of ~100 PRs! > > >?QGIS already has a problem with welcoming new contributors, and > a policy giving more special rights to core contributors will only > make the situation worse. > > I strongly disagree with this opinion, especially before the > inflow of AI assisted PRs. It's actually quite the contrary, QGIS > is so welcoming to new contributors that we are starting to face > issues with AI contributions! Yes, sometimes PRs stay in the queue > for too long, however reviews are helpful and not dismissive. > > It is sane and healthy to not treat core contributors or seasoned > veterans the same as newcomers. Core contributors are by > definition trusted so they can use the 'risky' tools. This is not > gatekeeping in the same way that it is not gatekeeping to limit > commit rights to core contributors only. We could still adapt this > to requiring a minimum of let's say 50 merged PRs before AI tools > are allowed. > > Of course, since this is not enforceable, practically anyone can > still use AI tools to review his code, or even generate new code > and we won't know, and that will be OK, as long as the code is good! > Overall SnR will be improved though, as anyone wanting to > contribute will need to put more effort into it. > > Best > Stefanos > > On Wed, 1 Apr 2026 at 14:47, Greg Troxel via QGIS-Developer > wrote: > > I should be clear that really I lean to "no AI contributions, > at least > for now" - the legal situation is unsettled, as is the social > situation, > and declining to engage while others figure it out seems best. > > What I really meant is that compared to where we are now, > restricting > contributions to those with a track record and human > relationships is a > positive incremental step.? However, I see the lack of equal > treatment > as a a bug. > > > As for concern about new contributors and what amounts to "the > kids > these days just want to vibe code and if we aren't ok with > that they > won't play with us", I think that's ok to defer worrying > about.? If > that's really how it is, the Free Software world has much bigger > problems well beyond the scope of any one project. > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: > https://lists.osgeo.org/mailman/listinfo/qgis-developer > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Sat Apr 11 12:08:36 2026 From: gdt at lexort.com (Greg Troxel) Date: Sat, 11 Apr 2026 15:08:36 -0400 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: (Nyall Dawson's message of "Sat, 11 Apr 2026 18:20:36 +1000") References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: Nyall Dawson writes: > Advance warning: Emotional reply. > > Why, as a society, can we recognise that it's generally a BAD THING that AI > has destroyed the livelihoods of graphic artists and musicians, but are > BLIND to the impact it is having on professional software developers? Why > MUST we be welcoming and warm to the people who are vandalising OUR form of > art, and making it impossible for us to continue in the industry that we've > devoted our lives to? > > I'm sorry, but I have absolutely NO sympathy for a new ai-slop contributor > to open source. Just like I have no sympathy toward someone flooding > spotify with AI written music, making it impossible for real artists to > make a living. > > Screw that. It's already thankless enough to be an open source maintainer. > Now it's even worse. > > Look after the people who have devoted YEARS of their lives to open source, > or you'll lose those. > > /me out > > Nyall Before I saw your reply, I was going to comment that the "it's unkind to label low-quality LLM-generated content as AI slop" statement, while coming from a place of wanting to be welcoing, is missing the point that submitting low-qualitty LLM-generated content is an offense against the community. We would not be welcoming to people posting intentionally offensive comments (e.g., gratuitous off-topic racial epithets) to issues, and we wouldn't be talking about how it was unwelcoming to just delete them and ban the submitter. This is less different than people that think AI is ok think. It is possible that some people submitting AI slop don't undersetand that it is AI slop, and don't understand the harms that LLM-generated content does to projects. Once there's a clear place to point to -- which explains that the submitter should not again submit other LLM-generated content -- it might be better to just close with a pointer, rather than label AI and leave open. From anitagraser at gmx.at Sat Apr 11 13:42:01 2026 From: anitagraser at gmx.at (Anita Graser) Date: Sat, 11 Apr 2026 22:42:01 +0200 Subject: [QGIS-Developer] Call for Grant Proposals 2026 In-Reply-To: <93979807-2820-41c0-a57d-92803dc8f3e8@gmx.at> References: <93979807-2820-41c0-a57d-92803dc8f3e8@gmx.at> Message-ID: <43020982-903c-4e3f-9c0d-a0c83a9b2d8c@gmx.at> Dear all, This is a friendly reminder that the proposal phase ends on Monday. Regards, Anita On 2026-03-16 18:12, Anita Graser wrote: > Dear QGIS Community, > > Our previous rounds of grant proposals have been a great success. We > are very pleased to announce that this year?s round of grants is now > available. The call is open to anybody who wants to make a funded > contribution to QGIS, subject to the call conditions outlined in the > application form. The deadline for this round is on Monday 13 April. > > For more details, please read: > https://blog.qgis.org/2026/03/16/qgis-grants-11-call-for-grant-proposals-2026/ > > > We look forward to seeing all your great ideas for improving QGIS! > > Regards, > > Anita > > From matthias at opengis.ch Sun Apr 12 03:10:49 2026 From: matthias at opengis.ch (Matthias Kuhn) Date: Sun, 12 Apr 2026 12:10:49 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: Hi, There is no question that carelessly throwing low quality AI products into the PR queue for review is offensive. I am absolutely with you Nyall, that the current situation where so much less effort is required to produce content than to check for its quality is a bad situation for maintainers (as well as the other industries that you mentioned). However, there is no guarantee that only such pull requests are flagged. E.g. just from the disclaimer checkbox in the PR template, it is not possible to deduce if it's a careless low quality product. I've seen this checked for commit message proposals from github copilot. It's also often added without any discussion about the provenance with the contributor. I think it is okay to use a label like this, but then I think the formulation should be compatible with "in dubio pro reo". The new proposal by Even is not dismissive for pull requests that deserve a second look (such as apparently the two currently open pull requests with this label 65573 and 65630). For pull requests that clearly qualify as slop, I agree with Greg and we should rather close them sooner than later. Kind regards Matthias On Sat, Apr 11, 2026 at 9:08?PM Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Nyall Dawson writes: > > > Advance warning: Emotional reply. > > > > Why, as a society, can we recognise that it's generally a BAD THING that > AI > > has destroyed the livelihoods of graphic artists and musicians, but are > > BLIND to the impact it is having on professional software developers? Why > > MUST we be welcoming and warm to the people who are vandalising OUR form > of > > art, and making it impossible for us to continue in the industry that > we've > > devoted our lives to? > > > > I'm sorry, but I have absolutely NO sympathy for a new ai-slop > contributor > > to open source. Just like I have no sympathy toward someone flooding > > spotify with AI written music, making it impossible for real artists to > > make a living. > > > > Screw that. It's already thankless enough to be an open source > maintainer. > > Now it's even worse. > > > > Look after the people who have devoted YEARS of their lives to open > source, > > or you'll lose those. > > > > /me out > > > > Nyall > > Before I saw your reply, I was going to comment that the "it's unkind to > label low-quality LLM-generated content as AI slop" statement, while > coming from a place of wanting to be welcoing, is missing the point that > submitting low-qualitty LLM-generated content is an offense against the > community. We would not be welcoming to people posting intentionally > offensive comments (e.g., gratuitous off-topic racial epithets) to > issues, and we wouldn't be talking about how it was unwelcoming to just > delete them and ban the submitter. This is less different than people > that think AI is ok think. > > It is possible that some people submitting AI slop don't undersetand > that it is AI slop, and don't understand the harms that LLM-generated > content does to projects. Once there's a clear place to point to -- > which explains that the submitter should not again submit other > LLM-generated content -- it might be better to just close with a > pointer, rather than label AI and leave open. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From delazj at gmail.com Sun Apr 12 03:55:07 2026 From: delazj at gmail.com (DelazJ) Date: Sun, 12 Apr 2026 12:55:07 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: <0a67dda6-438a-43d6-8f44-bd145e933518@spatialys.com> References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> <0a67dda6-438a-43d6-8f44-bd145e933518@spatialys.com> Message-ID: Hi, Great. Much better indeed. Thanks, Even. Harrissou Le 11 avril 2026 13:28:28 GMT+02:00, Even Rouault a ?crit?: >I've renamed to more neutral "AI assisted", with comment "AI assisted coding involved. Review with extreme scepticism" > >Le 11/04/2026 ? 08:14, DelazJ via QGIS-Developer a ?crit?: >> Hi, >> I'd like to sidestep a bit and actually comment on the project being welcoming or not. >> As Alexander explained earlier, there are many efforts and many resources out there to help anyone onboard and contribute (code?) to QGIS. This is true. But easiness is a matter of experience. For someone that made it the hard way, things may look easier today. For someone that is beginning, there still may be difficulties that we no longer see because we are already inside the circle. I've experienced this a few times in recent years, having to collaborate and share responsibilities in the docs repo. >> >> But being welcoming is not only a technical matter. It is also (and mainly?) about interaction, how we talk to each other, how we help each other, how we onboard new comers. >> In this thread, there have been concerns mentioned about the "Slop!" label not being welcoming. I don't know if that word has different meanings in English but the translation I am aware of is, at best not tasty, and generally offending for an intellectual production. Suggestion for relabeling and for a description have been made. Was there any action to improve the situation? None. The label is still there weeks later. The matter is not about whether you think it is not offending someone that just drops code from an AI; it is about whether it may offend someone that made some real efforts to contribute and use the AI as support (the same thing some core devs claimed they do). If there's a single person that can be offended, I'd say we must adapt our vocabulary. We are not interacting with machines. (Not yet). And as mentioned by some devs, that already happened to real and known people, not first time contributors, we encourage at French users meeting to open PR. >> >> So my question to core developers (or anyone that has rights on labels editing in the code repo) : what does it take to you to reword appropriately that label ? >> >> Let's keep being the most welcoming as possible! >> >> Kind regards, >> Harrissou >> >> >> Le 1 avril 2026 15:03:30 GMT+02:00, Stefanos Natsis via QGIS-Developer a ?crit?: >> >> Hi all, >> >> I'm on the same page with Nyall on this one. While not perfect, a >> no AI policy will improve the SnR of new PRs and that's important >> granted that we already struggle with a queue of ~100 PRs! >> >> >?QGIS already has a problem with welcoming new contributors, and >> a policy giving more special rights to core contributors will only >> make the situation worse. >> >> I strongly disagree with this opinion, especially before the >> inflow of AI assisted PRs. It's actually quite the contrary, QGIS >> is so welcoming to new contributors that we are starting to face >> issues with AI contributions! Yes, sometimes PRs stay in the queue >> for too long, however reviews are helpful and not dismissive. >> >> It is sane and healthy to not treat core contributors or seasoned >> veterans the same as newcomers. Core contributors are by >> definition trusted so they can use the 'risky' tools. This is not >> gatekeeping in the same way that it is not gatekeeping to limit >> commit rights to core contributors only. We could still adapt this >> to requiring a minimum of let's say 50 merged PRs before AI tools >> are allowed. >> >> Of course, since this is not enforceable, practically anyone can >> still use AI tools to review his code, or even generate new code >> and we won't know, and that will be OK, as long as the code is good! >> Overall SnR will be improved though, as anyone wanting to >> contribute will need to put more effort into it. >> >> Best >> Stefanos >> >> On Wed, 1 Apr 2026 at 14:47, Greg Troxel via QGIS-Developer >> wrote: >> >> I should be clear that really I lean to "no AI contributions, >> at least >> for now" - the legal situation is unsettled, as is the social >> situation, >> and declining to engage while others figure it out seems best. >> >> What I really meant is that compared to where we are now, >> restricting >> contributions to those with a track record and human >> relationships is a >> positive incremental step.? However, I see the lack of equal >> treatment >> as a a bug. >> >> >> As for concern about new contributors and what amounts to "the >> kids >> these days just want to vibe code and if we aren't ok with >> that they >> won't play with us", I think that's ok to defer worrying >> about.? If >> that's really how it is, the Free Software world has much bigger >> problems well beyond the scope of any one project. >> >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: >> https://lists.osgeo.org/mailman/listinfo/qgis-developer >> >> >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer > >-- >http://www.spatialys.com >My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From delazj at gmail.com Sun Apr 12 04:25:46 2026 From: delazj at gmail.com (DelazJ) Date: Sun, 12 Apr 2026 13:25:46 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> Message-ID: <6DC49088-50F7-4293-9F35-3C8BA17D25E6@gmail.com> Hi again, Nyall, I'm sorry to see that my message touched a nerve. Sorry. I reread myself and am (un)fortunately unable to find what part of my message triggers that: - the technical aspect of welcoming was about making sure we provide correct and up-to-date materials e.g., it's regular that the install.md file is outdated. It was in no way a call to open doors for AI tools. - on the interaction part: I didn't mean we welcomed warmly any AI-based (attempt of) contribution either. My point was to avoid being unwelcoming with real potential contributors just because they used AI, something the repo guidelines allow them to do. A neutral label as Even updated it to seems a good start, and we can imagine applying the "slop!" one to the PRs that reveal to be of low-quality, allowing us to quickly close and ban the authors after a number of recurrence. Anyway, sorry for any misinterpretation my message would have led to. For the societal questions you raised, well, I don't think AI is a threat for professional developers only. It is a threat for a number of intellectual activities, a threat for most of us here, at different degrees for now. But who knows in 5 years...? E.g., I've been asked at the French Users meeting why we do not translate QGIS with AI. Translating QGIS is in no way my profession... Translation companies are dying, if not already dead. So yes I completely understand and share your concerns about AI risks and its "insane use" in our society. IMHO the threat takes more and more place if there are more and more AI users, regardless of them being beginner or expert in their domain; they feed the beast. Greg, there are two different things: people submitting low-quality AI generated code (and these are problems we need to solve quickly), and people understanding what they do and using AI to help them polish the work. I personally probably don't have skills to judge who belongs to which group but this could be a first step of review; I'll leave that to others. My key point as explained above is that, as long as we allow (for good or bad reasons?) AI assisted PR, the second group does not violate our rules, so we have to be welcoming with them. That's all. Kind regards, Harrissou Le 11 avril 2026 21:08:36 GMT+02:00, Greg Troxel a ?crit?: >Nyall Dawson writes: > >> Advance warning: Emotional reply. >> >> Why, as a society, can we recognise that it's generally a BAD THING that AI >> has destroyed the livelihoods of graphic artists and musicians, but are >> BLIND to the impact it is having on professional software developers? Why >> MUST we be welcoming and warm to the people who are vandalising OUR form of >> art, and making it impossible for us to continue in the industry that we've >> devoted our lives to? >> >> I'm sorry, but I have absolutely NO sympathy for a new ai-slop contributor >> to open source. Just like I have no sympathy toward someone flooding >> spotify with AI written music, making it impossible for real artists to >> make a living. >> >> Screw that. It's already thankless enough to be an open source maintainer. >> Now it's even worse. >> >> Look after the people who have devoted YEARS of their lives to open source, >> or you'll lose those. >> >> /me out >> >> Nyall > >Before I saw your reply, I was going to comment that the "it's unkind to >label low-quality LLM-generated content as AI slop" statement, while >coming from a place of wanting to be welcoing, is missing the point that >submitting low-qualitty LLM-generated content is an offense against the >community. We would not be welcoming to people posting intentionally >offensive comments (e.g., gratuitous off-topic racial epithets) to >issues, and we wouldn't be talking about how it was unwelcoming to just >delete them and ban the submitter. This is less different than people >that think AI is ok think. > >It is possible that some people submitting AI slop don't undersetand >that it is AI slop, and don't understand the harms that LLM-generated >content does to projects. Once there's a clear place to point to -- >which explains that the submitter should not again submit other >LLM-generated content -- it might be better to just close with a >pointer, rather than label AI and leave open. -------------- next part -------------- An HTML attachment was scrubbed... URL: From regis.haubourg at gmail.com Sun Apr 12 09:51:05 2026 From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=) Date: Sun, 12 Apr 2026 18:51:05 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: <6DC49088-50F7-4293-9F35-3C8BA17D25E6@gmail.com> References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> <6DC49088-50F7-4293-9F35-3C8BA17D25E6@gmail.com> Message-ID: <38d78b50-b422-422b-bd1f-90acad0fbade@gmail.com> Hi Harrissou and all, Bien cordialement, R?gis Haubourg On 12/04/2026 13:25, DelazJ via QGIS-Developer wrote: > Hi again, > > Nyall, I'm sorry to see that my message touched a nerve. Sorry. I > reread myself and am (un)fortunately unable to find what part of my > message triggers that: > - the technical aspect of welcoming was about making sure we provide > correct and up-to-date materials e.g., it's regular that the > install.md file is outdated. It was in no way a call to open doors for > AI tools. > - on the interaction part: I didn't mean we welcomed warmly any > AI-based (attempt of) contribution either. My point was to avoid being > unwelcoming with real potential contributors just because they used > AI, something the repo guidelines allow them to do. A neutral label as > Even updated it to seems a good start, and we can imagine applying the > "slop!" one to the PRs that reveal to be of low-quality, allowing us > to quickly close and ban the authors after a number of recurrence. The topic of open source future in AI's world worries a lot of us. QGIS is both a professional tool, but also a passion for many of us and I'm happy that emotions and feelings about AI mis-uses impacts generate debates. Thanks all for keeping constructive and peaceful like you do. That is why I love this community. > > Anyway, sorry for any misinterpretation my message would have led to. > > > Greg, there are two different things: people submitting low-quality AI > generated code (and these are problems we need to solve quickly), and > people understanding what they do and using AI to help them polish the > work. I personally probably don't have skills to judge who belongs to > which group but this could be a first step of review; I'll leave that > to others. My key point as explained above is that, as long as we > allow (for good or bad reasons?) AI assisted PR, the second group does > not violate our rules, so we have to be welcoming with them. That's all. One key point here. It is really **hard** to decrypt the quality of LLM generated code, because it is trained to be plausible. ?Knowing this, a friendly contributor, willing to getting involved in the long term, and who will use AI as a helper for its first contributions, should know that it will put a very high charge on reviewers. So this is like a poisoned gift. My personal view is that contributors should take care of showing they are human, by describing their real motivations, plans for the future. Any purely technical PR, launched from an anonymous account, out of the blue, was already a not-so-good practice. In AI era, this is a very bad practice and I agree this is already "AI-slop". A presentation message on the developer's list and some context in the PR is the bare minimum to me. ?We're collaborating with each other. We appreciate meeting in contributor's events from time to time. We also like the project and like to take pleasure in doing good work, event when paid for not-so-fun tasks. This idea of being part of a community is our real strength. Let's make it clear that using AI is one tool only, it does not replace human relations. > > Kind regards, > Harrissou > > > Le 11 avril 2026 21:08:36 GMT+02:00, Greg Troxel a > ?crit?: > > Nyall Dawson writes: > > Advance warning: Emotional reply. Why, as a society, can we > recognise that it's generally a BAD THING that AI has > destroyed the livelihoods of graphic artists and musicians, > but are BLIND to the impact it is having on professional > software developers? Why MUST we be welcoming and warm to the > people who are vandalising OUR form of art, and making it > impossible for us to continue in the industry that we've > devoted our lives to? I'm sorry, but I have absolutely NO > sympathy for a new ai-slop contributor to open source. Just > like I have no sympathy toward someone flooding spotify with > AI written music, making it impossible for real artists to > make a living. Screw that. It's already thankless enough to be > an open source maintainer. Now it's even worse. Look after the > people who have devoted YEARS of their lives to open source, > or you'll lose those. /me out Nyall > > Before I saw your reply, I was going to comment that the "it's > unkind to label low-quality LLM-generated content as AI slop" > statement, while coming from a place of wanting to be welcoing, is > missing the point that submitting low-qualitty LLM-generated > content is an offense against the community. We would not be > welcoming to people posting intentionally offensive comments > (e.g., gratuitous off-topic racial epithets) to issues, and we > wouldn't be talking about how it was unwelcoming to just delete > them and ban the submitter. This is less different than people > that think AI is ok think. It is possible that some people > submitting AI slop don't undersetand that it is AI slop, and don't > understand the harms that LLM-generated content does to projects. > Once there's a clear place to point to -- which explains that the > submitter should not again submit other LLM-generated content -- > it might be better to just close with a pointer, rather than label > AI and leave open. > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Sun Apr 12 12:02:27 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 12 Apr 2026 15:02:27 -0400 Subject: [QGIS-Developer] [Qgis-user] Announcing QEP 419: Improved Wayland compatibility In-Reply-To: (Nyall Dawson via's message of "Fri, 10 Apr 2026 12:18:09 +1000") References: Message-ID: Nyall Dawson via QGIS-User writes: > Over the last couple of years, most Linux distributions and desktop > environments have been transitioning from the legacy X11 display server to > the Wayland standard. The transition has reached a stage where many > environments are now completely dropping support for the X11 server. I think it's entirely appropriate for qgis to work better on wayland because users have computers that are wayland and not X11. But I think we should refrain from buying into and repeating wayland propaganda. I almost always object to the word "legacy"; it means "the standard thing that people do now, because I have declared some shiny new thing to be the way of the future". My impression is that pro-wayland people are trying to remove X11 not because that removal serves users, but because it's aligned with a decision that they want wayland to be the only way. So I'd rewrite Many GNU/Linux distributions have added Wayland as a display server, and some are de-supporting X11. While qgis does not take a position on this, we would like qgis to work well in a Wayland environment, as well as continue to work well in an X11 environment. which refrains from endorsing any particular display server approach. > QEP 419 aims to address these limitations in the "best possible" way, given > the (many!) constraints of Wayland. This is a very telling comment. It suggests that this is the usual situation where proponents of ${SHINY_NEW_THING} are wanting others to overlook that it fails to do some of the things that ${LONGSTANDING_USEFUL_THING} does. Again, off topic for qgis to judge. From even.rouault at spatialys.com Sun Apr 12 12:38:04 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 12 Apr 2026 21:38:04 +0200 Subject: [QGIS-Developer] Floating an idea: ban AI based contributed from non-core developers? In-Reply-To: <38d78b50-b422-422b-bd1f-90acad0fbade@gmail.com> References: <8a860d30-e873-49ee-8787-a03c225fef85@oslandia.com> <6DC49088-50F7-4293-9F35-3C8BA17D25E6@gmail.com> <38d78b50-b422-422b-bd1f-90acad0fbade@gmail.com> Message-ID: > One key point here. It is really **hard** to decrypt the quality of > LLM generated code, because it is trained to be plausible. > I triple on that. I've always found that (in depth) reviewing was a task consuming a lot of mental energy, often more than coding, but in pre-LLM times, you knew that the contributor had already invested a lot of energy into creating their submission, so that made your own energy investment acceptable. Now, the reviewer is mostly the only one that sweats.? When you make comments and get a reply, you never know if the reply comes from the human, the machine or a mix of them. This is really really really unpleasant.? In our highly decentralized community, the lack of direct interaction pre-LLM could also be a challenge (mechanisms behind the working of human psychology have been forged by natural selection over ~ 3 million years of face-to-face interactions, add tens of extra millions years inherited from our closest cousins in the animal reign, compared to hardly 50 years of digital communication), but at least you knew that at @someone was a peer.? Now you don't know anymore. You're becoming effectively the slave of an agent. Among the things I dislike is the wall'o'text LLM generated PR descriptions. I believe we should ban them and require contributors to come with their own succinct and to-the-point descriptions. Or if they can't come up with one, just none. That makes at least less stuff to review!? But then the "human in the loop" policy no longer works. Maybe we should charge a symbolic fee to new contributors for each PR they submit, until one is accepted? I bet this would make them think twice. Unfortunately that's not a github feature. > ?Knowing this, a friendly contributor, willing to getting involved in > the long term, and who will use AI as a helper for its first > contributions, should know that it will put a very high charge on > reviewers. So this is like a poisoned gift. > One difficulty is that it is likely really hard for someone not having already experienced themselves reviewing LLM generated PRs to know how it feels to deal with them. Writing all the above with https://github.com/qgis/QGIS/pull/65778 in mind. Took me maybe one hour of digging (yes not fast but CMake is full of subtelties) to realize that there is (likely) a much simpler fix than the one suggested (I may be wrong, let's see what the bot answers). I believe that 6 months ago I would have approved the exact same PR content without much thinking. So one could argue that the extra skepticism when confronting to LLM generated PR is a good thing, but frankly it is exhausting. I believe there's a new job lurking: "mental coach/psychologist for developers dealing with LLM contributions" -- http://www.spatialys.com My software is free, but my time generally not. From nyall.dawson at gmail.com Sun Apr 12 15:57:11 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Mon, 13 Apr 2026 08:57:11 +1000 Subject: [QGIS-Developer] [Qgis-user] Announcing QEP 419: Improved Wayland compatibility In-Reply-To: References: Message-ID: On Fri, 10 Apr 2026 at 14:55, Andreas Neumann wrote: > > Hi Nyall, > > Thank you for this initiative. Sounds useful to me. > > As a reminder: we still have a significant number of consulting/development hours at KDAB available to support such an effort, if it is useful to reach the goal. Good point! I've added a note accordingly to the QEP. (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/376/changes/22eb9d4e7) Nyall > > Greetings, > Andreas > > On Fri, 10 Apr 2026 at 04:18, Nyall Dawson via QGIS-User wrote: >> >> Over the last couple of years, most Linux distributions and desktop environments have been transitioning from the legacy X11 display server to the Wayland standard. The transition has reached a stage where many environments are now completely dropping support for the X11 server. >> >> This presents a challenge to Linux QGIS users, as the current QGIS versions have limitations and bugs when run in a Wayland environment. >> >> QEP 419 aims to address these limitations in the "best possible" way, given the (many!) constraints of Wayland. >> >> Please see full details of the proposal at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/376. Discussion and comments welcome! >> >> This QEP will be submitted as part of the QGIS.org grant program >> >> Nyall >> >> _______________________________________________ >> QGIS-User mailing list >> QGIS-User at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > > > > -- > > -- > Andreas Neumann > QGIS.ORG board member (treasurer) From nyall.dawson at gmail.com Sun Apr 12 16:01:00 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Mon, 13 Apr 2026 09:01:00 +1000 Subject: [QGIS-Developer] [Qgis-user] Announcing QEP 419: Improved Wayland compatibility In-Reply-To: References: Message-ID: On Mon, 13 Apr 2026 at 05:02, Greg Troxel via QGIS-User < qgis-user at lists.osgeo.org> wrote: > > Nyall Dawson via QGIS-User writes: > > > Over the last couple of years, most Linux distributions and desktop > > environments have been transitioning from the legacy X11 display server to > > the Wayland standard. The transition has reached a stage where many > > environments are now completely dropping support for the X11 server. > > I think it's entirely appropriate for qgis to work better on wayland > because users have computers that are wayland and not X11. But I think > we should refrain from buying into and repeating wayland propaganda. Heh. I'm certainly not a Wayland fanboy. You could probably read between the lines in my proposal to see that I'm also frustrated by the decisions made by Wayland designers. My first draft of the QEP was quite a bit more opinionated, before I decided I'd better tone it down ? FWIW, https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/ is quite a good write-up and also very relevant to the Wayland shortcomings affecting QGIS. Their conclusion is very apt: "We try to be pragmatic. We support what works, we document what doesn?t, and we focus our development efforts where they?ll have most benefit for our users. We will adjust our position as Wayland improves, but we won?t compromise the reliability and functionality of KiCad." We could just directly copy/paste that and replace KiCad with QGIS Nyall > > I almost always object to the word "legacy"; it means "the standard > thing that people do now, because I have declared some shiny new thing > to be the way of the future". > > My impression is that pro-wayland people are trying to remove X11 not > because that removal serves users, but because it's aligned with a > decision that they want wayland to be the only way. > > So I'd rewrite > > Many GNU/Linux distributions have added Wayland as a display server, > and some are de-supporting X11. While qgis does not take a position > on this, we would like qgis to work well in a Wayland environment, > as well as continue to work well in an X11 environment. > > which refrains from endorsing any particular display server approach. > > > QEP 419 aims to address these limitations in the "best possible" way, given > > the (many!) constraints of Wayland. > > This is a very telling comment. It suggests that this is the usual > situation where proponents of ${SHINY_NEW_THING} are wanting others to > overlook that it fails to do some of the things that > ${LONGSTANDING_USEFUL_THING} does. Again, off topic for qgis to judge. > > _______________________________________________ > QGIS-User mailing list > QGIS-User at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user -------------- next part -------------- An HTML attachment was scrubbed... URL: