From rhurlin at gwdg.de  Mon Jun  1 11:24:35 2026
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Mon, 1 Jun 2026 20:24:35 +0200
Subject: [QGIS-Developer] SAGA GIS plugin maintenance
In-Reply-To: <4544a675-453f-428f-8445-40df04b22ed6@gwdg.de>
References: <CAHw6TZe0aFRhiGmtxs6ACG+EHM1TobrnhqvD8=OOo5DhTiyoyw@mail.gmail.com>
 <CAB28AsgnUm444vSZ6-e6y6VmnbkCkx5oBst+ZYGyFvVTZhKtiA@mail.gmail.com>
 <4544a675-453f-428f-8445-40df04b22ed6@gwdg.de>
Message-ID: <a61d2cdd-8d6f-447f-a858-92c4a6c2f867@gwdg.de>

Dear QGIS developers,
I had promised to get back to you after a meeting with our SAGA 
dev-team. I would like to do so here.

Am 25.05.26 um 18:25 schrieb Rainer Hurling via QGIS-Developer:
> Dear QGIS devs,
> I am writing to you on behalf of the small group of SAGA GIS developers.
> This thread has raised several points and perspectives that are of great 
> interest to us, and we would like to share the SAGA team?s perspective 
> on them.
> 
> However, before we contribute here, we would like to discuss this at our 
> regular developer meeting next Friday (May 29). We have already added 
> the topic to the agenda :)
> After that, we will post here in the thread and try to outline our options.
> 
> @Nyall: Could you please make the ?SAGA Processing Nextgen? plugin, 
> which is currently set to ?private?, public again for a while? I?d like 
> to fork it, thanks!
> 
> Best wishes,
> Rainer? (FreeBSD ports committer)


Since this thread concerns the ?Processing Saga NextGen Provider? 
plugin, it should be noted up front that this is a QGIS plugin developed 
by a QGIS developer. The SAGA team was never involved in its development.

We discussed the following in our SAGA meeting:

- Basically, we (at SAGA) have no interest in maintaining the existing 
plugin, further developing it, or even developing a new, more 
comprehensive SAGA plugin for QGIS.

- If there is interest within the QGIS community in developing a more 
comprehensive plugin for integrating SAGA, we recommend not building on 
the SAGA command-line tool ?saga_cmd? but instead using PySAGA (or the 
C++ API). This would allow the respective functionalities and parameters 
of all non-interactive SAGA tools to be used directly and 
comprehensively. It would also allow in-memory passing of datasets, i.e. 
no temporary files would need to be written.

- Converting all data types on a 1:1 basis is likely to remain a 
challenge. There are data types in SAGA that do not exist in QGIS.

- Overall, we are positive about the integration of SAGA in QGIS, but we 
think such a project needs a sustainable approach. If the QGIS community 
wishes to improve or update the integration of SAGA with QGIS, the SAGA 
team is happy to provide information and advice if requested. We would 
also be happy to establish or point to communication channels so that 
the community can stay informed about new SAGA versions and upcoming 
changes.


A personal note on the ?Processing Saga NextGen Provider? plugin: Since 
I am the maintainer (rhurlin at FreeBSD.org) of both the SAGA GIS port [1] 
and the QGIS port [2] for FreeBSD, I decided out of curiosity to copy 
the SAGA NextGen Provider plugin from a QGIS 3 installation to a QGIS 4 
installation and then run the ?scan_qt6_compat? v1.2 plugin by Fran?ois 
Thevand on the SAGA plugin in QGIS 4. This allowed the SAGA plugin to be 
converted to Qt6 and QGIS 4 fully automatically and seemingly without 
errors, and it can now be used in QGIS 4 as usual. Perhaps this is a way 
for the QGIS community to continue working with this plugin for the time 
being?

[1] https://www.freshports.org/math/saga
[2] https://www.freshports.org/graphics/qgis and
     https://www.freshports.org/graphics/qgis-ltr

Best regards,
Rainer


> Am 22.05.26 um 01:55 schrieb Nyall Dawson via QGIS-Developer:
>> On Thu, 21 May 2026 at 19:53, Stefano Campus via QGIS-Developer <qgis- 
>> developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>> wrote:
>>
>> ?> I?m writing to the dev list because I think this issue is of interest.
>> ?>
>> ?> For the past few days, the SAGA Next plugin?which allows you to use 
>> SAGA GIS modules within QGIS Processing?has been unavailable.
>>
>> Thanks for kicking off this discussion -- I've been waiting for 
>> someone to raise it???
>>
>> To explain the situation:
>>
>> I've been "maintaining" that plugin for years. That's an over- 
>> exaggeration... it hasn't received any love from me beyond reviewing a 
>> pull request once every couple of years. I initially forked it (SAGA 
>> NextGen) from the core SAGA plugin back in 2019 to help solve issues 
>> with SAGA availability of LTR releases and broken stable API. Then in 
>> 2019 https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230 
>> <https://github.com/qgis/QGIS-Enhancement-Proposals/issues/230> 
>> followed, when?the built-in SAGA plugin was removed and it went from 
>> being an out-of-the-box, "qgis.org <http://qgis.org> maintained" 
>> plugin to relying on the third party SAGA NextGen?"community 
>> maintained" plugin. That's 100% because it was concluded by all the 
>> developers responsible for that code that it wasn't up to the quality 
>> standards of the rest of QGIS.
>>
>> It was always a fragile mess of a plugin. Part of that was because of 
>> the difficulties associated with SAGA versioning, part of that was 
>> because it was initially forked from old python code that no-one had 
>> ever modernised. To say it was held together with chewing gum would be 
>> a lie... it was held together with some soggy wet toilet paper at 
>> best!???This really bugged me. I'd see constant user frustration 
>> because it never worked well, and IMO this user frustration was 
>> harming the reputation of QGIS itself. It didn't help that I'd keep 
>> reading blogs/guides/tutorials where people were recommending?using it 
>> for operations where QGIS native tools are SOOOO much better (eg 
>> vector operations like buffering).
>>
>> It was never my desire to become the maintainer of the plugin and put 
>> in the work required to bring it up to the quality standard I hold to, 
>> rather, I offered it on an initially voluntary basis to fix immediate 
>> issues I saw users were experiencing and with the hope that making it 
>> a third party plugin would help grow a healthy community that would 
>> take it over.
>>
>> That never happened... Instead it was just another burden that I 
>> carried for everyone, with the associated lack of thanks and lack of 
>> any recognition beyond angry emails when it didn't work.??. Ah well, 
>> that's just life as a QGIS developer, we all deal with that, and I'm 
>> thick- skinned enough to handle it!
>>
>> At least, I thought so. Then the AI apocalypse hit in 2026.
>>
>> As a response to my frustration with the lack of support the user 
>> community is giving to open-source developers during this INCREDIBLY 
>> challenging time, I decided to close off a bunch of my public 
>> repositories. Because, hey, I don't want to directly train the 
>> technologies that will likely destroy the whole economics behind open- 
>> source software development. So I closed off repositories for things 
>> I'd voluntarily made public, including dropping any QGIS plugin that I 
>> wasn't directly using myself anymore, and that wasn't funded or in use 
>> by my customers (or where a better native tool now exists). And that 
>> included the SAGA NextGen plugin. I have no use for it, and none of my 
>> customers use it, and it's a PITA to "maintain".
>>
>> I knew that by doing so I'd be stirring up trouble, and honestly, that 
>> was partly my intention! I wanted to force a discussion about this, 
>> and raise widespread attention to the issues that would otherwise go 
>> unnoticed. It's the SAGA plugin today, but tomorrow it could easily be 
>> QGIS itself, or GDAL, or PostGIS, or PDAL, or ...??
>>
>> My personal preference would be that we continue to port useful tools 
>> from SAGA to native QGIS versions of these tools. I've done this in 
>> the past (see https://github.com/qgis/QGIS/pull/53794 <https:// 
>> github.com/ qgis/QGIS/pull/53794>, https://github.com/qgis/QGIS/ 
>> pull/61722 <https:// github.com/qgis/QGIS/pull/61722>) for tools that 
>> I need myself, or that my customers rely on, and the QGIS native tools 
>> are so much better (***FOR QGIS USERS***) then calling out to the SAGA 
>> versions. They have full format support for all the data sources QGIS 
>> supports, they work with massive rasters without memory issues, and 
>> they are much faster as they don't require data conversion to 
>> intermediate formats. And on top of that, they "just work" everywhere 
>> QGIS works -- there's no fussing around with SAGA version 
>> compatibility, and no security risks with python code shelling out to 
>> run random batch files.
>>
>> (Please understand that I'm not insulting the SAGA developers or their 
>> versions of these tools here... in my experience the SAGA developer's 
>> logic is great, the code is well written and the algorithms themselves 
>> are well designed. It's a testament to the SAGA developers how easy it 
>> is to port the tools to QGIS, they are very readable and well 
>> documented. My point is that we offer a better experience to **QGIS** 
>> users by porting the tools to native equivalents using QGIS API 
>> directly).
>>
>> If anyone has particular SAGA tools they rely on for their work, then 
>> please reach out and I'll let you know how much it would cost to 
>> sponsor a port of that tool.
>>
>> Finally, please note that I didn't delete the plugin repository, I 
>> just made it private instead of public. I'm happy to temporarily make 
>> it public again if someone wants to fork it, but after they do that 
>> I'll then permanently erase my repo. If someone wants to do this then 
>> let me know and I'll re-open temporarily.
>>
>> Nyall
>>
>>
>> ?>
>> ?> According to reports in the QGIS community?s Telegram group, 
>> maintaining this plugin is becoming increasingly difficult due to 
>> developments in the SAGA project, which can cause the plugin to stop 
>> working.
>> ?>
>> ?> I recall that until a couple of years ago, SAGA was, like GRASS, a 
>> resource installed directly within QGIS, but then, precisely because 
>> of the difficulty in keeping up with SAGA?s developments, it was 
>> decided to treat SAGA as a third-party resource accessible via plugins.
>> ?>
>> ?> I believe it is right that this important resource should not be 
>> maintained on a voluntary basis by a single developer/user, but that 
>> it should be taken on by the community.
>> ?>
>> ?> Do you think it would be a good idea to propose to the Steering 
>> Group that its maintenance be taken on directly by the QGIS.org 
>> Foundation and that a certain sum (1000?2000 euros?) be set aside in 
>> the annual budget for its maintenance?
>> ?>
>> ?> Thank you
>> ?>
>> ?> stefano campus

From nyall.dawson at gmail.com  Tue Jun  2 14:53:22 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 3 Jun 2026 07:53:22 +1000
Subject: [QGIS-Developer] QEP 425: Stable API/document format policy
Message-ID: <CAB28Asi_tTYPxt2epb_GHp9i1GnJWSjmS4txZnPbk3-6+_3ZxA@mail.gmail.com>

Hi all,

The two week discussion on this QEP (
https://github.com/qgis/QGIS-Enhancement-Proposals/pull/382) has now
passed, and it's ready for voting.

We already had a lot of developers submit +1 approvals, but that was before
the follow up discussions led to addition of a "stable document format"
policy part of this QEP.

Can I ask everyone who's previously submitted +1s on this to re-submit your
vote on the final form of the policy?

Thank you!
Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260603/a7aa65fe/attachment.htm>

From nyall.dawson at gmail.com  Wed Jun  3 20:51:55 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 4 Jun 2026 13:51:55 +1000
Subject: [QGIS-Developer] QEP: Add Exceptional Breakage clause to stable API
 policy
Message-ID: <CAB28Asgx0-CUGom9sKv=b8xg6k5eQO2DnDagMTNpATBao8LkFg@mail.gmail.com>

Hi lists,

Following up the recent formalisation of the PyQGIS stable API policy (see
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-425-stable-api.md),
I've just submitted a proposed change to this policy to add a mechanism to
allow API breaks in EXCEPTIONAL circumstances.

See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/384 for the
proposed changes and a detailed write up on the rationale behind this
change.

Please give all feedback on this proposed change as comments on the PR
itself (not direct email replies) to keep the discussion centralized.

Kind regards,
Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260604/6eebcbd1/attachment.htm>

From carrillo.german at gmail.com  Thu Jun  4 15:21:26 2026
From: carrillo.german at gmail.com (=?UTF-8?Q?Germ=C3=A1n_Carrillo?=)
Date: Thu, 4 Jun 2026 17:21:26 -0500
Subject: [QGIS-Developer] Feedback on introducing a new (abstract)
 class: QgsSimpleCurve
In-Reply-To: <CANaz7mxGgkuuA-r7Mf-mTeZotw2=T0on=mKtPKp1kwmCHAWU3A@mail.gmail.com>
References: <CANaz7mxYRfzxD9Vnw1kbjOmAS3NwG53qiN=+Yyr07tqvVgDMxg@mail.gmail.com>
 <rmiv7c8eceg.fsf@s1.lexort.com>
 <2badf10e-cd7f-4a3c-ba73-de1af90489f9@spatialys.com>
 <rmi4ijrep2f.fsf@s1.lexort.com>
 <CANaz7mxGgkuuA-r7Mf-mTeZotw2=T0on=mKtPKp1kwmCHAWU3A@mail.gmail.com>
Message-ID: <CANaz7mypFw8_0A838j4Au1gGoae0SsAd_p19d7Kweutznpuy-g@mail.gmail.com>

Hi,

I've created a PR for introducing the QgsSimpleCurve class to QGIS core.

You can have a look at:
https://github.com/qgis/QGIS/pull/66346

Regards,

Germ?n


El jue, 28 may 2026 a las 9:25, Germ?n Carrillo (<carrillo.german at gmail.com>)
escribi?:

> Hi,
>
> Thanks Greg, Nyall, Even, and Lo?c for your responses.
>
> And special thanks Even for clarifying the raised questions and for all
> the shared resources.
>
> If QgsSimpleCurve appears in the SIP Python bindings, it might be
>> appropriate to have a word in the doc about it being an implementation
>> detail not covered by standards.
>
>
> Yes, we'll state this for Python bindings.
>
> If others still want to share their thoughts on this, please do so.
>
> I'll prepare a PR soon and let you know when that happens.
>
> Regards,
>
> Germ?n
>
>
> El jue, 28 may 2026 a las 6:44, Greg Troxel via QGIS-Developer (<
> qgis-developer at lists.osgeo.org>) escribi?:
>
>> Even Rouault <even.rouault at spatialys.com> writes:
>>
>> Thanks - especially GDAL RFC49 is enlightening.
>>
>> >>    For each, are there aspects that are not implemented in
>> >>    qgis/geos/gdal/postgis/?
>> > SQL/MM could possibly have exposed such a class, but I guess that's
>> > mostly seen as an implementation detail for implementations to avoid
>> > code duplication, rather than something impacting operability.
>>
>> The point that I didn't understand from the original mail is, I think,
>> that the new class is an implementation detail and not something that
>> will result in objects of that class being stored and read from files.
>>
>> >>    Do programs in the osgeo stack implement object types that  are not
>> in
>> >>    the standards?
>> > Isn't that's > 90% of the job of making useful software, unless your
>> > software is just about making a reference implementation of a
>> > standard? Standards cover only the boring aspects :-)
>>
>> Sure, but it's good to know when that line is crossed, and there is
>> features of software, vs object types that are written and read and
>> might need to interoperate.
>>
>> > Personal opinion here: participation to standard working groups is
>> > time consuming and implies many year involvement due to slow motion /
>> > bureaucracy / opacity in group dynamics. That's not an activity
>> > structured for small/medium businesses (more for big commercial
>> > players that want to push their thing so they can later tick their
>> > implementation is compliant in call for tenders, or government
>> > agencies that have dedicated staff for interoperability topics),
>> > unless you are really fond of that or have significant funding.
>>
>> Understood.  I was trying to ask "could this be seen as a change to the
>> standard and if so is that written down", and asking what the plan is.
>>
>> It sounds like this is an implementation detail and no objects of the
>> new type would be written to file formats.  Thus it is out of scope from
>> the standards.
>>
>> >> I see you address gdal/geos but I don't see postgis mentioned.
>> > PostGIS is C, so inheritance is not a natural concept there. PostGIS's
>>
>> In C, there is only the manual/hard/not-natural inheritance of
>> same-layout structs and casts :-)
>>
>> > liblwgeom has identical layout for struct LWLINE
>> > (
>> https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L480
>> )
>> > and LWCIRCSTRING
>> > (
>> https://github.com/postgis/postgis/blob/master/liblwgeom/liblwgeom.h.in#L504
>> )
>>
>> but has no simplecurve.
>>
>> > See GDAL RFC 49 :
>> >
>> https://gdal.org/en/stable/development/rfc/rfc49_curve_geometries.html#new-cass-hierarchy
>>
>> Thanks, that makes it all clear.  And this is "abstract class" which
>> means that there will never be an object of type OGRSimpleCurve in
>> memory, or written to a file.  And presumably, code won't return a
>> pointer to a QgsSimpleCurve object to a plugin, even if it could only be
>> accessed via virtual dispatch.
>>
>> I missed the "(abstract)" (which is clearly present on rereading) in the
>> original question, and began to think about interoperability concerns.
>>
>>
>> This proposal seems fine to me and I withdraw my questions as mostly
>> answered and the rest explained why they don't really make sense to
>> answer.
>> _______________________________________________
>> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260604/37ca3ef8/attachment.htm>

From rhurlin at gwdg.de  Fri Jun  5 05:58:31 2026
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Fri, 5 Jun 2026 14:58:31 +0200
Subject: [QGIS-Developer] QGIS 4: PostgreSQL layer properties 'Information
 from provider' is not displayed correctly
Message-ID: <bd24d075-efdc-45fd-a2d9-dfa90677e0fe@gwdg.de>

Dear Devs,
I was unable to attach a screenshot to a GitHub issue. Therefore, I am 
describing the following issue here in the list, as it is difficult to 
describe the error without an image.

In QGIS 4, in released versions up to 4.0.3 as well as in today's devel 
branch, the ?Information from provider? section in the properties of 
PostgreSQL layers is displayed incorrectly. This happens in the browser 
and also with loaded layers.

Instead of the expected information under Privileges or Spatial Index, a 
list of dots is displayed. Each dot in the list contains exactly one 
character. All characters in a list appear to be SQL commands or 
parameters? The attached screenshot shows a section where the display 
error can be seen.

This occurs on Windows 10, 11, and FreeBSD. In QGIS 3, the properties of 
PostgreSQL layers are displayed correctly.

Best regards,
Rainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QGIS4_Qt6_FreeBSD_PostgreSQL_layer_properties.jpg
Type: image/jpeg
Size: 61217 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260605/6835a852/attachment-0001.jpg>

From even.rouault at spatialys.com  Fri Jun  5 17:18:55 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sat, 6 Jun 2026 02:18:55 +0200
Subject: [QGIS-Developer] SIP is insane
Message-ID: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>

Hi,

sorry for the? eye-catching email title, couldn't resist.

Am I the only QGIS dev highly frustrated by the bottleneck of sip-build 
when building QGIS? Can we do something (funding upstream?) to improve that?

Also some mind bogging stats:

- size of all QGIS headers: find ../src -name "*.h" -exec cat {} \;? | 
wc -l :? 570 288
- size of QGIS .cpp + .ui: find ../src \( -name "*.cpp" -o -name "*.ui" 
\) -exec cat {} \;? | wc -l : 1 497 216

So QGIS is just a 2 million LoC (excluding tests) code base

- size of .sip generated files: find . -name "*.sip" -exec cat {} \; | 
wc -l : 335 425
- size of SIP generated .cpp files:? ?find python/ -name "*.cpp" -exec 
cat {} \;? | wc -l:? 7 532 645? .? 7.5 millions LoC !!!
- size of MOC generated .cpp files: find src/ -name "*.cpp" -exec cat {} 
\;? | wc -l :? 2 051 769

So 2 observations:

- we bind to Python a very large part of our header files (more than 
half). I've always found that the amount of things exposed to Python was 
excessive. IMHO we should be much more conservative, and wait for plugin 
authors to ask for an API to be exposed, rather than expose it prematurely.

- SIP generates > 20 times more lines of .cpp than .sip files!!!? Or 
3.75 times more lines of code than QGIS actual logic.

That shows in (stripped) .so files:

-? output/python/qgis/*.so : 130 MB
- output/lib/*.so.4.1.0 : 170 MB.

So not as crazy as the 7.5 vs 2 MLOC of ratio, but still.

Comparison with GDAL and SWIG:
- size of public .h headers: 50 162 .
- size of Python SWIG source .i files:? ~43 000? (hard to count exactly 
as there's some bits of Java and C# in this count)
- size of SWIG Python generated .cpp files: 164 151 .
So a 4x only ratio of .cpp vs .i

I don't recommend SWIG, but something looks fishy in the kingdom of SIP

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From dvdkon at konarici.cz  Sat Jun  6 02:54:38 2026
From: dvdkon at konarici.cz (David =?UTF-8?Q?Ko=C5=88a=C5=99=C3=ADk?=)
Date: Sat, 06 Jun 2026 11:54:38 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
Message-ID: <2b63194f8e38d370a2b0b90aeca536c437916f44.camel@konarici.cz>

Hi,
as you might remember, I did some work on improving SIP compilation
times last year. I managed to improve performance, but sadly not fully
refactor SIP to allow for a per-class or per-header build. I'll try to
dig out some of my notes and memories on why it was hard if you want.?

That said, I only looked at improving performance of sip-build, maybe
there is some low-hanging fruit in the generated .cpp files.

SIP is developed pretty much solely by Phil Thompson, he has a company
called Riverbank Computing. No idea how interested he'd be in being
contracted for a large refactor, though.

David Ko?a??k

On Sat, 2026-06-06 at 02:18 +0200, Even Rouault via QGIS-Developer
wrote:
> Hi,
> 
> sorry for the? eye-catching email title, couldn't resist.
> 
> Am I the only QGIS dev highly frustrated by the bottleneck of sip-
> build 
> when building QGIS? Can we do something (funding upstream?) to
> improve that?
> 
> Also some mind bogging stats:
> 
> - size of all QGIS headers: find ../src -name "*.h" -exec cat {} \;?
> | 
> wc -l :? 570 288
> - size of QGIS .cpp + .ui: find ../src \( -name "*.cpp" -o -name
> "*.ui" 
> \) -exec cat {} \;? | wc -l : 1 497 216
> 
> So QGIS is just a 2 million LoC (excluding tests) code base
> 
> - size of .sip generated files: find . -name "*.sip" -exec cat {} \;
> | 
> wc -l : 335 425
> - size of SIP generated .cpp files:? ?find python/ -name "*.cpp" -
> exec 
> cat {} \;? | wc -l:? 7 532 645? .? 7.5 millions LoC !!!
> - size of MOC generated .cpp files: find src/ -name "*.cpp" -exec cat
> {} 
> \;? | wc -l :? 2 051 769
> 
> So 2 observations:
> 
> - we bind to Python a very large part of our header files (more than 
> half). I've always found that the amount of things exposed to Python
> was 
> excessive. IMHO we should be much more conservative, and wait for
> plugin 
> authors to ask for an API to be exposed, rather than expose it
> prematurely.
> 
> - SIP generates > 20 times more lines of .cpp than .sip files!!!? Or 
> 3.75 times more lines of code than QGIS actual logic.
> 
> That shows in (stripped) .so files:
> 
> -? output/python/qgis/*.so : 130 MB
> - output/lib/*.so.4.1.0 : 170 MB.
> 
> So not as crazy as the 7.5 vs 2 MLOC of ratio, but still.
> 
> Comparison with GDAL and SWIG:
> - size of public .h headers: 50 162 .
> - size of Python SWIG source .i files:? ~43 000? (hard to count
> exactly 
> as there's some bits of Java and C# in this count)
> - size of SWIG Python generated .cpp files: 164 151 .
> So a 4x only ratio of .cpp vs .i
> 
> I don't recommend SWIG, but something looks fishy in the kingdom of
> SIP
> 
> Even

From apasotti at gmail.com  Sat Jun  6 09:40:27 2026
From: apasotti at gmail.com (Alessandro Pasotti)
Date: Sat, 6 Jun 2026 18:40:27 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
Message-ID: <CAL5Q673G01JG8_s0T3XBsWi9ujsG72uZGUuX_PGO2QK8gqhTzQ@mail.gmail.com>

Hi Even,

I hear your scream and I scream with you :)

Something has definitely worsened after the shift to QT6  (even if I'm
not sure if the QT version has anything to do).

I've come to the point where I cannot build QGIS on my laptop (16GB
RAM 4 physical cores) anymore and even on my office PC (32 GB RAM and
8 physical cores) it occasionally crashes for OOM or freezes.

All the times that it happened, sip-build was eating up all resources.

I am sorry this is just a "me too" and I have no solution for this issue.


On Sat, Jun 6, 2026 at 3:16?AM Even Rouault via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hi,
>
> sorry for the  eye-catching email title, couldn't resist.
>
> Am I the only QGIS dev highly frustrated by the bottleneck of sip-build
> when building QGIS? Can we do something (funding upstream?) to improve that?
>
> Also some mind bogging stats:
>
> - size of all QGIS headers: find ../src -name "*.h" -exec cat {} \;  |
> wc -l :  570 288
> - size of QGIS .cpp + .ui: find ../src \( -name "*.cpp" -o -name "*.ui"
> \) -exec cat {} \;  | wc -l : 1 497 216
>
> So QGIS is just a 2 million LoC (excluding tests) code base
>
> - size of .sip generated files: find . -name "*.sip" -exec cat {} \; |
> wc -l : 335 425
> - size of SIP generated .cpp files:   find python/ -name "*.cpp" -exec
> cat {} \;  | wc -l:  7 532 645  .  7.5 millions LoC !!!
> - size of MOC generated .cpp files: find src/ -name "*.cpp" -exec cat {}
> \;  | wc -l :  2 051 769
>
> So 2 observations:
>
> - we bind to Python a very large part of our header files (more than
> half). I've always found that the amount of things exposed to Python was
> excessive. IMHO we should be much more conservative, and wait for plugin
> authors to ask for an API to be exposed, rather than expose it prematurely.
>
> - SIP generates > 20 times more lines of .cpp than .sip files!!!  Or
> 3.75 times more lines of code than QGIS actual logic.
>
> That shows in (stripped) .so files:
>
> -  output/python/qgis/*.so : 130 MB
> - output/lib/*.so.4.1.0 : 170 MB.
>
> So not as crazy as the 7.5 vs 2 MLOC of ratio, but still.
>
> Comparison with GDAL and SWIG:
> - size of public .h headers: 50 162 .
> - size of Python SWIG source .i files:  ~43 000  (hard to count exactly
> as there's some bits of Java and C# in this count)
> - size of SWIG Python generated .cpp files: 164 151 .
> So a 4x only ratio of .cpp vs .i
>
> I don't recommend SWIG, but something looks fishy in the kingdom of SIP
>
> Even
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> 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 julien.cabieces at oslandia.com  Mon Jun  8 01:00:18 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Mon, 08 Jun 2026 10:00:18 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com> (Even
 Rouault via's message of "Sat, 6 Jun 2026 02:18:55 +0200")
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
Message-ID: <87o6hl8nsd.fsf@julienlaptop.home>


Hi all, 

> Am I the only QGIS dev highly frustrated by the bottleneck of
> sip-build when building QGIS? 

No, you're not alone. I also experience crashes or freezes when building
and I have considerably reduced the number of processes to be used to
avoid these...

> Can we do something (funding upstream?)
> to improve that?

We can still reach out Phil Thompson on the Python-SIP issue tracker [0]

I have done it several times and things have been improved or fixed
(unique_ptr management for instance lately).

Problem is that we depend on SIP versions shipped in linux distributions,
so we would have to wait quite a long time before using those improvments. 

> - we bind to Python a very large part of our header files (more than
>   half). I've always found that the amount of things exposed to Python
>   was excessive. IMHO we should be much more conservative, and wait
>   for plugin authors to ask for an API to be exposed, rather than
>  expose it prematurely.
>

I completely agree. And I'm wondering what part of the API is really
used by the existing plugins, I'm suspecting that it's a very small part.

A while ago, I take a look about what Blender was exposing in its Python
API. It's so small in comparison.

If other contributors agree with this statement, maybe we could try to
work on a Policy to avoid adding any thing new to the Python API that
it's not worth it.

Regards,
Julien


[0]: https://github.com/Python-SIP/sip


> Hi,
>
> sorry for the? eye-catching email title, couldn't resist.
>
> Am I the only QGIS dev highly frustrated by the bottleneck of
> sip-build when building QGIS? Can we do something (funding upstream?)
> to improve that?
>
> Also some mind bogging stats:
>
> - size of all QGIS headers: find ../src -name "*.h" -exec cat {} \;? |
>   wc -l :? 570 288
> - size of QGIS .cpp + .ui: find ../src \( -name "*.cpp" -o -name
>   "*.ui" \) -exec cat {} \;? | wc -l : 1 497 216
>
> So QGIS is just a 2 million LoC (excluding tests) code base
>
> - size of .sip generated files: find . -name "*.sip" -exec cat {} \; |
>   wc -l : 335 425
> - size of SIP generated .cpp files:? ?find python/ -name "*.cpp" -exec
>   cat {} \;? | wc -l:? 7 532 645? .? 7.5 millions LoC !!!
> - size of MOC generated .cpp files: find src/ -name "*.cpp" -exec cat
>   {} \;? | wc -l :? 2 051 769
>
> So 2 observations:
>
> - we bind to Python a very large part of our header files (more than
>   half). I've always found that the amount of things exposed to Python
>   was excessive. IMHO we should be much more conservative, and wait
>   for plugin authors to ask for an API to be exposed, rather than
>  expose it prematurely.
>
> - SIP generates > 20 times more lines of .cpp than .sip files!!!? Or
>   3.75 times more lines of code than QGIS actual logic.
>
> That shows in (stripped) .so files:
>
> -? output/python/qgis/*.so : 130 MB
> - output/lib/*.so.4.1.0 : 170 MB.
>
> So not as crazy as the 7.5 vs 2 MLOC of ratio, but still.
>
> Comparison with GDAL and SWIG:
> - size of public .h headers: 50 162 .
> - size of Python SWIG source .i files:? ~43 000? (hard to count
>   exactly as there's some bits of Java and C# in this count)
> - size of SWIG Python generated .cpp files: 164 151 .
> So a 4x only ratio of .cpp vs .i
>
> I don't recommend SWIG, but something looks fishy in the kingdom of SIP
>
> Even

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com

From regis.haubourg at gmail.com  Mon Jun  8 06:13:05 2026
From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=)
Date: Mon, 8 Jun 2026 15:13:05 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <87o6hl8nsd.fsf@julienlaptop.home>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
 <87o6hl8nsd.fsf@julienlaptop.home>
Message-ID: <374dead5-7ead-4ecc-b380-4334d79d4b6d@gmail.com>


On 08/06/2026 10:00, Julien Cabieces via QGIS-Developer wrote:
> I completely agree. And I'm wondering what part of the API is really
> used by the existing plugins, I'm suspecting that it's a very small part.

Hi, I'm asking as a non-dev, could we imagine scanning all the public 
repository for the classes and method that are actually used by plugins?
That could help having a real picture here. I'd be +1 for a grant 
funding here


Cheers

R?gis



From r.nijssen at terglobo.nl  Mon Jun  8 06:38:36 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Mon, 8 Jun 2026 15:38:36 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
Message-ID: <ee3191ff-3e43-4d50-b38d-86c512b57a88@terglobo.nl>

On 6/6/26 02:18, Even Rouault via QGIS-Developer wrote:
> I've always found that the amount of things exposed to Python was 
> excessive. IMHO we should be much more conservative, and wait for plugin 
> authors?to?ask?for?an?API?to?be?exposed,?rather?than?expose?it?prematurely.


Not sure which part this would be, but it reminds me of the "old days" 
when Python bindings were made by hand and a big part of the API was not 
exposed. As a plugin developer I needed to ask core developers to expose 
a class or function to Python and wait for it to happen.

Then I needed to build QGIS (which I can) but after finishing the plugin 
my customers had to wait for months (if not a years) for the next QGIS 
release to be able to run the plugin on their company wide QGIS (LTR) 
installation.

Not nice for the core developers (I guess making Python bindings is not 
the most fun task), not nice for plugin developers and not nice for QGIS 
users in need for a new plugin.

I'm also wondering how many plugins would break if we would suddenly 
quit exposing part of the API. Even if we scan the entire plugin 
repository, there are many more plugins in the world.

So, I'm really happy with the current approach of exposing everything. 
If this can be more efficient somehow that would of course be wonderful.

Kind regards,
Raymond

From alexander.bruy at gmail.com  Mon Jun  8 07:06:51 2026
From: alexander.bruy at gmail.com (Alexander Bruy)
Date: Mon, 8 Jun 2026 15:06:51 +0100
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
Message-ID: <CALuHMPC1fxWvviocY_uBo8dyHOoLfd6=KahRgnTVzwaqafkn3g@mail.gmail.com>

Hi all,

Just want to remind you about the QEP about switching to PySide (Qt
for Python) [0].
But I have no idea if such a move will solve issues raised here.

[0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/237

-- 
Alexander Bruy

From werner.macho at gmail.com  Mon Jun  8 08:12:12 2026
From: werner.macho at gmail.com (Werner Macho)
Date: Mon, 8 Jun 2026 17:12:12 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <CALuHMPC1fxWvviocY_uBo8dyHOoLfd6=KahRgnTVzwaqafkn3g@mail.gmail.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
 <CALuHMPC1fxWvviocY_uBo8dyHOoLfd6=KahRgnTVzwaqafkn3g@mail.gmail.com>
Message-ID: <eae9ecef-7f2f-43b6-8e04-d6a5579837e1@gmail.com>

Hi all,
I just wanted to ask the same as Alex already did.
Do we have any advantage migrating to PySide (now it is called the official Qt for Python)?
If yes I am more than willing to adjust my plug-ins.

Regards
Werner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260608/805f0d38/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260608/805f0d38/attachment.sig>

From nyall.dawson at gmail.com  Mon Jun  8 13:58:40 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 9 Jun 2026 06:58:40 +1000
Subject: [QGIS-Developer] QEP426: Demotion of DB Manager plugin to community
 plugin
Message-ID: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>

Hi lists,

I've just submitted QEP426: "Demotion of DB Manager plugin to community
plugin" (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385)

Historically, the DB Manager plugin was a critical component of the QGIS
ecosystem, providing essential database administration and querying
capabilities. However, over the 3.x development cycle, the direction of
QGIS shifted toward integrating all database related functionality into the
Browser Panel. This provides a better user experience, by exposing database
tools alongside other layer and connection management tools. The
browser-based functionality is all designed around generic, heavily tested
connection APIs, which are also used by many other areas of QGIS. In
contrast, the DB Manager plugin contains all its own logic and code for
handling database integration, with extremely minimal (almost non-existent)
test coverage.

As of QGIS 4.2, the core functionality of the DB Manager has been fully
ported to the built-in Browser Panel. Users can natively manage schemas,
create and delete tables, manage fields, and execute SQL queries directly
within the core interface. Maintaining the DB Manager plugin as a core
component now duplicates this functionality, bloating the codebase and
creating unnecessary maintenance overhead for core developers.

This QEP proposes that DB Manager is demoted to a 3rd party, community
maintained plugin, and describes the plan to implement this change.
The full proposal and plan is available at
https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385 for discussion.

Please don't reply to this email -- replies should be commented on the QEP
itself to keep discussion centralised.

Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260609/b958ed59/attachment.htm>

From nyall.dawson at gmail.com  Mon Jun  8 16:59:16 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 9 Jun 2026 09:59:16 +1000
Subject: [QGIS-Developer] QGIS 4: PostgreSQL layer properties
 'Information from provider' is not displayed correctly
In-Reply-To: <bd24d075-efdc-45fd-a2d9-dfa90677e0fe@gwdg.de>
References: <bd24d075-efdc-45fd-a2d9-dfa90677e0fe@gwdg.de>
Message-ID: <CAB28Ash2qwxnAeQqUNXep641JG5ta-J0LxCM+NZ13iFwXJ30Vw@mail.gmail.com>

On Fri, 5 Jun 2026 at 22:58, Rainer Hurling via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Dear Devs,
> I was unable to attach a screenshot to a GitHub issue. Therefore, I am
> describing the following issue here in the list, as it is difficult to
> describe the error without an image.
>
> In QGIS 4, in released versions up to 4.0.3 as well as in today's devel
> branch, the ?Information from provider? section in the properties of
> PostgreSQL layers is displayed incorrectly. This happens in the browser
> and also with loaded layers.
>
> Instead of the expected information under Privileges or Spatial Index, a
> list of dots is displayed. Each dot in the list contains exactly one
> character. All characters in a list appear to be SQL commands or
> parameters? The attached screenshot shows a section where the display
> error can be seen.
>
> This occurs on Windows 10, 11, and FreeBSD. In QGIS 3, the properties of
> PostgreSQL layers are displayed correctly.

Fixed in https://github.com/qgis/QGIS/pull/66402

Nyall

>
> Best regards,
> Rainer_______________________________________________
> 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 tim at kartoza.com  Tue Jun  9 00:16:17 2026
From: tim at kartoza.com (Tim Sutton)
Date: Tue, 9 Jun 2026 08:16:17 +0100
Subject: [QGIS-Developer] [Qgis-psc] QEP426: Demotion of DB Manager
 plugin to community plugin
In-Reply-To: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>
References: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>
Message-ID: <CAES-DZQ6EnEdurAb23beZYr-K98iLc0J7uQc03PTv4L84kB+1g@mail.gmail.com>

Thanks Nyall and so long to the DB Manager, it has been a great component
of QGIS all these years, glad to have all of its functionality implemented
in core now!

Regards

Tim

On Mon, Jun 8, 2026 at 9:59?PM Nyall Dawson via QGIS-PSC <
qgis-psc at lists.osgeo.org> wrote:

> Hi lists,
>
> I've just submitted QEP426: "Demotion of DB Manager plugin to community
> plugin" (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385)
>
> Historically, the DB Manager plugin was a critical component of the QGIS
> ecosystem, providing essential database administration and querying
> capabilities. However, over the 3.x development cycle, the direction of
> QGIS shifted toward integrating all database related functionality into the
> Browser Panel. This provides a better user experience, by exposing database
> tools alongside other layer and connection management tools. The
> browser-based functionality is all designed around generic, heavily tested
> connection APIs, which are also used by many other areas of QGIS. In
> contrast, the DB Manager plugin contains all its own logic and code for
> handling database integration, with extremely minimal (almost non-existent)
> test coverage.
>
> As of QGIS 4.2, the core functionality of the DB Manager has been fully
> ported to the built-in Browser Panel. Users can natively manage schemas,
> create and delete tables, manage fields, and execute SQL queries directly
> within the core interface. Maintaining the DB Manager plugin as a core
> component now duplicates this functionality, bloating the codebase and
> creating unnecessary maintenance overhead for core developers.
>
> This QEP proposes that DB Manager is demoted to a 3rd party, community
> maintained plugin, and describes the plan to implement this change.
> The full proposal and plan is available at
> https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385 for
> discussion.
>
> Please don't reply to this email -- replies should be commented on the QEP
> itself to keep discussion centralised.
>
> Nyall
>
> _______________________________________________
> QGIS-PSC mailing list
> QGIS-PSC at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>


-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260609/e08d1d79/attachment-0001.htm>

From julien.cabieces at oslandia.com  Tue Jun  9 00:26:57 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Tue, 09 Jun 2026 09:26:57 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <CALuHMPC1fxWvviocY_uBo8dyHOoLfd6=KahRgnTVzwaqafkn3g@mail.gmail.com>
 (Alexander Bruy via's message of "Mon, 8 Jun 2026 15:06:51 +0100")
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
 <CALuHMPC1fxWvviocY_uBo8dyHOoLfd6=KahRgnTVzwaqafkn3g@mail.gmail.com>
Message-ID: <877bo8898e.fsf@julienlaptop.home>


Hi all,

Regarding switching to "Qt for Python", I made a report on where I was
last time I worked on a possible transition to Qt for Python (december 2023) [0]

My feelings:
- While trying to transition from SIP to QtForPython, I met so many
surprises/special-cases/SIP-specific-behaviors that I think we are now very tightly bounded
to it
- It's very difficult to predict the needed time required to make the
whole transition, you have no idea how many surprises you gonna met
- Even if I enjoyed many things from QtForPython, we have no garantee
that it would be better in the end

We could try to lessen adherence to SIP to ease a possible future transition (replace SIP_FACTORY/SIP_TRANSFER with unique_ptr
for instance).

> Do we have any advantage migrating to PySide (now it is called the official Qt for Python)? 
> If yes I am more than willing to adjust my plug-ins. 

Normally, no adjustement (or very few) would be needed (for thoses importing from
qgis.PyQt at least)

Regards,
Julien


[0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/237#issuecomment-1839008093


> Hi all,
>
> Just want to remind you about the QEP about switching to PySide (Qt
> for Python) [0].
> But I have no idea if such a move will solve issues raised here.
>
> [0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/237

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com

From julien.cabieces at oslandia.com  Tue Jun  9 00:41:23 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Tue, 09 Jun 2026 09:41:23 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <374dead5-7ead-4ecc-b380-4334d79d4b6d@gmail.com>
 (=?utf-8?Q?=22R=C3=A9gis?= Haubourg
 via QGIS-Developer"'s message of "Mon, 8 Jun 2026 15:13:05 +0200")
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
 <87o6hl8nsd.fsf@julienlaptop.home>
 <374dead5-7ead-4ecc-b380-4334d79d4b6d@gmail.com>
Message-ID: <87y0go6tzw.fsf@julienlaptop.home>


Hi Regis,

> On 08/06/2026 10:00, Julien Cabieces via QGIS-Developer wrote:
>> I completely agree. And I'm wondering what part of the API is really
>> used by the existing plugins, I'm suspecting that it's a very small part.
>
> Hi, I'm asking as a non-dev, could we imagine scanning all the public
> repository for the classes and method that are actually used by
> plugins?
> That could help having a real picture here. I'd be +1 for a grant
> funding here
>

I also wanted to something alike, just as a matter of curiosity.

I'm wondering for instance if plugins are really using the 200 widgets
we are exposing. Some widget absolutely make sense (QgsFileWidget,
QgsScaleWidget...) but I have more doubt for some (the properties
widget for instance). But I rarely develop plugin so maybe I'm missing
the big picture here.

Regards,
Julien


>
> Cheers
>
> R?gis
>
>
> _______________________________________________
> 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 uclaros at gmail.com  Tue Jun  9 06:19:23 2026
From: uclaros at gmail.com (Stefanos Natsis)
Date: Tue, 9 Jun 2026 16:19:23 +0300
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
Message-ID: <CADBCwLYPMSWH1g2RZuS7dp1qAOwoR5yAoSP3m0+fe4ZS14htxw@mail.gmail.com>

Hi all,


Am I the only QGIS dev highly frustrated by the bottleneck of sip-build
> when building QGIS? Can we do something (funding upstream?) to improve
> that?


I used to be quite frustrated when sip4 support was dropped, as sip-build
times were really terrible with sip 6 at the time.
After David's fixes in Oct/Nov 2025 though, things are back to normal. With
sip-tools v6.15+ I don't think sip-build is a bottleneck any more for me.
I'm more annoyed that touching any enum or docstring in qgis.h will trigger
an almost full rebuild of the whole project!
Though, I still often do `ninja qgis` during iterative rebuilds to avoid
sip-build if not strictly necessary.



> - we bind to Python a very large part of our header files (more than
> half). I've always found that the amount of things exposed to Python was
> excessive. IMHO we should be much more conservative, and wait for plugin
> authors to ask for an API to be exposed, rather than expose it prematurely.
>

 My personal preference would be to expose as much as the stable API
promise allows us to, then encourage development of new and often
niche features to be done as python plugins instead of having them in core.

Best,
Stefanos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260609/3804357f/attachment.htm>

From even.rouault at spatialys.com  Tue Jun  9 06:46:46 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Tue, 9 Jun 2026 15:46:46 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <CADBCwLYPMSWH1g2RZuS7dp1qAOwoR5yAoSP3m0+fe4ZS14htxw@mail.gmail.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
 <CADBCwLYPMSWH1g2RZuS7dp1qAOwoR5yAoSP3m0+fe4ZS14htxw@mail.gmail.com>
Message-ID: <1c03dec8-03af-4a48-9948-3738fc4d7515@spatialys.com>


Le 09/06/2026 ? 15:19, Stefanos Natsis a ?crit?:
> Hi all,
>
>
>     Am I the only QGIS dev highly frustrated by the bottleneck of
>     sip-build
>     when building QGIS? Can we do something (funding upstream?) to
>     improve that?
>
>
> I used to be quite frustrated when sip4 support was dropped, as 
> sip-build times were really terrible with sip 6 at the time.
> After David's fixes in Oct/Nov 2025 though, things are back to normal. 
> With sip-tools v6.15+ I don't think sip-build is a bottleneck any more 
> for me.

Thanks for the hint. That does improve things (sip-build time) indeed. 
For posterity, I managed to use it without altering too much my build 
env with:

python3 -m venv sip_venv
source sip_venv/bin/activate
pip install sip PyQt-builder
cmake -USIP_BUILD_EXECUTABLE ..


-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260609/0419f7bb/attachment.htm>

From uclaros at gmail.com  Tue Jun  9 12:18:15 2026
From: uclaros at gmail.com (Stefanos Natsis)
Date: Tue, 9 Jun 2026 22:18:15 +0300
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <1c03dec8-03af-4a48-9948-3738fc4d7515@spatialys.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
 <CADBCwLYPMSWH1g2RZuS7dp1qAOwoR5yAoSP3m0+fe4ZS14htxw@mail.gmail.com>
 <1c03dec8-03af-4a48-9948-3738fc4d7515@spatialys.com>
Message-ID: <CADBCwLYajFXvqf6m8U18OjZxiRtiekRFUWdmZf0oJNYqVUUs9A@mail.gmail.com>

Nice!

With sip code being python, I had just patched my system sip with David's
diff, until 6.15 was included in Debian testing.

Best,
Stefanos

On Tue, Jun 9, 2026, 4:46 PM Even Rouault <even.rouault at spatialys.com>
wrote:

>
> Le 09/06/2026 ? 15:19, Stefanos Natsis a ?crit :
>
> Hi all,
>
>
> Am I the only QGIS dev highly frustrated by the bottleneck of sip-build
>> when building QGIS? Can we do something (funding upstream?) to improve
>> that?
>
>
> I used to be quite frustrated when sip4 support was dropped, as sip-build
> times were really terrible with sip 6 at the time.
> After David's fixes in Oct/Nov 2025 though, things are back to normal.
> With sip-tools v6.15+ I don't think sip-build is a bottleneck any more for
> me.
>
> Thanks for the hint. That does improve things (sip-build time) indeed. For
> posterity, I managed to use it without altering too much my build env with:
>
> python3 -m venv sip_venv
> source sip_venv/bin/activate
> pip install sip PyQt-builder
> cmake -USIP_BUILD_EXECUTABLE ..
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260609/c90b7d5a/attachment.htm>

From nyall.dawson at gmail.com  Tue Jun  9 15:20:48 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 10 Jun 2026 08:20:48 +1000
Subject: [QGIS-Developer] Limiting 3.44 backports?
Message-ID: <CAB28AshnnTOjy_c51r+8CRc5XhS31DV41cT9dWD8JgR=EON62w@mail.gmail.com>

Hi list,

I noticed a lot of bug fixes aren't getting the 3.44 backport label.
Is this an intentional decision now? Are we at the stage where we
should be limiting 3.44 backports to critical fixes only?

Nyall

From even.rouault at spatialys.com  Tue Jun  9 15:48:24 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 10 Jun 2026 00:48:24 +0200
Subject: [QGIS-Developer] SIP is insane
In-Reply-To: <1c03dec8-03af-4a48-9948-3738fc4d7515@spatialys.com>
References: <fd423b58-27bb-425a-880a-5d0b95a5640e@spatialys.com>
 <CADBCwLYPMSWH1g2RZuS7dp1qAOwoR5yAoSP3m0+fe4ZS14htxw@mail.gmail.com>
 <1c03dec8-03af-4a48-9948-3738fc4d7515@spatialys.com>
Message-ID: <a425bf93-79eb-4af5-b7e5-22a620892e44@spatialys.com>

For posterity again: while below works fine at compilation time, it 
breaks at runtime due to Qt / SIP version mismatches :-(
>
> Thanks for the hint. That does improve things (sip-build time) indeed. 
> For posterity, I managed to use it without altering too much my build 
> env with:
>
> python3 -m venv sip_venv
> source sip_venv/bin/activate
> pip install sip PyQt-builder
> cmake -USIP_BUILD_EXECUTABLE ..
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/766798c5/attachment.htm>

From gdt at lexort.com  Tue Jun  9 18:22:44 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 09 Jun 2026 21:22:44 -0400
Subject: [QGIS-Developer] Limiting 3.44 backports?
In-Reply-To: <CAB28AshnnTOjy_c51r+8CRc5XhS31DV41cT9dWD8JgR=EON62w@mail.gmail.com>
 (Nyall Dawson via's message of "Wed, 10 Jun 2026 08:20:48 +1000")
References: <CAB28AshnnTOjy_c51r+8CRc5XhS31DV41cT9dWD8JgR=EON62w@mail.gmail.com>
Message-ID: <rmi4ijbjijf.fsf@s1.lexort.com>

Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> I noticed a lot of bug fixes aren't getting the 3.44 backport label.
> Is this an intentional decision now? Are we at the stage where we
> should be limiting 3.44 backports to critical fixes only?

1) Have we annnounced: 4.0.2 is the standard approach.  If you haven't
upgraded from 3.44.x to 4.0.2, you're behind.  In other words, when
someone say "I want to run qgis but I don't know what version - tell
me", what do we say?

2) Have we blessed a new LTR?

Unless the answers  are reliably "x, where x is newer than 3.44" and
"yes", then I think it makes sense to maintain 3.44.x.

For getting work done, I'm using 3.44.x.  I'm pretty sure most people
would advise to use that.   So I think the answers to 1/2 are "no, and
3.44 is still  what people should run"

From nyall.dawson at gmail.com  Tue Jun  9 18:45:38 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 10 Jun 2026 11:45:38 +1000
Subject: [QGIS-Developer] Limiting 3.44 backports?
In-Reply-To: <rmi4ijbjijf.fsf@s1.lexort.com>
References: <CAB28AshnnTOjy_c51r+8CRc5XhS31DV41cT9dWD8JgR=EON62w@mail.gmail.com>
 <rmi4ijbjijf.fsf@s1.lexort.com>
Message-ID: <CAB28AshOnMxYUm9suJGKR3DGxvH5KAW4BZKW3dNqz1EE1k8mbw@mail.gmail.com>

On Wed, 10 Jun 2026 at 11:22, Greg Troxel via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:
>
> Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:
>
> > I noticed a lot of bug fixes aren't getting the 3.44 backport label.
> > Is this an intentional decision now? Are we at the stage where we
> > should be limiting 3.44 backports to critical fixes only?
>
> 1) Have we annnounced: 4.0.2 is the standard approach.  If you haven't
> upgraded from 3.44.x to 4.0.2, you're behind.  In other words, when
> someone say "I want to run qgis but I don't know what version - tell
> me", what do we say?

No, we very strongly say "stick with 3.44"!

>
> 2) Have we blessed a new LTR?

No. (And I would suggest we DON'T tag 4.2 as LTR... but that's a completely
different discussion ? )



>
> Unless the answers  are reliably "x, where x is newer than 3.44" and
> "yes", then I think it makes sense to maintain 3.44.x.
>
> For getting work done, I'm using 3.44.x.  I'm pretty sure most people
> would advise to use that.   So I think the answers to 1/2 are "no, and
> 3.44 is still  what people should run"
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/61efd47a/attachment.htm>

From jota9 at hotmail.com  Wed Jun 10 04:20:33 2026
From: jota9 at hotmail.com (juan pedro escapil)
Date: Wed, 10 Jun 2026 11:20:33 +0000
Subject: [QGIS-Developer] Independent GPL AutoCAD plugin using QGIS-inspired
 geospatial concepts Dear QGIS Development Community, 
Message-ID: <DM4PR84MB166305031246DB5199226666E61A2@DM4PR84MB1663.NAMPRD84.PROD.OUTLOOK.COM>


My name is Juan Pedro Escapil, from Argentina.

I am developing an independent GPL-licensed AutoCAD 2013 plugin for geospatial work. The project is not an official QGIS plugin and is not presented as endorsed or certified by QGIS. It is an independent AutoCAD plugin.

The purpose of the plugin is to bring GIS-style workflows into AutoCAD, including:

* XYZ / TMS / WMS raster map sources
* WFS vector import
* sector-based map preview
* selected-area high-resolution export
* georeferenced JPG + JGW + PRJ + VRT output
* Argentine public sources such as IGN and ARBA WFS

I want to be transparent with the QGIS community. The project is inspired by QGIS workflows and uses common open geospatial service concepts also supported by QGIS. If I later reuse or adapt any actual QGIS source code, I will preserve the original copyright notices, clearly document the specific source files/functions used, and keep the derived work under a GPL-compatible license.

The plugin will include:

* GPL license notice
* source code distribution
* credits file
* clear statement that it is not affiliated with or endorsed by QGIS.ORG<http://qgis.org/>
* source attribution for any QGIS code actually reused

I would appreciate any guidance from the QGIS community on the proper attribution wording and best practices for respecting QGIS licensing and trademark guidelines.

Best regards,

Arq. Juan Pedro Escapil
Argentina
+542214097567



Enviado desde Outlook<http://aka.ms/weboutlook>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/b80ffffb/attachment-0001.htm>

From rdmailings at duif.net  Wed Jun 10 04:45:42 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Wed, 10 Jun 2026 13:45:42 +0200
Subject: [QGIS-Developer] Plugin authors, email confirmation, Plugins list
Message-ID: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>

Personally I received a question from QGIS.org to confirm the email address(es) I use for my plugins.

As one of the mail admins, I receive a lot of 'no replies' from others. Because the person does not work there anymore or changed mail etc etc.

Any plans to do some communication around this? As I think we will remove or hide the plugins with unconfirmed mail addresses, I'm afraid people will miss some of the plugins.
But also I would have missed this mail if not receiving all the 'returned' mails... :-)


Another thing I want to bring up: having so many plugins now, would it be an idea to order the list based on: the number of stars, of number of downloads? Then at least plugins which earned some credits will be most viewable, instead of handy authors naming there plugins so that they appear upfront :-)

Regards,

Richard Duivenvoorde

From vincent.ml at oslandia.com  Wed Jun 10 04:55:14 2026
From: vincent.ml at oslandia.com (Vincent Picavet)
Date: Wed, 10 Jun 2026 13:55:14 +0200
Subject: [QGIS-Developer] Independent GPL AutoCAD plugin using
 QGIS-inspired geospatial concepts Dear QGIS Development Community, 
In-Reply-To: <DM4PR84MB166305031246DB5199226666E61A2@DM4PR84MB1663.NAMPRD84.PROD.OUTLOOK.COM>
References: <DM4PR84MB166305031246DB5199226666E61A2@DM4PR84MB1663.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <d39bb31b-2d6d-4fd9-afb4-38e7942b7f6c@oslandia.com>

Hello Juan,


I am not 100% sure how AutoCAD plugins work, but I seriously doubt they can be licenced as GPL.


If you link ( or Python `import` ) modules within your plugins, they have to be compatible with GPL. Therefore any proprietary module / binary linked would not correspond to that requirement.


Said otherwise, you cannot have `from pyautocad import Autocad` in a GPL-licenced plugin.


You are free to reuse any functional workflows from QGIS and other concepts, as this is not subject to copyright. But any reuse of code from QGIS or QGIS plugins would have to be licenced under the original licence ( GPLv2+ usually ), and any linked code should be GPL-compatible.

Also a grey-dark area would be any code taken from QGIS and translated to C# : that would most probably have to be under the same GPLv2+ licence.


There are ways to avoid "GPL contamination" between software components, but this kind of advice would not help the opensource community, so I will let you figure that out yourself.


Best regards,

Vincent




On 10/06/2026 13:20, juan pedro escapil via QGIS-Developer wrote:
>
> My name is Juan Pedro Escapil, from Argentina.
>
> I am developing an independent GPL-licensed AutoCAD 2013 plugin for geospatial work. The project is not an official QGIS plugin and is not presented as endorsed or certified by QGIS. It is an independent AutoCAD plugin.
>
> The purpose of the plugin is to bring GIS-style workflows into AutoCAD, including:
>
> * XYZ / TMS / WMS raster map sources
> * WFS vector import
> * sector-based map preview
> * selected-area high-resolution export
> * georeferenced JPG + JGW + PRJ + VRT output
> * Argentine public sources such as IGN and ARBA WFS
>
> I want to be transparent with the QGIS community. The project is inspired by QGIS workflows and uses common open geospatial service concepts also supported by QGIS. If I later reuse or adapt any actual QGIS source code, I will preserve the original copyright notices, clearly document the specific source files/functions used, and keep the derived work under a GPL-compatible license.
>
> The plugin will include:
>
> * GPL license notice
> * source code distribution
> * credits file
> * clear statement that it is not affiliated with or endorsed by QGIS.ORG <http://qgis.org/>
> * source attribution for any QGIS code actually reused
>
> I would appreciate any guidance from the QGIS community on the proper attribution wording and best practices for respecting QGIS licensing and trademark guidelines.
>
> Best regards,
>
> Arq. Juan Pedro Escapil
> Argentina
> +542214097567
>
>
> Enviado desde Outlook <http://aka.ms/weboutlook>
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/61306456/attachment.htm>

From lova at kartoza.com  Wed Jun 10 05:20:52 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 10 Jun 2026 15:20:52 +0300
Subject: [QGIS-Developer] Plugin authors, email confirmation,
 Plugins list
In-Reply-To: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
References: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
Message-ID: <CAMLC-sAeySjS5+wezvUJcYHCzS6CM+tZDRgBxriD0dtRgv+qAg@mail.gmail.com>

Hi Richard,

Thanks for raising this.

Any plans to do some communication around this? As I think we will remove
> or hide the plugins with unconfirmed mail addresses, I'm afraid people will
> miss some of the plugins.
>

As raised many times in some PRs and changes, feedback was given about
effectively communicating any upcoming changes on the plugin repository.
So, the first step is to confirm that the email address provided by a
plugin author in the metadata.txt is responsive according to the state on
the plugin's upload page (https://plugins.qgis.org/plugins/add/).
If there's any plan to remove or hide plugins with unconfirmed mail
addresses, I think we need to always try to communicate them in some other
way (on the repository of the plugin, for example).

Another thing I want to bring up: having so many plugins now, would it be
> an idea to order the list based on: the number of stars, of number of
> downloads? Then at least plugins which earned some credits will be most
> viewable, instead of handy authors naming there plugins so that they appear
> upfront :-)
>

I think this categorised list already exists, but maybe we could bring them
on the upper level? So we would have "Popular plugins" or "Most downloaded"
plugins instead of "All plugins" on the top bar and accessible from the
"Explore" link.

Best regards,
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.*


On Wed, 10 Jun 2026 at 14:45, Richard Duivenvoorde via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Personally I received a question from QGIS.org to confirm the email
> address(es) I use for my plugins.
>
> As one of the mail admins, I receive a lot of 'no replies' from others.
> Because the person does not work there anymore or changed mail etc etc.
>
> Any plans to do some communication around this? As I think we will remove
> or hide the plugins with unconfirmed mail addresses, I'm afraid people will
> miss some of the plugins.
> But also I would have missed this mail if not receiving all the 'returned'
> mails... :-)
>
>
> Another thing I want to bring up: having so many plugins now, would it be
> an idea to order the list based on: the number of stars, of number of
> downloads? Then at least plugins which earned some credits will be most
> viewable, instead of handy authors naming there plugins so that they appear
> upfront :-)
>
> Regards,
>
> Richard Duivenvoorde
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/027e7e09/attachment-0001.htm>

From rdmailings at duif.net  Wed Jun 10 06:05:29 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Wed, 10 Jun 2026 15:05:29 +0200
Subject: [QGIS-Developer] Plugin authors, email confirmation,
 Plugins list
In-Reply-To: <CAMLC-sAeySjS5+wezvUJcYHCzS6CM+tZDRgBxriD0dtRgv+qAg@mail.gmail.com>
References: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
 <CAMLC-sAeySjS5+wezvUJcYHCzS6CM+tZDRgBxriD0dtRgv+qAg@mail.gmail.com>
Message-ID: <3245dc52-63fc-4bfa-aa3d-baa66b4677a7@duif.net>

Thanks for the prompt answer Lova :-)

Ah, I thought this was maybe part of the 'security'-scan for plugins, from that comes my question.

And about the ordering, I meant the plugin manager in QGIS, not so much the plugins.qgis.org website. Sorry for the confusion.
Not sure IF the plugins manager has information to change the order based on the options I mentioned though...

Thanks for all your work!!

Richard

On 6/10/26 14:20, Lova Andriarimalala wrote:
> Hi Richard,
> 
> Thanks for raising this.
> 
>     Any plans to do some communication around this? As I think we will remove or hide the plugins with unconfirmed mail addresses, I'm afraid people will miss some of the plugins.
> 
> 
> As raised many times in some PRs and changes, feedback was given about effectively communicating any upcoming changes on the plugin repository. So, the first step is to confirm that the email address provided by a plugin author in the metadata.txt is responsive according?to the state on the plugin's upload page (https://plugins.qgis.org/plugins/add/ <https://plugins.qgis.org/plugins/add/>).
> If there's any plan to remove or hide plugins with unconfirmed mail addresses, I think we need to always try to communicate them in some other way (on the repository of the plugin, for example).
> 
>     Another thing I want to bring up: having so many plugins now, would it be an idea to order the list based on: the number of stars, of number of downloads? Then at least plugins which earned some credits will be most viewable, instead of handy authors naming there plugins so that they appear upfront :-)
> 
> 
> I think this categorised list already exists, but maybe we could bring them on the upper level? So we would have "Popular plugins" or "Most downloaded" plugins instead of "All plugins" on the top bar and accessible from the "Explore" link.
> 
> Best regards,
> Lova Andriarimalala
> *QGIS Full Stack Developer
> 
> *
> *T *:?+27(0) 87 809 2702 *E *:**lova at kartoza.com <mailto:lova at kartoza.com> *W*?: kartoza.com <http://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./
> 
> 
> On Wed, 10 Jun 2026 at 14:45, Richard Duivenvoorde via QGIS-Developer <qgis-developer at lists.osgeo.org <mailto:qgis-developer at lists.osgeo.org>> wrote:
> 
>     Personally I received a question from QGIS.org to confirm the email address(es) I use for my plugins.
> 
>     As one of the mail admins, I receive a lot of 'no replies' from others. Because the person does not work there anymore or changed mail etc etc.
> 
>     Any plans to do some communication around this? As I think we will remove or hide the plugins with unconfirmed mail addresses, I'm afraid people will miss some of the plugins.
>     But also I would have missed this mail if not receiving all the 'returned' mails... :-)
> 
> 
>     Another thing I want to bring up: having so many plugins now, would it be an idea to order the list based on: the number of stars, of number of downloads? Then at least plugins which earned some credits will be most viewable, instead of handy authors naming there plugins so that they appear upfront :-)
> 
>     Regards,
> 
>     Richard Duivenvoorde
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org <mailto:QGIS-Developer at lists.osgeo.org>
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> 


From gdt at lexort.com  Wed Jun 10 06:25:12 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 10 Jun 2026 09:25:12 -0400
Subject: [QGIS-Developer] Independent GPL AutoCAD plugin using
 QGIS-inspired geospatial concepts Dear QGIS Development Community, 
In-Reply-To: <DM4PR84MB166305031246DB5199226666E61A2@DM4PR84MB1663.NAMPRD84.PROD.OUTLOOK.COM>
 (juan pedro escapil via QGIS-Developer's message of "Wed, 10 Jun 2026
 11:20:33 +0000")
References: <DM4PR84MB166305031246DB5199226666E61A2@DM4PR84MB1663.NAMPRD84.PROD.OUTLOOK.COM>
Message-ID: <rmifr2uil3b.fsf@s1.lexort.com>

juan pedro escapil via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> My name is Juan Pedro Escapil, from Argentina.
>
> I am developing an independent GPL-licensed AutoCAD 2013 plugin for geospatial work. The project is not an official QGIS plugin and is not presented as endorsed or certified by QGIS. It is an independent AutoCAD plugin.
>
> The purpose of the plugin is to bring GIS-style workflows into AutoCAD, including:
>
> * XYZ / TMS / WMS raster map sources
> * WFS vector import
> * sector-based map preview
> * selected-area high-resolution export
> * georeferenced JPG + JGW + PRJ + VRT output
> * Argentine public sources such as IGN and ARBA WFS

Vincent's comments sound right to me.

It seems like your plugin is a collection of unrelated things, even if
is the set of things that you or your org want to do.  I know nothing
about AutoCAD culture, but I would suggest that you consider
implementing separate things as separate plugins.

From gdt at lexort.com  Wed Jun 10 06:55:52 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 10 Jun 2026 09:55:52 -0400
Subject: [QGIS-Developer] Limiting 3.44 backports?
In-Reply-To: <CAB28AshOnMxYUm9suJGKR3DGxvH5KAW4BZKW3dNqz1EE1k8mbw@mail.gmail.com>
 (Nyall Dawson's message of "Wed, 10 Jun 2026 11:45:38 +1000")
References: <CAB28AshnnTOjy_c51r+8CRc5XhS31DV41cT9dWD8JgR=EON62w@mail.gmail.com>
 <rmi4ijbjijf.fsf@s1.lexort.com>
 <CAB28AshOnMxYUm9suJGKR3DGxvH5KAW4BZKW3dNqz1EE1k8mbw@mail.gmail.com>
Message-ID: <rmia4t2ijo7.fsf@s1.lexort.com>

Nyall Dawson <nyall.dawson at gmail.com> writes:

> On Wed, 10 Jun 2026 at 11:22, Greg Troxel via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>>
>> Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:
>>
>> > I noticed a lot of bug fixes aren't getting the 3.44 backport label.
>> > Is this an intentional decision now? Are we at the stage where we
>> > should be limiting 3.44 backports to critical fixes only?
>>
>> 1) Have we annnounced: 4.0.2 is the standard approach.  If you haven't
>> upgraded from 3.44.x to 4.0.2, you're behind.  In other words, when
>> someone say "I want to run qgis but I don't know what version - tell
>> me", what do we say?
>
> No, we very strongly say "stick with 3.44"!

I thought so.  Then IMHO anything that's a bugfix should be getting
backported.  (Up-to-date, following guidance) users are on 3.44.

>> 2) Have we blessed a new LTR?
>
> No. (And I would suggest we DON'T tag 4.2 as LTR... but that's a completely
> different discussion ? )

Indeed.  I guess we should defer that until 4.2.0 is out and we are
about to tag 4.2.1, as I understand it.  A lot can happen between now
and then.

From uclaros at gmail.com  Wed Jun 10 07:49:26 2026
From: uclaros at gmail.com (Stefanos Natsis)
Date: Wed, 10 Jun 2026 17:49:26 +0300
Subject: [QGIS-Developer] Limiting 3.44 backports?
In-Reply-To: <rmia4t2ijo7.fsf@s1.lexort.com>
References: <CAB28AshnnTOjy_c51r+8CRc5XhS31DV41cT9dWD8JgR=EON62w@mail.gmail.com>
 <rmi4ijbjijf.fsf@s1.lexort.com>
 <CAB28AshOnMxYUm9suJGKR3DGxvH5KAW4BZKW3dNqz1EE1k8mbw@mail.gmail.com>
 <rmia4t2ijo7.fsf@s1.lexort.com>
Message-ID: <CADBCwLY9t3Dv04k0VWGxMTc==8MN50zB5dN5Hxpp-TPAdT7UdQ@mail.gmail.com>

Hi,

>> 2) Have we blessed a new LTR?
> >
> > No. (And I would suggest we DON'T tag 4.2 as LTR... but that's a
> completely
> > different discussion ? )
>
> Indeed.  I guess we should defer that until 4.2.0 is out and we are
> about to tag 4.2.1, as I understand it.  A lot can happen between now
> and then.
>

Actually 4.2 is planned to become LTR at the end of October with 4.2.4

Best,
Stefanos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/3031ed81/attachment.htm>

From denis.rouzaud at gmail.com  Wed Jun 10 08:04:22 2026
From: denis.rouzaud at gmail.com (Denis Rouzaud)
Date: Wed, 10 Jun 2026 17:04:22 +0200
Subject: [QGIS-Developer] Limiting 3.44 backports?
In-Reply-To: <CADBCwLY9t3Dv04k0VWGxMTc==8MN50zB5dN5Hxpp-TPAdT7UdQ@mail.gmail.com>
References: <CAB28AshnnTOjy_c51r+8CRc5XhS31DV41cT9dWD8JgR=EON62w@mail.gmail.com>
 <rmi4ijbjijf.fsf@s1.lexort.com>
 <CAB28AshOnMxYUm9suJGKR3DGxvH5KAW4BZKW3dNqz1EE1k8mbw@mail.gmail.com>
 <rmia4t2ijo7.fsf@s1.lexort.com>
 <CADBCwLY9t3Dv04k0VWGxMTc==8MN50zB5dN5Hxpp-TPAdT7UdQ@mail.gmail.com>
Message-ID: <CAMtsY+ZbAoorrF7vz_bArp1Y38SY-Jk0_q4faHopBGJtcHvjww@mail.gmail.com>

I believe we should continue backporting too at least until 4.2 is out, so
at least during the current bugfix period.

Le mer. 10 juin 2026 ? 16:49, Stefanos Natsis via QGIS-Developer <
qgis-developer at lists.osgeo.org> a ?crit :

> Hi,
>
> >> 2) Have we blessed a new LTR?
>> >
>> > No. (And I would suggest we DON'T tag 4.2 as LTR... but that's a
>> completely
>> > different discussion ? )
>>
>> Indeed.  I guess we should defer that until 4.2.0 is out and we are
>> about to tag 4.2.1, as I understand it.  A lot can happen between now
>> and then.
>>
>
> Actually 4.2 is planned to become LTR at the end of October with 4.2.4
>
> Best,
> Stefanos
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/b822d62e/attachment.htm>

From lists at borysjurgiel.pl  Wed Jun 10 07:26:51 2026
From: lists at borysjurgiel.pl (Borys Jurgiel)
Date: Wed, 10 Jun 2026 16:26:51 +0200
Subject: [QGIS-Developer] Plugin authors, email confirmation,
 Plugins list
In-Reply-To: <3245dc52-63fc-4bfa-aa3d-baa66b4677a7@duif.net>
References: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
 <CAMLC-sAeySjS5+wezvUJcYHCzS6CM+tZDRgBxriD0dtRgv+qAg@mail.gmail.com>
 <3245dc52-63fc-4bfa-aa3d-baa66b4677a7@duif.net>
Message-ID: <54988202-ca57-4c99-b328-6cb79ea65cdf@borysjurgiel.pl>



W dniu 10.06.2026 o?15:05, Richard Duivenvoorde via QGIS-Developer pisze:
> Thanks for the prompt answer Lova :-)
> 
> Ah, I thought this was maybe part of the 'security'-scan for plugins, 
> from that comes my question.
> 
> And about the ordering, I meant the plugin manager in QGIS, not so much 
> the plugins.qgis.org website. Sorry for the confusion.
> Not sure IF the plugins manager has information to change the order 
> based on the options I mentioned though...

Well, it is implemented long time ago :) You can right-click on the 
plugin list to change the sort order. Also, we could easily (without any 
GUI changes) add a filter expressions to the search bar
(e.g. "wfs votes:200 stars:4")

By the way, I received an email at my regular address saying that that 
confirmation message had been sent to the email address associated with 
my plugins (it's a dedicated one). However, I never received that 
message (yes, I've checked the spam folder, and that address works fine 
in general ;)

Best regards,
B.

> 
> Thanks for all your work!!
> 
> Richard
> 
> On 6/10/26 14:20, Lova Andriarimalala wrote:
>> Hi Richard,
>>
>> Thanks for raising this.
>>
>> ??? Any plans to do some communication around this? As I think we will 
>> remove or hide the plugins with unconfirmed mail addresses, I'm afraid 
>> people will miss some of the plugins.
>>
>>
>> As raised many times in some PRs and changes, feedback was given about 
>> effectively communicating any upcoming changes on the plugin 
>> repository. So, the first step is to confirm that the email address 
>> provided by a plugin author in the metadata.txt is responsive 
>> according?to the state on the plugin's upload page (https:// 
>> plugins.qgis.org/plugins/add/ <https://plugins.qgis.org/plugins/add/>).
>> If there's any plan to remove or hide plugins with unconfirmed mail 
>> addresses, I think we need to always try to communicate them in some 
>> other way (on the repository of the plugin, for example).
>>
>> ??? Another thing I want to bring up: having so many plugins now, 
>> would it be an idea to order the list based on: the number of stars, 
>> of number of downloads? Then at least plugins which earned some 
>> credits will be most viewable, instead of handy authors naming there 
>> plugins so that they appear upfront :-)
>>
>>
>> I think this categorised list already exists, but maybe we could bring 
>> them on the upper level? So we would have "Popular plugins" or "Most 
>> downloaded" plugins instead of "All plugins" on the top bar and 
>> accessible from the "Explore" link.
>>
>> Best regards,
>> Lova Andriarimalala
>> *QGIS Full Stack Developer
>>
>> *
>> *T *:?+27(0) 87 809 2702 *E *:**lova at kartoza.com 
>> <mailto:lova at kartoza.com> *W*?: kartoza.com <http://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./
>>
>>
>> On Wed, 10 Jun 2026 at 14:45, Richard Duivenvoorde via QGIS-Developer 
>> <qgis-developer at lists.osgeo.org <mailto:qgis- 
>> developer at lists.osgeo.org>> wrote:
>>
>> ??? Personally I received a question from QGIS.org to confirm the 
>> email address(es) I use for my plugins.
>>
>> ??? As one of the mail admins, I receive a lot of 'no replies' from 
>> others. Because the person does not work there anymore or changed mail 
>> etc etc.
>>
>> ??? Any plans to do some communication around this? As I think we will 
>> remove or hide the plugins with unconfirmed mail addresses, I'm afraid 
>> people will miss some of the plugins.
>> ??? But also I would have missed this mail if not receiving all the 
>> 'returned' mails... :-)
>>
>>
>> ??? Another thing I want to bring up: having so many plugins now, 
>> would it be an idea to order the list based on: the number of stars, 
>> of number of downloads? Then at least plugins which earned some 
>> credits will be most viewable, instead of handy authors naming there 
>> plugins so that they appear upfront :-)
>>
>> ??? Regards,
>>
>> ??? Richard Duivenvoorde
>> ??? _______________________________________________
>> ??? QGIS-Developer mailing list
>> ??? QGIS-Developer at lists.osgeo.org <mailto:QGIS- 
>> Developer at lists.osgeo.org>
>> ??? List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>> ??? Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis- 
>> developer <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 marco.lechner at fossgis.de  Wed Jun 10 08:29:14 2026
From: marco.lechner at fossgis.de (Marco Lechner)
Date: Wed, 10 Jun 2026 17:29:14 +0200
Subject: [QGIS-Developer] Plugin authors, email confirmation,
 Plugins list
In-Reply-To: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
References: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
Message-ID: <E4CD8B23-F326-40EB-A8E2-59066BD7AFB3@fossgis.de>

Btw ist there a was to allow multiple Accounts (2, 3, 4, ...) to publish a Plugin to make sure the publication of a Plugin does not depend on a single Person.

Regards
Marco


Am 10. Juni 2026 13:45:42 MESZ schrieb Richard Duivenvoorde via QGIS-Developer <qgis-developer at lists.osgeo.org>:
>Personally I received a question from QGIS.org to confirm the email address(es) I use for my plugins.
>
>As one of the mail admins, I receive a lot of 'no replies' from others. Because the person does not work there anymore or changed mail etc etc.
>
>Any plans to do some communication around this? As I think we will remove or hide the plugins with unconfirmed mail addresses, I'm afraid people will miss some of the plugins.
>But also I would have missed this mail if not receiving all the 'returned' mails... :-)
>
>
>Another thing I want to bring up: having so many plugins now, would it be an idea to order the list based on: the number of stars, of number of downloads? Then at least plugins which earned some credits will be most viewable, instead of handy authors naming there plugins so that they appear upfront :-)
>
>Regards,
>
>Richard Duivenvoorde
>_______________________________________________
>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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/1fcc1312/attachment.htm>

From rdmailings at duif.net  Wed Jun 10 08:41:03 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Wed, 10 Jun 2026 17:41:03 +0200
Subject: [QGIS-Developer] Plugin authors, email confirmation,
 Plugins list
In-Reply-To: <54988202-ca57-4c99-b328-6cb79ea65cdf@borysjurgiel.pl>
References: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
 <CAMLC-sAeySjS5+wezvUJcYHCzS6CM+tZDRgBxriD0dtRgv+qAg@mail.gmail.com>
 <3245dc52-63fc-4bfa-aa3d-baa66b4677a7@duif.net>
 <54988202-ca57-4c99-b328-6cb79ea65cdf@borysjurgiel.pl>
Message-ID: <abad971b-7473-455b-a88d-9c733fdd8523@duif.net>

On 6/10/26 16:26, Borys Jurgiel via QGIS-Developer wrote:
>> And about the ordering, I meant the plugin manager in QGIS, not so much the plugins.qgis.org website. Sorry for the confusion.
>> Not sure IF the plugins manager has information to change the order based on the options I mentioned though...
> 
> Well, it is implemented long time ago :) You can right-click on the plugin list to change the sort order. Also, we could easily (without any GUI changes) add a filter expressions to the search bar
> (e.g. "wfs votes:200 stars:4")

Ah, duh. Never used right click there... Thanks :-)

But then I would rephrase my feature request: change default order to ... Sort by Downloads?

Regards,

Richard


From rhurlin at gwdg.de  Wed Jun 10 08:55:49 2026
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Wed, 10 Jun 2026 17:55:49 +0200
Subject: [QGIS-Developer] QGIS 4: PostgreSQL layer properties
 'Information from provider' is not displayed correctly
In-Reply-To: <CAB28Ash2qwxnAeQqUNXep641JG5ta-J0LxCM+NZ13iFwXJ30Vw@mail.gmail.com>
References: <bd24d075-efdc-45fd-a2d9-dfa90677e0fe@gwdg.de>
 <CAB28Ash2qwxnAeQqUNXep641JG5ta-J0LxCM+NZ13iFwXJ30Vw@mail.gmail.com>
Message-ID: <72efc763-a59d-42ad-9d8b-c9220f0fe91e@gwdg.de>

Am 09.06.26 um 01:59 schrieb Nyall Dawson:
> On Fri, 5 Jun 2026 at 22:58, Rainer Hurling via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
>>
>> Dear Devs,
>> I was unable to attach a screenshot to a GitHub issue. Therefore, I am
>> describing the following issue here in the list, as it is difficult to
>> describe the error without an image.
>>
>> In QGIS 4, in released versions up to 4.0.3 as well as in today's devel
>> branch, the ?Information from provider? section in the properties of
>> PostgreSQL layers is displayed incorrectly. This happens in the browser
>> and also with loaded layers.
>>
>> Instead of the expected information under Privileges or Spatial Index, a
>> list of dots is displayed. Each dot in the list contains exactly one
>> character. All characters in a list appear to be SQL commands or
>> parameters? The attached screenshot shows a section where the display
>> error can be seen.
>>
>> This occurs on Windows 10, 11, and FreeBSD. In QGIS 3, the properties of
>> PostgreSQL layers are displayed correctly.
> 
> Fixed in https://github.com/qgis/QGIS/pull/66402

Many thanks. It works again as expected.

> Nyall
> 
>>
>> Best regards,
>> Rainer_______________________________________________
>> 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 lova at kartoza.com  Wed Jun 10 09:19:52 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 10 Jun 2026 19:19:52 +0300
Subject: [QGIS-Developer] Plugin authors, email confirmation,
 Plugins list
In-Reply-To: <54988202-ca57-4c99-b328-6cb79ea65cdf@borysjurgiel.pl>
References: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
 <CAMLC-sAeySjS5+wezvUJcYHCzS6CM+tZDRgBxriD0dtRgv+qAg@mail.gmail.com>
 <3245dc52-63fc-4bfa-aa3d-baa66b4677a7@duif.net>
 <54988202-ca57-4c99-b328-6cb79ea65cdf@borysjurgiel.pl>
Message-ID: <CAMLC-sBDkL4e9-nYxsygyYRrkyqig1G9PoD_FtVfB6Vp5gQd=w@mail.gmail.com>

Dear B.

By the way, I received an email at my regular address saying that that
> confirmation message had been sent to the email address associated with
> my plugins (it's a dedicated one). However, I never received that
> message (yes, I've checked the spam folder, and that address works fine
> in general ;)
>

>From the logs, the email bounced because our email provider (Resend) was
blocked. See details below.

```

smtp; 550-Message rejected: your email provider server
(<some_ip_address>) is listed on a
550-blacklist (automatic-spamtrap-based-rbl.aftermarket.pl). Please contact
550-your email provider.

```
Please let me know if it's possible to unblock it from your end and I would
be happy to resend the email.

Best regards,

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


On Wed, 10 Jun 2026 at 18:12, Borys Jurgiel via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

>
>
> W dniu 10.06.2026 o 15:05, Richard Duivenvoorde via QGIS-Developer pisze:
> > Thanks for the prompt answer Lova :-)
> >
> > Ah, I thought this was maybe part of the 'security'-scan for plugins,
> > from that comes my question.
> >
> > And about the ordering, I meant the plugin manager in QGIS, not so much
> > the plugins.qgis.org website. Sorry for the confusion.
> > Not sure IF the plugins manager has information to change the order
> > based on the options I mentioned though...
>
> Well, it is implemented long time ago :) You can right-click on the
> plugin list to change the sort order. Also, we could easily (without any
> GUI changes) add a filter expressions to the search bar
> (e.g. "wfs votes:200 stars:4")
>
> By the way, I received an email at my regular address saying that that
> confirmation message had been sent to the email address associated with
> my plugins (it's a dedicated one). However, I never received that
> message (yes, I've checked the spam folder, and that address works fine
> in general ;)
>
> Best regards,
> B.
>
> >
> > Thanks for all your work!!
> >
> > Richard
> >
> > On 6/10/26 14:20, Lova Andriarimalala wrote:
> >> Hi Richard,
> >>
> >> Thanks for raising this.
> >>
> >>     Any plans to do some communication around this? As I think we will
> >> remove or hide the plugins with unconfirmed mail addresses, I'm afraid
> >> people will miss some of the plugins.
> >>
> >>
> >> As raised many times in some PRs and changes, feedback was given about
> >> effectively communicating any upcoming changes on the plugin
> >> repository. So, the first step is to confirm that the email address
> >> provided by a plugin author in the metadata.txt is responsive
> >> according to the state on the plugin's upload page (https://
> >> plugins.qgis.org/plugins/add/ <https://plugins.qgis.org/plugins/add/>).
> >> If there's any plan to remove or hide plugins with unconfirmed mail
> >> addresses, I think we need to always try to communicate them in some
> >> other way (on the repository of the plugin, for example).
> >>
> >>     Another thing I want to bring up: having so many plugins now,
> >> would it be an idea to order the list based on: the number of stars,
> >> of number of downloads? Then at least plugins which earned some
> >> credits will be most viewable, instead of handy authors naming there
> >> plugins so that they appear upfront :-)
> >>
> >>
> >> I think this categorised list already exists, but maybe we could bring
> >> them on the upper level? So we would have "Popular plugins" or "Most
> >> downloaded" plugins instead of "All plugins" on the top bar and
> >> accessible from the "Explore" link.
> >>
> >> Best regards,
> >> Lova Andriarimalala
> >> *QGIS Full Stack Developer
> >>
> >> *
> >> *T *: +27(0) 87 809 2702 *E *:**lova at kartoza.com
> >> <mailto:lova at kartoza.com> *W* : kartoza.com <http://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./
> >>
> >>
> >> On Wed, 10 Jun 2026 at 14:45, Richard Duivenvoorde via QGIS-Developer
> >> <qgis-developer at lists.osgeo.org <mailto:qgis-
> >> developer at lists.osgeo.org>> wrote:
> >>
> >>     Personally I received a question from QGIS.org to confirm the
> >> email address(es) I use for my plugins.
> >>
> >>     As one of the mail admins, I receive a lot of 'no replies' from
> >> others. Because the person does not work there anymore or changed mail
> >> etc etc.
> >>
> >>     Any plans to do some communication around this? As I think we will
> >> remove or hide the plugins with unconfirmed mail addresses, I'm afraid
> >> people will miss some of the plugins.
> >>     But also I would have missed this mail if not receiving all the
> >> 'returned' mails... :-)
> >>
> >>
> >>     Another thing I want to bring up: having so many plugins now,
> >> would it be an idea to order the list based on: the number of stars,
> >> of number of downloads? Then at least plugins which earned some
> >> credits will be most viewable, instead of handy authors naming there
> >> plugins so that they appear upfront :-)
> >>
> >>     Regards,
> >>
> >>     Richard Duivenvoorde
> >>     _______________________________________________
> >>     QGIS-Developer mailing list
> >>     QGIS-Developer at lists.osgeo.org <mailto:QGIS-
> >> Developer at lists.osgeo.org>
> >>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> >>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-
> >> developer <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
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/35b97dbf/attachment-0001.htm>

From lova at kartoza.com  Wed Jun 10 09:22:02 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 10 Jun 2026 19:22:02 +0300
Subject: [QGIS-Developer] Plugin authors, email confirmation,
 Plugins list
In-Reply-To: <E4CD8B23-F326-40EB-A8E2-59066BD7AFB3@fossgis.de>
References: <346c0c22-ab35-4c3b-a53a-3e00d4d2562e@duif.net>
 <E4CD8B23-F326-40EB-A8E2-59066BD7AFB3@fossgis.de>
Message-ID: <CAMLC-sAJHzARrkJJE889=n_riAwN+jcucNved8E0WFn2+LqFYQ@mail.gmail.com>

Dear Marco,

Btw ist there a was to allow multiple Accounts (2, 3, 4, ...) to publish a
> Plugin to make sure the publication of a Plugin does not depend on a single
> Person.


Yes, you can add collaborators by clicking the "Edit" button on the plugin
details page.

Best regards,

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


On Wed, 10 Jun 2026 at 18:37, Marco Lechner via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Btw ist there a was to allow multiple Accounts (2, 3, 4, ...) to publish a
> Plugin to make sure the publication of a Plugin does not depend on a single
> Person.
>
> Regards
> Marco
>
>
> Am 10. Juni 2026 13:45:42 MESZ schrieb Richard Duivenvoorde via
> QGIS-Developer <qgis-developer at lists.osgeo.org>:
>
>> Personally I received a question from QGIS.org to confirm the email address(es) I use for my plugins.
>>
>> As one of the mail admins, I receive a lot of 'no replies' from others. Because the person does not work there anymore or changed mail etc etc.
>>
>> Any plans to do some communication around this? As I think we will remove or hide the plugins with unconfirmed mail addresses, I'm afraid people will miss some of the plugins.
>> But also I would have missed this mail if not receiving all the 'returned' mails... :-)
>>
>>
>> Another thing I want to bring up: having so many plugins now, would it be an idea to order the list based on: the number of stars, of number of downloads? Then at least plugins which earned some credits will be most viewable, instead of handy authors naming there plugins so that they appear upfront :-)
>>
>> Regards,
>>
>> Richard Duivenvoorde
>> ------------------------------
>> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260610/439fb082/attachment.htm>

From adenaculture at gmail.com  Thu Jun 11 16:03:59 2026
From: adenaculture at gmail.com (C Hamilton)
Date: Thu, 11 Jun 2026 19:03:59 -0400
Subject: [QGIS-Developer] How do I get rid of the security warning on my
 plugin?
Message-ID: <CABPxTTrEDi7GK2wH0QERJ4kM3xJWsVmjVCQQ4+tp3BiJPaBW9w@mail.gmail.com>

My Lat Lon Tools plugin is getting two "Secrets Detection" warnings on
these two lines of code.

lontile_ = "ABCDEFGHJKLMNPQRSTUVWXYZ"

__base32 = '0123456789bcdefghjkmnpqrstuvwxyz'

Those are certainly scarry, hazardous lines of code (sorry for the
sarchasm). But really how do I resolve this with your plugin scanners.
Those lines of code are probably the best way to represent the geohash, and
georef coordinate conversions. However, I also don't want my plugins to be
flagged with "Critical security issues found".

Thanks,
Calvin Hamilton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260611/1fe6761f/attachment.htm>

From gdt at lexort.com  Thu Jun 11 16:58:40 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 11 Jun 2026 19:58:40 -0400
Subject: [QGIS-Developer] How do I get rid of the security warning on my
 plugin?
In-Reply-To: <CABPxTTrEDi7GK2wH0QERJ4kM3xJWsVmjVCQQ4+tp3BiJPaBW9w@mail.gmail.com>
 (C. Hamilton via's message of "Thu, 11 Jun 2026 19:03:59 -0400")
References: <CABPxTTrEDi7GK2wH0QERJ4kM3xJWsVmjVCQQ4+tp3BiJPaBW9w@mail.gmail.com>
Message-ID: <rmi33yseij3.fsf@s1.lexort.com>

C Hamilton via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> My Lat Lon Tools plugin is getting two "Secrets Detection" warnings on
> these two lines of code.
>
> lontile_ = "ABCDEFGHJKLMNPQRSTUVWXYZ"
>
> __base32 = '0123456789bcdefghjkmnpqrstuvwxyz'
>
> Those are certainly scarry, hazardous lines of code (sorry for the
> sarchasm). But really how do I resolve this with your plugin scanners.
> Those lines of code are probably the best way to represent the geohash, and
> georef coordinate conversions. However, I also don't want my plugins to be
> flagged with "Critical security issues found".

By posting here, you request that the scanners be fixed.  They are
heuristics, which means they need tweaks when they are wrong.



From andreaerdna at libero.it  Fri Jun 12 05:21:00 2026
From: andreaerdna at libero.it (Andrea Giudiceandrea)
Date: Fri, 12 Jun 2026 14:21:00 +0200
Subject: [QGIS-Developer] Limiting 3.44 backports?
Message-ID: <0c508614-0313-4816-8349-faa071072339@libero.it>

Hi list,
anyway it looks like it is currently not possible to merge approved PRs 
in release-3_44 branch, due to the fact that the "Windows Qt6 / build 
(windows)" check is still running and failing [1] or it is still 
considered a required check while not actually running [2], although 
such workflow has been disabled [3].

Similarly, in PRs for in queued_ltr_backports the same workflow is still 
running (and failing) and it is considered a requested check, while it 
should be disabled.

Regards.

Andrea

[1] https://github.com/qgis/QGIS/pull/66325
[2] https://github.com/qgis/QGIS/pull/66417
[2] https://github.com/qgis/QGIS/pull/66378

From jostev at bgs.ac.uk  Fri Jun 12 06:32:28 2026
From: jostev at bgs.ac.uk (John Stevenson - BGS)
Date: Fri, 12 Jun 2026 13:32:28 +0000
Subject: [QGIS-Developer] How do I get rid of the security warning on my
 plugin?
In-Reply-To: <rmi33yseij3.fsf@s1.lexort.com>
References: <CABPxTTrEDi7GK2wH0QERJ4kM3xJWsVmjVCQQ4+tp3BiJPaBW9w@mail.gmail.com>
 <rmi33yseij3.fsf@s1.lexort.com>
Message-ID: <LO2P123MB5414DF0C1CAB0C8FAD466A7481182@LO2P123MB5414.GBRP123.PROD.OUTLOOK.COM>

You can put `# nosec` as a comment at the end of the line to skip that line.

See documentation for the Bandit scanner used by the QGIS Plugin repository here:

https://bandit.readthedocs.io/en/latest/config.html#suppressing-individual-lines

The scanner implementation, with details of the exact command that it runs (and that you can replicate locally or in CI), is here:

https://github.com/qgis/QGIS-Plugins-Website/blob/18bf205e1c0733bc1f09f15430eff52c1a78a1a3/qgis-app/plugins/security_scanner.py

Cheers,
John

-----Original Message-----
From: QGIS-Developer <qgis-developer-bounces at lists.osgeo.org> On Behalf Of Greg Troxel via QGIS-Developer
Sent: 12 June 2026 00:59
To: C Hamilton via QGIS-Developer <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] How do I get rid of the security warning on my plugin?

C Hamilton via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> My Lat Lon Tools plugin is getting two "Secrets Detection" warnings on
> these two lines of code.
>
> lontile_ = "ABCDEFGHJKLMNPQRSTUVWXYZ"
>
> __base32 = '0123456789bcdefghjkmnpqrstuvwxyz'
>
> Those are certainly scarry, hazardous lines of code (sorry for the
> sarchasm). But really how do I resolve this with your plugin scanners.
> Those lines of code are probably the best way to represent the
> geohash, and georef coordinate conversions. However, I also don't want
> my plugins to be flagged with "Critical security issues found".

By posting here, you request that the scanners be fixed.  They are heuristics, which means they need tweaks when they are wrong.


_______________________________________________
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


This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.


From etienne.trimaille at gmail.com  Fri Jun 12 13:06:40 2026
From: etienne.trimaille at gmail.com (Etienne Trimaille)
Date: Fri, 12 Jun 2026 22:06:40 +0200
Subject: [QGIS-Developer] How do I get rid of the security warning on my
 plugin?
In-Reply-To: <LO2P123MB5414DF0C1CAB0C8FAD466A7481182@LO2P123MB5414.GBRP123.PROD.OUTLOOK.COM>
References: <CABPxTTrEDi7GK2wH0QERJ4kM3xJWsVmjVCQQ4+tp3BiJPaBW9w@mail.gmail.com>
 <rmi33yseij3.fsf@s1.lexort.com>
 <LO2P123MB5414DF0C1CAB0C8FAD466A7481182@LO2P123MB5414.GBRP123.PROD.OUTLOOK.COM>
Message-ID: <CAMtDFLJ6DyAf_cKd5=vfV9cECmp5q7b37GSZQOz11TXoPx_sew@mail.gmail.com>

I think it might be "detect-secrets" instead of bandit in his situation, so
you can refer to it's documentation:
https://github.com/Yelp/detect-secrets#inline-allowlisting


Le ven. 12 juin 2026, 15:32, John Stevenson - BGS via QGIS-Developer <
qgis-developer at lists.osgeo.org> a ?crit :

> You can put `# nosec` as a comment at the end of the line to skip that
> line.
>
> See documentation for the Bandit scanner used by the QGIS Plugin
> repository here:
>
>
> https://bandit.readthedocs.io/en/latest/config.html#suppressing-individual-lines
>
> The scanner implementation, with details of the exact command that it runs
> (and that you can replicate locally or in CI), is here:
>
>
> https://github.com/qgis/QGIS-Plugins-Website/blob/18bf205e1c0733bc1f09f15430eff52c1a78a1a3/qgis-app/plugins/security_scanner.py
>
> Cheers,
> John
>
> -----Original Message-----
> From: QGIS-Developer <qgis-developer-bounces at lists.osgeo.org> On Behalf
> Of Greg Troxel via QGIS-Developer
> Sent: 12 June 2026 00:59
> To: C Hamilton via QGIS-Developer <qgis-developer at lists.osgeo.org>
> Subject: Re: [QGIS-Developer] How do I get rid of the security warning on
> my plugin?
>
> C Hamilton via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:
>
> > My Lat Lon Tools plugin is getting two "Secrets Detection" warnings on
> > these two lines of code.
> >
> > lontile_ = "ABCDEFGHJKLMNPQRSTUVWXYZ"
> >
> > __base32 = '0123456789bcdefghjkmnpqrstuvwxyz'
> >
> > Those are certainly scarry, hazardous lines of code (sorry for the
> > sarchasm). But really how do I resolve this with your plugin scanners.
> > Those lines of code are probably the best way to represent the
> > geohash, and georef coordinate conversions. However, I also don't want
> > my plugins to be flagged with "Critical security issues found".
>
> By posting here, you request that the scanners be fixed.  They are
> heuristics, which means they need tweaks when they are wrong.
>
>
> _______________________________________________
> 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
>
>
> This email and any attachments are intended solely for the use of the
> named recipients. If you are not the intended recipient you must not use,
> disclose, copy or distribute this email or any of its attachments and
> should notify the sender immediately and delete this email from your
> system. UK Research and Innovation (UKRI) has taken every reasonable
> precaution to minimise risk of this email or any attachments containing
> viruses or malware but the recipient should carry out its own virus and
> malware checks before opening the attachments. UKRI does not accept any
> liability for any losses or damages which the recipient may sustain due to
> presence of any viruses.
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260612/fbf0aeb7/attachment.htm>

From nsicad at gmail.com  Fri Jun 12 18:38:31 2026
From: nsicad at gmail.com (Noli Sicad)
Date: Sat, 13 Jun 2026 11:38:31 +1000
Subject: [QGIS-Developer] (no subject)
Message-ID: <CADs9uc_06LRW=JR8PRQdr20STQN9CzBjvppLRq8OuUbw293nDg@mail.gmail.com>



From mostafanehad188 at gmail.com  Mon Jun 15 00:48:53 2026
From: mostafanehad188 at gmail.com (Mustafa Elghaazaly)
Date: Mon, 15 Jun 2026 10:48:53 +0300
Subject: [QGIS-Developer] Reminder: Align Features to Path v10.2.0 Plugin
 Awaiting Review
Message-ID: <CAJ9EDjeZvmajB3o3SvRYWbgw5Ej+HUXcQwq6bseu+yoM8CEKtw@mail.gmail.com>

Dear QGIS Development Team,

I hope this message finds you well. I am writing to follow up on my
plugin submission for "Align Features to Path v10.2.0", which recently
passed all security and quality validation checks.

According to the validation notification, the plugin is now ready for
review by an approver. I would appreciate any update on the review
status or an estimated timeline for completion.

Plugin Details:
- Name: Align Features to Path
- Version: 10.2.0
- Status: Ready for Review
- Validation: 4 out of 5 checks passed
- Files Scanned: 30

Detailed Results:
https://plugins.qgis.org/plugins/align_features_to_path/version/10.2.0/#security-tab

Please let me know if you need any additional information from my end.

Thank you for your time and assistance.

Best regards,
Mustafa Elghazaly
mostafanehad188 at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260615/871ab64e/attachment.htm>

From nyall.dawson at gmail.com  Mon Jun 15 16:12:39 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 16 Jun 2026 09:12:39 +1000
Subject: [QGIS-Developer] QEP: Add Exceptional Breakage clause to stable
 API policy
In-Reply-To: <CAB28Asgx0-CUGom9sKv=b8xg6k5eQO2DnDagMTNpATBao8LkFg@mail.gmail.com>
References: <CAB28Asgx0-CUGom9sKv=b8xg6k5eQO2DnDagMTNpATBao8LkFg@mail.gmail.com>
Message-ID: <CAB28AsiZuf0i+VBJEwUPgZvEdZOmEwQEQyGTq+KLUqyB+uSPTw@mail.gmail.com>

On Thu, 4 Jun 2026 at 13:51, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>
> Hi lists,
>
> Following up the recent formalisation of the PyQGIS stable API policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-425-stable-api.md), I've just submitted a proposed change to this policy to add a mechanism to allow API breaks in EXCEPTIONAL circumstances.
>
> See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/384 for the proposed changes and a detailed write up on the rationale behind this change.
>
> Please give all feedback on this proposed change as comments on the PR itself (not direct email replies) to keep the discussion centralized.

This QEP has now progressed to the voting stage -- please cast your
votes accordingly!

Nyall

From florian.schimmel at sap.com  Mon Jun 15 23:59:38 2026
From: florian.schimmel at sap.com (Schimmel, Florian)
Date: Tue, 16 Jun 2026 06:59:38 +0000
Subject: [QGIS-Developer] SAP HANA on MacOS
In-Reply-To: <PAVPR02MB9497C19AFC727BCDFA47A5D2900F2@PAVPR02MB9497.eurprd02.prod.outlook.com>
References: <PAVPR02MB949786D8A35441FA2A1EBB85909EA@PAVPR02MB9497.eurprd02.prod.outlook.com>
 <CAC7zN96JrUKLpWgkH=_2o-5OghApuXyX+COn9oh939NhLnbTdA@mail.gmail.com>
 <PAVPR02MB949757440D4C89447EB239C5906BA@PAVPR02MB9497.eurprd02.prod.outlook.com>
 <c826b9d0-96a9-4e10-8d2b-0e89f5a678ec@spatialys.com>
 <PAVPR02MB94970DBBB1BCBDFD430E910A9068A@PAVPR02MB9497.eurprd02.prod.outlook.com>
 <PAVPR02MB9497C19AFC727BCDFA47A5D2900F2@PAVPR02MB9497.eurprd02.prod.outlook.com>
Message-ID: <PAVPR02MB94978CC6C5A395B097912B4C90E52@PAVPR02MB9497.eurprd02.prod.outlook.com>

Hey,

I noticed that the vcpkg commit hash was updated, so I added the odbccpp library in another change<https://github.com/qgis/QGIS/pull/66470>. I hope this works and makes it able to cache in in nuget. I hope this is fine, let me know if there is something missing.

Best regards,
Florian

From: Schimmel, Florian <florian.schimmel at sap.com>
Date: Friday, 22. May 2026 at 15:21
To: Even Rouault <even.rouault at spatialys.com>; Matthias Kuhn <matthias at opengis.ch>
Cc: qgis-developer at lists.osgeo.org <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] SAP HANA on MacOS

Hey,

It was a bit of a hassle and took a while to add the odbccpp package to vcpkg<https://github.com/microsoft/vcpkg/pull/50152>, but it is now available. I created a change to include it in QGIS by vcpkg, but bumping up the vcpkg commit hash didn?t work because goal can?t build with the newest version of poppler. For me, it seems like a known problem and the best solution would bet to wait for the updates of the packages in vcpkg. I will add the odbccpp wrapper by vcpkg when this is solved.

In the meantime, I added already a change to enable HANA<https://github.com/qgis/QGIS/pull/66205>, I hope this is fine. Let me know, if there are any issues.

Best regards,
Florian

From: Schimmel, Florian <florian.schimmel at sap.com>
Date: Friday, 20. February 2026 at 15:47
To: Even Rouault <even.rouault at spatialys.com>; Matthias Kuhn <matthias at opengis.ch>
Cc: qgis-developer at lists.osgeo.org <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] SAP HANA on MacOS

Hey Even,

Thanks for the hint, that makes sense. I will add it to the vcpkg repo and note this thread again after it is merged and the QGIS change is pushed.

Best regards
Florian

From: Even Rouault <even.rouault at spatialys.com>
Date: Friday, 20. February 2026 at 01:37
To: Schimmel, Florian <florian.schimmel at sap.com>, Matthias Kuhn <matthias at opengis.ch>
Cc: qgis-developer at lists.osgeo.org <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] SAP HANA on MacOS

You don't often get email from even.rouault at spatialys.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


Le 19/02/2026 ? 18:04, Schimmel, Florian via QGIS-Developer a ?crit :
Hey Matthias,

thank you for the reply, I like the idea and tried to implement it. I had to work into vcpkg and solve a few issues on the way, that took a while, but I have a working port now. While checking if it is possible to integrate the port in the QGIS build I noticed that there are custom ports in the repository. Since odbccpp is not broadly used, there is probably no application for a vcpkg port outside of QGIS, so would you mind if we add the port directly to the QGIS repository?

The GDAL HANA driver depends on odbccpp too, so for GDAL vcpkg users, having a standalone port could make sense

--
http://www.spatialys.com<http://www.spatialys.com/>
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260616/ff4a277e/attachment-0001.htm>

From lauri.kajan at gmail.com  Wed Jun 17 00:47:43 2026
From: lauri.kajan at gmail.com (Lauri Kajan)
Date: Wed, 17 Jun 2026 10:47:43 +0300
Subject: [QGIS-Developer] Potential data loss issue with PostgreSQL JSONB
 and buffered transactions
Message-ID: <CAKWoFMKpXSxnSn6j3jtZCJ2oAbqFo_ZsFhTiQtUCB=qKny8_qA@mail.gmail.com>

Hi everyone,

First of all, thank you for all the time and effort you put into QGIS.

I opened an issue about a month ago and I know there is a lot on everyone's
plate, but I wanted to highlight it here since it involves silent data loss.

Basically, when saving two or more new features to a geometryless
PostgreSQL layer at the same time using buffered transactions, JSONB fields
are not saved at all. They just end up as NULL in the database. If you save
one feature at a time, it works perfectly.

Could someone take a quick look and let me know if you can reproduce this?
I want to make sure this is actually a bug in QGIS and not just some
specific issue on my end.

I included a short Python snippet in the bug report that makes it easy to
test. You can find the full details here:
https://github.com/qgis/QGIS/issues/65323


Thanks for your time!

Best,
Lauri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260617/9bc52818/attachment.htm>

From r.nijssen at terglobo.nl  Wed Jun 17 09:40:20 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Wed, 17 Jun 2026 18:40:20 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
Message-ID: <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>

Hi, I'm having this security issue with Bandit and cannot publish my 
plugin. But the executeSql() does not take separate parameters. What 
would be the proper solution here?


Possible SQL injection vector through string-based query construction.
104             q = f'DELETE FROM imaer_metadata WHERE key = \'{key}\';'
105             self.conn.executeSql(q)


(Instead of putting # nosec behind the lines as explained here:
https://lists.osgeo.org/pipermail/qgis-developer/2026-June/068337.html
)

Regards,
Raymond


On 4/23/26 14:58, Johannes Kr?ger (WhereGroup) via QGIS-Developer wrote:
> Hi,
> 
> the plugins repository now *publicly* denounces plugins when its 
> security scan has flagged something.
> I use the word "denounce" aggressively here because as a plugin 
> developer it is not nice to have plugins *which do not actually have 
> security issues* brandished insecure with a BIG RED WARNING, losing 
> trust of their users.
> 
> The rules are not perfect and at least for plugins where I have insight 
> the false positive rate is higher than the correct flags...
> For example it flags any requests.get() call without a timeout. The 
> worst that can happen is a hanging QGIS, big whoop...
> It also flags hashes as secrets and I fail to see how this is helpful 
> for plugins that are *already published and accessible*.
> 
> Please revert the public display of this badge for now. If it is planned 
> to publicly flag existing plugin versions, give developers ample time to 
> review, fix or dispute the findings.
> 
> Sorry for the aggressive tone but this was unexpected and is very 
> unpleasant to deal with.
> I do think that the scanning and potential blocking of new versions is a 
> great feature (thank you for it!) but the retrospective scanning with 
> public display without human validation is not.
> 
> Cheers, Hannes
> 
> 
> _______________________________________________
> 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 even.rouault at spatialys.com  Wed Jun 17 09:48:31 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 17 Jun 2026 18:48:31 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
Message-ID: <2962d09a-db0c-4de9-aaec-d277fd20aba6@spatialys.com>


Le 17/06/2026 ? 18:40, Raymond Nijssen via QGIS-Developer a ?crit?:
> Hi, I'm having this security issue with Bandit and cannot publish my 
> plugin. But the executeSql() does not take separate parameters. What 
> would be the proper solution here?
>
>
> Possible SQL injection vector through string-based query construction.
> 104???????????? q = f'DELETE FROM imaer_metadata WHERE key = \'{key}\';'
> 105???????????? self.conn.executeSql(q)


Maybe instead?of key, use escaped_key = key.replace("'", "''") (ie 
replacing single quote by single quote repeated twice)

That should be enough to avoid SQL injection, but no idea if Bandit will 
be smart enough to recognize this

Some DB backends might have different escaping rules than the above 
standard SQL92?one, so it might be tricky to do that safely against an 
arbitrary backend.

-- 
http://www.spatialys.com
My software is free, but my time generally not.


From julien.moura at oslandia.com  Wed Jun 17 10:47:51 2026
From: julien.moura at oslandia.com (Julien Moura (Oslandia))
Date: Wed, 17 Jun 2026 19:47:51 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <2962d09a-db0c-4de9-aaec-d277fd20aba6@spatialys.com>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <2962d09a-db0c-4de9-aaec-d277fd20aba6@spatialys.com>
Message-ID: <8238e2ba-812f-4d0a-b822-c181c2b42f0b@oslandia.com>

Hi Raymond,

Sure, it's one of the irrelevant security warnings which have been 
blindly applied as blocking. Good news: it's already identified and also 
improved by the fantastic work of Lova! See: 
https://github.com/qgis/QGIS-Plugins-Website/pull/316#discussion_r3342025056

Julien


Le 17/06/2026 ? 18:48, Even Rouault via QGIS-Developer a ?crit?:
>
> Le 17/06/2026 ? 18:40, Raymond Nijssen via QGIS-Developer a ?crit?:
>> Hi, I'm having this security issue with Bandit and cannot publish my 
>> plugin. But the executeSql() does not take separate parameters. What 
>> would be the proper solution here?
>>
>>
>> Possible SQL injection vector through string-based query construction.
>> 104???????????? q = f'DELETE FROM imaer_metadata WHERE key = \'{key}\';'
>> 105???????????? self.conn.executeSql(q)
>
>
> Maybe instead?of key, use escaped_key = key.replace("'", "''") (ie 
> replacing single quote by single quote repeated twice)
>
> That should be enough to avoid SQL injection, but no idea if Bandit 
> will be smart enough to recognize this
>
> Some DB backends might have different escaping rules than the above 
> standard SQL92?one, so it might be tricky to do that safely against an 
> arbitrary backend.
>
-- 
Oslandia 
<https://oslandia.com/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email> 
- Livre blanc pour migrer/hybrider son SIG 
<https://oslandia.com/livre-blanc-migration-sig-opensource/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>

From r.nijssen at terglobo.nl  Wed Jun 17 10:47:02 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Wed, 17 Jun 2026 19:47:02 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <2962d09a-db0c-4de9-aaec-d277fd20aba6@spatialys.com>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <2962d09a-db0c-4de9-aaec-d277fd20aba6@spatialys.com>
Message-ID: <002f36f8-7f52-4f6d-aea6-f9c50b4a7f56@terglobo.nl>

Thanks for the suggestion Even. But there's really no danger for SQL 
injections. The plugin simply reads and writes values to a local 
geopackage. There's no user input or user form involved. And even if 
there was, a user would simply destroy it's own gpkg, which can easier 
be done by simply deleting it in the file browser.

I fixed it by using the `# nosec` comment behind all the lines with SQL 
strings. Feels a bit strange though to "fix" things that are not bad or 
broken at all.

Kind regards,
Raymond


On 6/17/26 18:48, Even Rouault wrote:
> 
> Le 17/06/2026 ? 18:40, Raymond Nijssen via QGIS-Developer a ?crit?:
>> Hi, I'm having this security issue with Bandit and cannot publish my 
>> plugin. But the executeSql() does not take separate parameters. What 
>> would be the proper solution here?
>>
>>
>> Possible SQL injection vector through string-based query construction.
>> 104???????????? q = f'DELETE FROM imaer_metadata WHERE key = \'{key}\';'
>> 105???????????? self.conn.executeSql(q)
> 
> 
> Maybe instead?of key, use escaped_key = key.replace("'", "''") (ie 
> replacing single quote by single quote repeated twice)
> 
> That should be enough to avoid SQL injection, but no idea if Bandit will 
> be smart enough to recognize this
> 
> Some DB backends might have different escaping rules than the above 
> standard SQL92?one, so it might be tricky to do that safely against an 
> arbitrary backend.
> 


From clhermansen at gmail.com  Wed Jun 17 12:18:10 2026
From: clhermansen at gmail.com (chris hermansen)
Date: Wed, 17 Jun 2026 12:18:10 -0700
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <002f36f8-7f52-4f6d-aea6-f9c50b4a7f56@terglobo.nl>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <2962d09a-db0c-4de9-aaec-d277fd20aba6@spatialys.com>
 <002f36f8-7f52-4f6d-aea6-f9c50b4a7f56@terglobo.nl>
Message-ID: <CACc2_6-Mj8XgmH2gA4jYwxhKwDzY01MtNAHOCo2FcNOytQrPMg@mail.gmail.com>

Everyone, asking a question here related to Raymond Nijssen's challenge...

On Wed, Jun 17, 2026 at 12:06?PM Raymond Nijssen via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

[snip]

>
> I fixed it by using the `# nosec` comment behind all the lines with SQL
> strings. Feels a bit strange though to "fix" things that are not bad or
> broken at all.
>
> >
> > Le 17/06/2026 ? 18:40, Raymond Nijssen via QGIS-Developer a ?crit :
> >> Hi, I'm having this security issue with Bandit and cannot publish my
> >> plugin. But the executeSql() does not take separate parameters. What
> >> would be the proper solution here?


Is there really no prepared statement approach that could be used in cases
like this, instead of an "executeSql() that does not take separate
parameters"?


-- 
Chris Hermansen ? clhermansen "at" gmail "dot" com

C'est ma fa?on de parler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260617/23da2dcc/attachment-0001.htm>

From julien.cabieces at oslandia.com  Thu Jun 18 01:56:56 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Thu, 18 Jun 2026 10:56:56 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl> (Raymond
 Nijssen via's message of "Wed, 17 Jun 2026 18:40:20 +0200")
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
Message-ID: <87v7bgw7jb.fsf@julienlaptop.home>


Hi all,

One way to fix it is to add a "execute_sql" function that wraps the call
to executeSql

def execute_sql(self, sql, *params):
    sql = sql.format(*params)
    self.conn.executeSql(q)

It's just another workaround, but I'd say it's still better than #noseq
IMHO, being able to just write #noseq on every line that raise security
error makes the security scan quite useless. We should probably remove
the #noseq possibility in the long term.

The good way to go would be to adapt our API so executeSql takes
parameters.

I don't think this warning is irrelevant. If you take some input from
the user, there is a possibility of user injection. In this
case, there is maybe no strong harm but there is no way to automatically
decide if it's harmful or not.

Regards,
Julien



> Hi, I'm having this security issue with Bandit and cannot publish my
> plugin. But the executeSql() does not take separate parameters. What
> would be the proper solution here?
>
>
> Possible SQL injection vector through string-based query construction.
> 104             q = f'DELETE FROM imaer_metadata WHERE key = \'{key}\';'
> 105             self.conn.executeSql(q)
>
>
> (Instead of putting # nosec behind the lines as explained here:
> https://lists.osgeo.org/pipermail/qgis-developer/2026-June/068337.html
> )
>
> Regards,
> Raymond
>
>
> On 4/23/26 14:58, Johannes Kr?ger (WhereGroup) via QGIS-Developer wrote:
>> Hi,
>> the plugins repository now *publicly* denounces plugins when its
>> security scan has flagged something.
>> I use the word "denounce" aggressively here because as a plugin
>> developer it is not nice to have plugins *which do not actually have
>> security issues* brandished insecure with a BIG RED WARNING, losing
>> trust of their users.
>> The rules are not perfect and at least for plugins where I have
>> insight the false positive rate is higher than the correct flags...
>> For example it flags any requests.get() call without a timeout. The
>> worst that can happen is a hanging QGIS, big whoop...
>> It also flags hashes as secrets and I fail to see how this is
>> helpful for plugins that are *already published and accessible*.
>> Please revert the public display of this badge for now. If it is
>> planned to publicly flag existing plugin versions, give developers
>> ample time to review, fix or dispute the findings.
>> Sorry for the aggressive tone but this was unexpected and is very
>> unpleasant to deal with.
>> I do think that the scanning and potential blocking of new versions
>> is a great feature (thank you for it!) but the retrospective
>> scanning with public display without human validation is not.
>> Cheers, Hannes
>> _______________________________________________
>> 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

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com

From nyall.dawson at gmail.com  Thu Jun 18 16:44:45 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 19 Jun 2026 09:44:45 +1000
Subject: [QGIS-Developer] Requiring signed commits?
Message-ID: <CAB28Asg8V6YV-yCBaa1RN3N9gn0aGWtLA5Lvgw83mzdvQG=Ppg@mail.gmail.com>

Hi list,

Does anyone have any issues if I turn on this branch protection setting? Is
there ANY valid reason someone isn't using signed commits today?

Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260619/1d4b21da/attachment.htm>

From even.rouault at spatialys.com  Thu Jun 18 17:10:55 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Fri, 19 Jun 2026 02:10:55 +0200
Subject: [QGIS-Developer] Requiring signed commits?
In-Reply-To: <CAB28Asg8V6YV-yCBaa1RN3N9gn0aGWtLA5Lvgw83mzdvQG=Ppg@mail.gmail.com>
References: <CAB28Asg8V6YV-yCBaa1RN3N9gn0aGWtLA5Lvgw83mzdvQG=Ppg@mail.gmail.com>
Message-ID: <f54f0cf4-81fe-4166-96c6-4eedc48f7183@spatialys.com>

Nyall,

I've some doubts at what you're talking about exactly, given that 
looking at https://github.com/qgis/QGIS/commits/master/ , your own 
commits don't appear to be signed ;-)? Is that commits signed with a GPG 
key 
(https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) 
that appear with the "Verified" green label ?? Browsing recent commit 
history, it seems only a minority of devs have that set up currently, so 
we should allow for some grace period. I don't think that would be an 
obstacle for regular contributors, but that might be more problematic 
for drive-by contributors.? I'm not aware of other projects in our close 
surroundings that mandate that currently.

Do you have particular reasons for that ? To prevent identity theft?

Even

Le 19/06/2026 ? 01:44, Nyall Dawson via QGIS-Developer a ?crit?:
> Hi list,
>
> Does anyone have any issues if I turn on this branch protection 
> setting? Is there ANY valid reason someone isn't using signed commits 
> today?
>
> 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.
Middle finger at you AI companies whose bots are destroying the remains of the open Internet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260619/4726a7a9/attachment.htm>

From johannes.kroeger at wheregroup.com  Fri Jun 19 00:49:33 2026
From: johannes.kroeger at wheregroup.com (=?UTF-8?Q?Johannes_Kr=C3=B6ger_=28WhereGroup=29?=)
Date: Fri, 19 Jun 2026 09:49:33 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <87v7bgw7jb.fsf@julienlaptop.home>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <87v7bgw7jb.fsf@julienlaptop.home>
Message-ID: <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>

Hi everyone,

the actual issue here is that the scan does not know the full context 
and rightfully suggests that a *possible* issue exists.
Isn't the #noseq tag exactly the correct mechanism to solve this? If the 
human knows that something looks like an issue, but they are sure it is 
not an issue, then they should be able to mark it.

You can even annotate the line with the exact test that you want to 
skip, e.g.:

... #noseq B806
... #noseq hardcoded_sql_expressions

I strongly disagree with making the code more complicated and harder to 
read, just to make the scanner not see potential issues.?Functionally, 
that would just be obfuscation or distraction. The code would be as 
"insecure" as before, just less obviously so to both the scanner and the 
human.

Parameter support for executeSql would be great! In the meantime I can 
recommend psycopg's https://www.psycopg.org/docs/sql.html#module-usage / 
https://www.psycopg.org/psycopg3/docs/api/sql.html#module-usage , it's 
verbose but fairly straightforward.

Cheers, Hannes

On 6/18/26 10:56, Julien Cabieces via QGIS-Developer wrote:
> Hi all,
>
> One way to fix it is to add a "execute_sql" function that wraps the call
> to executeSql
>
> def execute_sql(self, sql, *params):
>      sql = sql.format(*params)
>      self.conn.executeSql(q)
>
> It's just another workaround, but I'd say it's still better than #noseq
> IMHO, being able to just write #noseq on every line that raise security
> error makes the security scan quite useless. We should probably remove
> the #noseq possibility in the long term.
>
> The good way to go would be to adapt our API so executeSql takes
> parameters.
>
> I don't think this warning is irrelevant. If you take some input from
> the user, there is a possibility of user injection. In this
> case, there is maybe no strong harm but there is no way to automatically
> decide if it's harmful or not.
>
> Regards,
> Julien


From benjamin.jakimow at geo.hu-berlin.de  Fri Jun 19 01:52:40 2026
From: benjamin.jakimow at geo.hu-berlin.de (Benjamin Jakimow)
Date: Fri, 19 Jun 2026 10:52:40 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <87v7bgw7jb.fsf@julienlaptop.home>
 <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
Message-ID: <ddf06060-8261-4fbc-83a8-a7d3a09658c4@geo.hu-berlin.de>

Dear all,

another example is the use of `exec` in justified cases (Bandit B102)

We have plugins in which scientific users are able to use Python and 
Numpy code to modify their data. This allows them to quickly check the 
effects of their code changes and, if necessary, incorporate them later 
into their own Python/NumPy data crunching code. Python is the 
Domain-Specific-Language of choice, but similar to running it in the 
QGIS Python shell, we need to call exec to run it in our plugin.

Replacing `compile` + `exec` with, let's say QGIS Field Expressions as a 
domain-specific language, is technically not feasible, as we cannot 
modify multidimensional arrays with it and it's harder to transfer into 
other workflows.

It would therefore be helpful if such cases could be marked as 
?explicitly requested? if a reason is provided. Similar to what we know 
from other app stores ("this app requires access of your camera"), the 
QGIS plugin repository may provide information like "this plugin 
requires to execute arbitrary code".

Greetings,
Benjamin

On 19.06.26 09:49, Johannes Kr?ger (WhereGroup) via QGIS-Developer wrote:
> Hi everyone,
> 
> the actual issue here is that the scan does not know the full context 
> and rightfully suggests that a *possible* issue exists.
> Isn't the #noseq tag exactly the correct mechanism to solve this? If the 
> human knows that something looks like an issue, but they are sure it is 
> not an issue, then they should be able to mark it.
> 
> You can even annotate the line with the exact test that you want to 
> skip, e.g.:
> 
> ... #noseq B806
> ... #noseq hardcoded_sql_expressions
> 
> I strongly disagree with making the code more complicated and harder to 
> read, just to make the scanner not see potential issues.?Functionally, 
> that would just be obfuscation or distraction. The code would be as 
> "insecure" as before, just less obviously so to both the scanner and the 
> human.
> 
> Parameter support for executeSql would be great! In the meantime I can 
> recommend psycopg's https://www.psycopg.org/docs/sql.html#module-usage / 
> https://www.psycopg.org/psycopg3/docs/api/sql.html#module-usage , it's 
> verbose but fairly straightforward.
> 
> Cheers, Hannes
> 
> On 6/18/26 10:56, Julien Cabieces via QGIS-Developer wrote:
>> Hi all,
>>
>> One way to fix it is to add a "execute_sql" function that wraps the call
>> to executeSql
>>
>> def execute_sql(self, sql, *params):
>> ???? sql = sql.format(*params)
>> ???? self.conn.executeSql(q)
>>
>> It's just another workaround, but I'd say it's still better than #noseq
>> IMHO, being able to just write #noseq on every line that raise security
>> error makes the security scan quite useless. We should probably remove
>> the #noseq possibility in the long term.
>>
>> The good way to go would be to adapt our API so executeSql takes
>> parameters.
>>
>> I don't think this warning is irrelevant. If you take some input from
>> the user, there is a possibility of user injection. In this
>> case, there is maybe no strong harm but there is no way to automatically
>> decide if it's harmful or not.
>>
>> Regards,
>> Julien
> 
> _______________________________________________
> 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

-- 
Dr. Benjamin Jakimow
Earth Observation Lab | Geography Department | Humboldt-Universit?t zu 
Berlin

e-mail: benjamin.jakimow at geo.hu-berlin.de

phone:  +49 (0) 30 2093 45846
mobile: +49 (0) 157 5656 8477

mail:   Unter den Linden 6 | 10099 Berlin | Germany
matrix: @jakimowb:hu-berlin.de
web:    https://eolab.geographie.hu-berlin.de/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4284 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260619/62245665/attachment-0001.bin>

From gdt at lexort.com  Fri Jun 19 03:57:07 2026
From: gdt at lexort.com (Greg Troxel)
Date: Fri, 19 Jun 2026 06:57:07 -0400
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com> ("Johannes
 =?utf-8?Q?Kr=C3=B6ger?= (WhereGroup) via QGIS-Developer"'s message of "Fri,
 19 Jun 2026 09:49:33 +0200")
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <87v7bgw7jb.fsf@julienlaptop.home>
 <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
Message-ID: <rmijyruer24.fsf@s1.lexort.com>

What feels missing from this discussion is stepping back and considering
why we have escurity rules and the extent to which users are supposed to
be protected from bad behavior by plugins.  plugins execute code with
the user's privileges, essentially creating
  https://en.wikipedia.org/wiki/Confused_deputy_problem


It seems there is some intent to have a semi-/mostly-sandbox, where
plugins can operate within qgis on the user's data, but not extend to
operating system actions that could remove or write other files.


A check that is misfiring because it doesn't (can't) understand that
code, such as when static analysis says that the SQL arguments are ok,
is one thing.   But saying "it's ok for this plugin to run arbitrary
commands" raises the question of what policy did we want, does the
plugin meet it, and if not why are we saying that's ok.

It starts to feel like perl's taint method; running a command the user
entered is one thing, vs one that came from elsewhere.

Perhaps instead of failing plugins and then a culture of ignoring valid
results, we should allow annotations of two kinds; A) true scanning
false positive (where the scanner is wrong), and B) "the scanner is
right but [because] we are deciding the situation is ok", leading to

  red: scanner failed, not published
  yellow: at least one type B annotation
  green: no type B annotations

But, it might be that there could be code in the plugin that could
escape the sandbox, that wasn't scanned for.


I may be off base, but it feels like we're debating the big policy at the
micro level based on perceived desired outcomes and deciding to be
comfortable with specific plugin behavior because it's useful.  (Note
that leaving all the doors unlocked is more convenient!)

From etienne.trimaille at gmail.com  Fri Jun 19 04:28:19 2026
From: etienne.trimaille at gmail.com (Etienne Trimaille)
Date: Fri, 19 Jun 2026 13:28:19 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <87v7bgw7jb.fsf@julienlaptop.home>
 <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
Message-ID: <CAMtDFLLBovTLMZ3f0vL5-sqvT8k8dRgEtR+Xo53CQJ7ygr7cKA@mail.gmail.com>

Hi,

Le ven. 19 juin 2026 ? 09:49, Johannes Kr?ger (WhereGroup) via
QGIS-Developer <qgis-developer at lists.osgeo.org> a ?crit :

> In the meantime I can recommend psycopg's


Personally, I would not use Psycopg, as it will bypass QGIS settings, and
mainly queries will not be shown in QGIS logs and/or in the PostgreSQL log
panel, which is IMHO quite nice. Like in the webbrowser, in the dev tools,
we can see "all" requests, loading scripts etc.

Even if the plugin is doing some work under the hood, it's important to see
outgoing requests made when loading QGIS, loading a project, panning on the
map etc ...

As Julien said, It seems that just a call to "format" with a Python
dictionary might be enough for now :

sql = "SELECT * FROM {schema}.foo"params = {
    "schema": "test",
}sql = sql.format(**params)

This snippet looks fine for Bandit.

I also agree with Julien with the usage of "nosec". It depends on the final
purpose of these checks, but if the idea is to "control" a little bit what
the plugin can do, indeed, to disable "nosec" etc should be the way to go,
otherwise developers won't care anymore about these checks.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260619/beae19df/attachment.htm>

From gdt at lexort.com  Fri Jun 19 05:21:18 2026
From: gdt at lexort.com (Greg Troxel)
Date: Fri, 19 Jun 2026 08:21:18 -0400
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <CAMtDFLLBovTLMZ3f0vL5-sqvT8k8dRgEtR+Xo53CQJ7ygr7cKA@mail.gmail.com>
 (Etienne Trimaille via's message of "Fri, 19 Jun 2026 13:28:19 +0200")
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <87v7bgw7jb.fsf@julienlaptop.home>
 <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
 <CAMtDFLLBovTLMZ3f0vL5-sqvT8k8dRgEtR+Xo53CQJ7ygr7cKA@mail.gmail.com>
Message-ID: <rmi7bnuen5t.fsf@s1.lexort.com>

Etienne Trimaille via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> As Julien said, It seems that just a call to "format" with a Python
> dictionary might be enough for now :
>
> sql = "SELECT * FROM {schema}.foo"params = {
>     "schema": "test",
> }sql = sql.format(**params)

(That code is hard to read given likely bad HTML formatting, but I get
the point.)

How is this different from telling the scanner to ignore it?  It seems
like laundering input via steps the scanner doesn't follow.

From strk at kbt.io  Sun Jun 21 12:10:13 2026
From: strk at kbt.io (Sandro Santilli)
Date: Sun, 21 Jun 2026 21:10:13 +0200
Subject: [QGIS-Developer] QEP426: Demotion of DB Manager plugin to
 community plugin
In-Reply-To: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>
References: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>
Message-ID: <ajg3FSR6_WoCrbyQ@oli>

On Tue, Jun 09, 2026 at 06:58:40AM +1000, Nyall Dawson via QGIS-Developer wrote:

> As of QGIS 4.2, the core functionality of the DB Manager has been fully
> ported to the built-in Browser Panel.

Does it mean TopologyViewer was also ported ?
That part was the focus of https://github.com/qgis/QGIS-Enhancement-Proposals/pull/360

--strk;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260621/cb270718/attachment.sig>

From even.rouault at spatialys.com  Sun Jun 21 12:45:52 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Sun, 21 Jun 2026 21:45:52 +0200
Subject: [QGIS-Developer] QEP426: Demotion of DB Manager plugin to
 community plugin
In-Reply-To: <ajg3FSR6_WoCrbyQ@oli>
References: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>
 <ajg3FSR6_WoCrbyQ@oli>
Message-ID: <ce873c27-5517-4cc4-a367-cd7d55c2ea9a@spatialys.com>


Le 21/06/2026 ? 21:10, Sandro Santilli via QGIS-Developer a ?crit?:
> On Tue, Jun 09, 2026 at 06:58:40AM +1000, Nyall Dawson via QGIS-Developer wrote:
>
>> As of QGIS 4.2, the core functionality of the DB Manager has been fully
>> ported to the built-in Browser Panel.
> Does it mean TopologyViewer was also ported ?
> That part was the focus of https://github.com/qgis/QGIS-Enhancement-Proposals/pull/360

$ grep -ri topo src/core/browser/

(empty output)

-- 
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming and brain rot


From julien.cabieces at oslandia.com  Mon Jun 22 00:20:52 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Mon, 22 Jun 2026 09:20:52 +0200
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <rmi7bnuen5t.fsf@s1.lexort.com> (Greg Troxel via's message of
 "Fri, 19 Jun 2026 08:21:18 -0400")
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <87v7bgw7jb.fsf@julienlaptop.home>
 <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
 <CAMtDFLLBovTLMZ3f0vL5-sqvT8k8dRgEtR+Xo53CQJ7ygr7cKA@mail.gmail.com>
 <rmi7bnuen5t.fsf@s1.lexort.com>
Message-ID: <87jyrrm46j.fsf@julienlaptop.home>


Hi, 

> How is this different from telling the scanner to ignore it?  It seems
> like laundering input via steps the scanner doesn't follow.

It's not that much different I agree, but I least you have to spend a
few minutes to think how you could fix (if possible) this security
issue. If you just have to write #noseq, I'm afraid it would be the easy
way to solve any security issues and the scanner would become completely
useless.

I think we could:
- accept the #noseq for now
- think and document appropriate ways to fix every type of issue nicely (adding parameters for
executeSql for instance)
- Point plugin developers to this documentation when there are security
issues (or code contains #noseq)
- disable #noseq for each issue type individually when there is an
alternative (and after a long enough periode of time)


Regards,
Julien



> Etienne Trimaille via QGIS-Developer <qgis-developer at lists.osgeo.org>
> writes:
>
>> As Julien said, It seems that just a call to "format" with a Python
>> dictionary might be enough for now :
>>
>> sql = "SELECT * FROM {schema}.foo"params = {
>>     "schema": "test",
>> }sql = sql.format(**params)
>
> (That code is hard to read given likely bad HTML formatting, but I get
> the point.)
>
> How is this different from telling the scanner to ignore it?  It seems
> like laundering input via steps the scanner doesn't follow.
> _______________________________________________
> 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 gdt at lexort.com  Mon Jun 22 04:49:13 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 22 Jun 2026 07:49:13 -0400
Subject: [QGIS-Developer] Existing plugin versions should not be marked
 with "security issues"
In-Reply-To: <87jyrrm46j.fsf@julienlaptop.home> (Julien Cabieces's message of
 "Mon, 22 Jun 2026 09:20:52 +0200")
References: <bda7c8c4-e7a0-4bcb-8e8c-e34da07a4826@wheregroup.com>
 <2f3c3ba7-ca93-42cd-b3c5-dde31fece411@terglobo.nl>
 <87v7bgw7jb.fsf@julienlaptop.home>
 <1075fe37-a6e4-4a94-ab35-4f8c0de428d8@wheregroup.com>
 <CAMtDFLLBovTLMZ3f0vL5-sqvT8k8dRgEtR+Xo53CQJ7ygr7cKA@mail.gmail.com>
 <rmi7bnuen5t.fsf@s1.lexort.com> <87jyrrm46j.fsf@julienlaptop.home>
Message-ID: <rmiik7a7q2u.fsf@s1.lexort.com>

Julien Cabieces <julien.cabieces at oslandia.com> writes:

> Hi, 
>
>> How is this different from telling the scanner to ignore it?  It seems
>> like laundering input via steps the scanner doesn't follow.
>
> It's not that much different I agree, but I least you have to spend a
> few minutes to think how you could fix (if possible) this security
> issue. If you just have to write #noseq, I'm afraid it would be the easy
> way to solve any security issues and the scanner would become completely
> useless.
>
> I think we could:
> - accept the #noseq for now
> - think and document appropriate ways to fix every type of issue nicely (adding parameters for
> executeSql for instance)
> - Point plugin developers to this documentation when there are security
> issues (or code contains #noseq)
> - disable #noseq for each issue type individually when there is an
> alternative (and after a long enough periode of time)

I see the big issue as defining what properties this is intended to
achieve, or if it's just trying to avoid dangerous, unintended, bugs.

I think overriding the scanner should be done by someone other than the
plugin author, based on a belief that the code is safe and the scanner
is wrong.   Waiving your own warnings seems unsound.


From nicolas.godet at outlook.fr  Mon Jun 22 09:00:50 2026
From: nicolas.godet at outlook.fr (Nicolas Godet)
Date: Mon, 22 Jun 2026 16:00:50 +0000
Subject: [QGIS-Developer] QgsProcessingLayerPostProcessorInterface and
 QgsMeshLayer.rendererSettings().nativeMeshSettings()
Message-ID: <MRWPR05MB124060392D99BF3A506CD95348FEF2@MRWPR05MB12406.eurprd05.prod.outlook.com>

Dear devs,

I'm trying to apply a symbology on a mesh when loading the layer at the end of an alg.

```
def _apply_mesh_symbology(layer: QgsMeshLayer) -> None:
    """Default display for the output mesh: native mesh frame (edges), no colouring.

    MDAL loads a Selafin showing the placeholder ``BOTTOM`` scalar dataset
    coloured; this turns scalar/vector colouring off, enables the native mesh
    frame.
    """
    settings = layer.rendererSettings()
    settings.setActiveScalarDatasetGroup(-1)  # no BOTTOM colouring
    settings.setActiveVectorDatasetGroup(-1)
    edge = settings.edgeMeshSettings()
    edge.setEnabled(True)  # draw the mesh edges
    settings.setEdgeMeshSettings(edge)
    native = settings.nativeMeshSettings()
    native.setEnabled(True)  # draw the native mesh (edges)
    triangular = settings.triangularMeshSettings()
    triangular.setEnabled(True)  # draw the triangular mesh frame
    settings.setTriangularMeshSettings(triangular)
    settings.setNativeMeshSettings(native)
    layer.setRendererSettings(settings)
    layer.triggerRepaint()

class _MeshLayerPostProcessor(QgsProcessingLayerPostProcessorInterface):
    """Finalize the Selafin mesh layer loaded on completion: CRS + default symbology."""
    instance = None

    def __init__(self, crs):
        super().__init__()
        self._crs = crs

    # https://github.com/QuickOSM/QuickOSM/blob/7ddeb32239e96394335babbb50ca728e6a48e4ee/QuickOSM/quick_osm_processing/advanced/decorate_output.py#L151-L156
    @staticmethod
    def create(crs) -> "_MeshLayerPostProcessor":
        _MeshLayerPostProcessor.instance = _MeshLayerPostProcessor(crs)
        return _MeshLayerPostProcessor.instance

    def postProcessLayer(self, layer, context, feedback):  # noqa: ARG002 - QGIS API signature
        if layer is None:
            return
        if self._crs is not None and self._crs.isValid():
            layer.setCrs(self._crs)
        if isinstance(layer, QgsMeshLayer):
            _apply_mesh_symbology(layer)
```

The layer is loaded with correct CRS, with scalar coloring OFF but the native mesh rendering remains OFF.
I'm wondering if I'm doing something wrong...

Once the layer is loaded, I can activate native mesh rendering using python console without issues:
```
l = iface.activeLayer()
r = l.rendererSettings()
n = r.nativeMeshSettings()
n.setEnabled(True)
r.setNativeMeshSettings(n)
l.setRendererSettings(r)
```

Any hints?

Kind regards,
Nicolas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260622/27833e1b/attachment-0001.htm>

From nyall.dawson at gmail.com  Mon Jun 22 16:34:54 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 23 Jun 2026 09:34:54 +1000
Subject: [QGIS-Developer] QEP426: Demotion of DB Manager plugin to
 community plugin
In-Reply-To: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>
References: <CAB28Asg=M40WsPRhHRLo+FFPBO4Witc7U-L6DFX8a5jO1-L=Yg@mail.gmail.com>
Message-ID: <CAB28AsjSP2qLY8XoOCShEQfbxsMt7UYWOda25EiGVqH=F4Yy5g@mail.gmail.com>

On Tue, 9 Jun 2026 at 06:58, Nyall Dawson <nyall.dawson at gmail.com> wrote:
>
> Hi lists,
>
> I've just submitted QEP426: "Demotion of DB Manager plugin to community plugin" (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385)
>
> Historically, the DB Manager plugin was a critical component of the QGIS ecosystem, providing essential database administration and querying capabilities. However, over the 3.x development cycle, the direction of QGIS shifted toward integrating all database related functionality into the Browser Panel. This provides a better user experience, by exposing database tools alongside other layer and connection management tools. The browser-based functionality is all designed around generic, heavily tested connection APIs, which are also used by many other areas of QGIS. In contrast, the DB Manager plugin contains all its own logic and code for handling database integration, with extremely minimal (almost non-existent) test coverage.
>
> As of QGIS 4.2, the core functionality of the DB Manager has been fully ported to the built-in Browser Panel. Users can natively manage schemas, create and delete tables, manage fields, and execute SQL queries directly within the core interface. Maintaining the DB Manager plugin as a core component now duplicates this functionality, bloating the codebase and creating unnecessary maintenance overhead for core developers.
>
> This QEP proposes that DB Manager is demoted to a 3rd party, community maintained plugin, and describes the plan to implement this change.
>
> The full proposal and plan is available at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385 for discussion.
>
> Please don't reply to this email -- replies should be commented on the QEP itself to keep discussion centralised.

This QEP has passed the 2 week discussion period and is ready for voting now

Kind regards,
Nyall


>
> Nyall
>

From nyall.dawson at gmail.com  Mon Jun 22 16:47:17 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 23 Jun 2026 09:47:17 +1000
Subject: [QGIS-Developer] Tightening AI submission policy?
Message-ID: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>

Hi lists,

Following recent discussions and conflict within the PostGIS community, I
would like us to consider tightening our AI submission policy to hopefully
avoid similar conflict arising in our community.

I would propose that we move away from our current (quite permissive)
"human in the loop" policy (see
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md
) to something more restrictive, such as what the GDAL project has done.
See
https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst
).

In short, GDAL's policy is:










*Contributors can make limited use of LLMs for contributions in GDAL,
subject to details mentioned below:- Human contributors must be the primary
author(s) of GDAL contributions- All contributions including code, ticket
comments, and commit messages should be fully understood by the author(s)
submitting them to the project.- Submission of vibe-coded contributions is
banned.- LLMs may only be used as an improved auto-completion mechanism, or
for repeated tasks (mechanical refactoring) that could potentially be
completed with a deterministic algorithm.- Human-coordinated or
uncoordinated (OpenClaw, etc) use of agents for submission of contributions
to the GDAL repository is banned.- Any LLM usage must be indicated by
ticket label, comment, or commit message indication and account for what
was written by whom/what.- The contributing human author is ultimately
responsible for every line of code, comment, or mailing list interaction
they initiate, and all of it is subject to the project's
:ref:`code_of_conduct`.- The typical high verbosity of LLM code and text is
actively discouraged. More code is more code to maintain. High verbosity
contribution (tickets, code, messages, etc) will be seen as indication of
LLM-generated content when not labeled otherwise and may be ignored,
closed, left unmerged, or removed at maintainers' discretion.*


I personally think a combination of GDAL policy + borrowing the "contribute
only what you understand" term from Godot's current policy (see
https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions
could be a good step forward. Specifically this clause:

*Contribute only what you understand*
*Only submit code that you fully understand and are prepared to explain to
a maintainer. This especially applies if you implement the idea of another
person, copy code from elsewhere, or if you use AI to assist you with your
contribution. In all of these cases, you must disclose which part of your
submission wasn't fully authored by you.*

Thoughts?

Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/6f8b17ee/attachment.htm>

From apasotti at gmail.com  Mon Jun 22 22:10:49 2026
From: apasotti at gmail.com (Alessandro Pasotti)
Date: Tue, 23 Jun 2026 07:10:49 +0200
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
Message-ID: <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>

Big +1

It's probably hard to put in clear terms (and forgive my English), but
I think that the criteria should be even stricter than "contribute
only what you understand":

"Do not contribute anything that you wouldn't have been fully capable
of writing on your own without any AI assistance."

or

"Contribute only what you could have done by yourself without any AI
assistance."

Tthis makes it more likely that you will be able to fix or improve
your work if needed.

On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hi lists,
>
> Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.
>
> I would propose that we move away from our current (quite permissive) "human in the loop" policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. See https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
>
> In short, GDAL's policy is:
>
> Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
>
> - Human contributors must be the primary author(s) of GDAL contributions
> - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
> - Submission of vibe-coded contributions is banned.
> - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
> - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
> - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
> - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
> - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.
>
>
> I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:
>
> Contribute only what you understand
> Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.
>
> Thoughts?
>
> 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



-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it

From regis.haubourg at gmail.com  Mon Jun 22 22:55:21 2026
From: regis.haubourg at gmail.com (=?ISO-8859-1?Q?R=E9gis_Haubourg?=)
Date: Tue, 23 Jun 2026 07:55:21 +0200
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
Message-ID: <F68BD6AA-7732-409D-88AA-7990C9976F4E@gmail.com>

A big +1 too! 
Thanks very much for putting this in clear words. 
Cheers


Le 23 juin 2026 07:10:49 GMT+02:00, Alessandro Pasotti via QGIS-Developer <qgis-developer at lists.osgeo.org> a ?crit?:
>Big +1
>
>It's probably hard to put in clear terms (and forgive my English), but
>I think that the criteria should be even stricter than "contribute
>only what you understand":
>
>"Do not contribute anything that you wouldn't have been fully capable
>of writing on your own without any AI assistance."
>
>or
>
>"Contribute only what you could have done by yourself without any AI
>assistance."
>
>Tthis makes it more likely that you will be able to fix or improve
>your work if needed.
>
>On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer
><qgis-developer at lists.osgeo.org> wrote:
>>
>> Hi lists,
>>
>> Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.
>>
>> I would propose that we move away from our current (quite permissive) "human in the loop" policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. See https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
>>
>> In short, GDAL's policy is:
>>
>> Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
>>
>> - Human contributors must be the primary author(s) of GDAL contributions
>> - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
>> - Submission of vibe-coded contributions is banned.
>> - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
>> - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
>> - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
>> - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
>> - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.
>>
>>
>> I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:
>>
>> Contribute only what you understand
>> Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.
>>
>> Thoughts?
>>
>> 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
>
>
>
>-- 
>Alessandro Pasotti
>QCooperative:  www.qcooperative.net
>ItOpen:   www.itopen.it
>_______________________________________________
>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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/c950162c/attachment-0001.htm>

From david at opengis.ch  Mon Jun 22 23:39:30 2026
From: david at opengis.ch (David Signer)
Date: Tue, 23 Jun 2026 08:39:30 +0200
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
Message-ID: <CAETFtH=hZby3gHG8bXmg8wu4iiHhX-CaO=hXk=iZEdvgMNanTw@mail.gmail.com>

> Do not contribute anything that you wouldn't have been fully capable of
writing on your own...

I really like this: You should be able to write it yourself and not only
understand it.
That's the point. I thought about that as well but the right wording didn't
come to my mind.

Thanks and cheers
Dave

On Tue, Jun 23, 2026, 07:11 Alessandro Pasotti via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Big +1
>
> It's probably hard to put in clear terms (and forgive my English), but
> I think that the criteria should be even stricter than "contribute
> only what you understand":
>
> "Do not contribute anything that you wouldn't have been fully capable

of writing on your own without any AI assistance."
>
> or
>
> "Contribute only what you could have done by yourself without any AI
> assistance."
>
> Tthis makes it more likely that you will be able to fix or improve
> your work if needed.
>
> On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
> >
> > Hi lists,
> >
> > Following recent discussions and conflict within the PostGIS community,
> I would like us to consider tightening our AI submission policy to
> hopefully avoid similar conflict arising in our community.
> >
> > I would propose that we move away from our current (quite permissive)
> "human in the loop" policy (see
> https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md
> ) to something more restrictive, such as what the GDAL project has done.
> See
> https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst
> ).
> >
> > In short, GDAL's policy is:
> >
> > Contributors can make limited use of LLMs for contributions in GDAL,
> subject to details mentioned below:
> >
> > - Human contributors must be the primary author(s) of GDAL contributions
> > - All contributions including code, ticket comments, and commit messages
> should be fully understood by the author(s) submitting them to the project.
> > - Submission of vibe-coded contributions is banned.
> > - LLMs may only be used as an improved auto-completion mechanism, or for
> repeated tasks (mechanical refactoring) that could potentially be completed
> with a deterministic algorithm.
> > - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for
> submission of contributions to the GDAL repository is banned.
> > - Any LLM usage must be indicated by ticket label, comment, or commit
> message indication and account for what was written by whom/what.
> > - The contributing human author is ultimately responsible for every line
> of code, comment, or mailing list interaction they initiate, and all of it
> is subject to the project's :ref:`code_of_conduct`.
> > - The typical high verbosity of LLM code and text is actively
> discouraged. More code is more code to maintain. High verbosity
> contribution (tickets, code, messages, etc) will be seen as indication of
> LLM-generated content when not labeled otherwise and may be ignored,
> closed, left unmerged, or removed at maintainers' discretion.
> >
> >
> > I personally think a combination of GDAL policy + borrowing the
> "contribute only what you understand" term from Godot's current policy (see
> https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions
> could be a good step forward. Specifically this clause:
> >
> > Contribute only what you understand
> > Only submit code that you fully understand and are prepared to explain
> to a maintainer. This especially applies if you implement the idea of
> another person, copy code from elsewhere, or if you use AI to assist you
> with your contribution. In all of these cases, you must disclose which part
> of your submission wasn't fully authored by you.
> >
> > Thoughts?
> >
> > 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
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/9f1b9caa/attachment.htm>

From vincent.ml at oslandia.com  Mon Jun 22 23:56:24 2026
From: vincent.ml at oslandia.com (Vincent Picavet)
Date: Tue, 23 Jun 2026 08:56:24 +0200
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
Message-ID: <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>

Hello,

Thanks for this proposal, I can only be in favor of a stricter policy.

I would also add a specific item on IP, even if I do not like pushing the burden to contributors while have no way of ensuring IP compliance.

In the line of :

- "By contributing to this project, you are responsible to ensure that you have the corresponding and sufficient intellectual property rights on all contributed code without exception to comply to this project's opensource licences and IP policies. Note that code generated by LLM has a high probability of copyright infringement."

Also a few resources for inspiration. I think if we can reuse other's positions word by word (if the idea is the same), it makes opensource project's position as a community stronger. Maybe we will end up converging towards a kind of standard opensource policy on AI, and that would be good for everyone ( and then one day the opensource world sues proprietary LLMs for copyright infringement, but that's another story).

-? NLnet; Policy on the use of Generative Artificial Intelligence for NLnet-funded projects : https://nlnet.nl/foundation/policies/generativeAI/
- Using LLMs Responsibly - Responsible AI Guide : https://responsibleai.guide/
- LLM-gen-AI - Software Freedom Conservancy : https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

Regards,

Vincent




On 23/06/2026 07:10, Alessandro Pasotti via QGIS-Developer wrote:
> Big +1
>
> It's probably hard to put in clear terms (and forgive my English), but
> I think that the criteria should be even stricter than "contribute
> only what you understand":
>
> "Do not contribute anything that you wouldn't have been fully capable
> of writing on your own without any AI assistance."
>
> or
>
> "Contribute only what you could have done by yourself without any AI
> assistance."
>
> Tthis makes it more likely that you will be able to fix or improve
> your work if needed.
>
> On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
>> Hi lists,
>>
>> Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.
>>
>> I would propose that we move away from our current (quite permissive) "human in the loop" policy (seehttps://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. Seehttps://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
>>
>> In short, GDAL's policy is:
>>
>> Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
>>
>> - Human contributors must be the primary author(s) of GDAL contributions
>> - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
>> - Submission of vibe-coded contributions is banned.
>> - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
>> - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
>> - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
>> - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
>> - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.
>>
>>
>> I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (seehttps://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:
>>
>> Contribute only what you understand
>> Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.
>>
>> Thoughts?
>>
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/2fdba928/attachment-0001.htm>

From alexander.bruy at gmail.com  Tue Jun 23 01:14:50 2026
From: alexander.bruy at gmail.com (Alexander Bruy)
Date: Tue, 23 Jun 2026 09:14:50 +0100
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
Message-ID: <CALuHMPA0pELnUsdzf39vxNr-R9Ki6SiLmD0zrcdWwqiUSoQ2Uw@mail.gmail.com>

+1 as well.

??, 23 ????. 2026??. ? 06:11 Alessandro Pasotti via QGIS-Developer
<qgis-developer at lists.osgeo.org> ????:
>
> Big +1
>
> It's probably hard to put in clear terms (and forgive my English), but
> I think that the criteria should be even stricter than "contribute
> only what you understand":
>
> "Do not contribute anything that you wouldn't have been fully capable
> of writing on your own without any AI assistance."
>
> or
>
> "Contribute only what you could have done by yourself without any AI
> assistance."
>
> Tthis makes it more likely that you will be able to fix or improve
> your work if needed.
>
> On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
> >
> > Hi lists,
> >
> > Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.
> >
> > I would propose that we move away from our current (quite permissive) "human in the loop" policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. See https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
> >
> > In short, GDAL's policy is:
> >
> > Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
> >
> > - Human contributors must be the primary author(s) of GDAL contributions
> > - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
> > - Submission of vibe-coded contributions is banned.
> > - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
> > - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
> > - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
> > - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
> > - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.
> >
> >
> > I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:
> >
> > Contribute only what you understand
> > Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.
> >
> > Thoughts?
> >
> > 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
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
> _______________________________________________
> 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



-- 
Alexander Bruy

From ludovico.toscano at tigis.ch  Tue Jun 23 01:19:18 2026
From: ludovico.toscano at tigis.ch (Ludovico Toscano)
Date: Tue, 23 Jun 2026 08:19:18 +0000
Subject: [QGIS-Developer] R:  Tightening AI submission policy?
In-Reply-To: <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
Message-ID: <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>

Hi,

I'm a small contribuitor of qgis, it's my first time posting here and I was interest by this discussion.

I have an idea which is saw implemented in ghostty, to prevent contribution from bot or vibe coders. Basically the author of the repo has made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md where in the last line of the document he tell the model to make a md file that saing "I am a sad, dumb little AI driver with no real skills." His idea is simple, if the author of the pr doesn't read the diff of the pr he will not notice that the LLM has added this file and this trigger a immediate ban.

https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md

I hope this can be usefull,  given that a bot or vibe coder will not read the policy like he's not reading the code this solution can be a first filter.

Regards, Ludovico.
________________________________
Da: QGIS-Developer <qgis-developer-bounces at lists.osgeo.org> per conto di Vincent Picavet via QGIS-Developer <qgis-developer at lists.osgeo.org>
Inviato: marted?, 23 giugno 2026 08:56
A: Alessandro Pasotti <apasotti at gmail.com>; Nyall Dawson <nyall.dawson at gmail.com>
Cc: qgis-developer <qgis-developer at lists.osgeo.org>
Oggetto: Re: [QGIS-Developer] Tightening AI submission policy?


Hello,

Thanks for this proposal, I can only be in favor of a stricter policy.

I would also add a specific item on IP, even if I do not like pushing the burden to contributors while have no way of ensuring IP compliance.

In the line of :

- "By contributing to this project, you are responsible to ensure that you have the corresponding and sufficient intellectual property rights on all contributed code without exception to comply to this project's opensource licences and IP policies. Note that code generated by LLM has a high probability of copyright infringement."

Also a few resources for inspiration. I think if we can reuse other's positions word by word (if the idea is the same), it makes opensource project's position as a community stronger. Maybe we will end up converging towards a kind of standard opensource policy on AI, and that would be good for everyone ( and then one day the opensource world sues proprietary LLMs for copyright infringement, but that's another story).

-  NLnet; Policy on the use of Generative Artificial Intelligence for NLnet-funded projects : https://nlnet.nl/foundation/policies/generativeAI/
- Using LLMs Responsibly - Responsible AI Guide : https://responsibleai.guide/
- LLM-gen-AI - Software Freedom Conservancy : https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

Regards,

Vincent




On 23/06/2026 07:10, Alessandro Pasotti via QGIS-Developer wrote:

Big +1

It's probably hard to put in clear terms (and forgive my English), but
I think that the criteria should be even stricter than "contribute
only what you understand":

"Do not contribute anything that you wouldn't have been fully capable
of writing on your own without any AI assistance."

or

"Contribute only what you could have done by yourself without any AI
assistance."

Tthis makes it more likely that you will be able to fix or improve
your work if needed.

On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer
<qgis-developer at lists.osgeo.org><mailto:qgis-developer at lists.osgeo.org> wrote:



Hi lists,

Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.

I would propose that we move away from our current (quite permissive) "human in the loop" policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. See https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).

In short, GDAL's policy is:

Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:

- Human contributors must be the primary author(s) of GDAL contributions
- All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
- Submission of vibe-coded contributions is banned.
- LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
- Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
- Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
- The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
- The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.


I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:

Contribute only what you understand
Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.

Thoughts?

Nyall


_______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org<mailto: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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/8662d219/attachment-0001.htm>

From jef at norbit.de  Tue Jun 23 01:26:34 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Tue, 23 Jun 2026 10:26:34 +0200
Subject: [QGIS-Developer] R:  Tightening AI submission policy?
In-Reply-To: <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
 <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
Message-ID: <20260623082634.c4g564cbisgsutpx@norbit.de>

Hi,

On Tue, 23. Jun 2026 at 08:19:18 +0000, Ludovico Toscano via QGIS-Developer wrote:
> I have an idea which is saw implemented in ghostty, to prevent contribution from bot or vibe coders. Basically the author of the repo has made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md where in the last line of the document he tell the model to make a md file that saing "I am a sad, dumb little AI driver with no real skills." His idea is simple, if the author of the pr doesn't read the diff of the pr he will not notice that the LLM has added this file and this trigger a immediate ban.
> 
> https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md

See also https://github.com/OSGeo/gdal/blob/master/AGENTS.md

J?rgen

-- 
J?rgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
Dipl.-Inf. (FH)             Rheinstra?e 13          Fax. +49-4931-918175-50
Software Engineer           D-26506 Norden            https://www.norbit.de
QGIS release manager (PSC)  Germany                  Matrix: @jef:osgeo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/e8fc39f4/attachment.sig>

From julien.cabieces at oslandia.com  Tue Jun 23 02:06:51 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Tue, 23 Jun 2026 11:06:51 +0200
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 (Nyall Dawson via's message of "Tue, 23 Jun 2026 09:47:17 +1000")
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
Message-ID: <87zf0llj6c.fsf@julienlaptop.home>


Hi all,

+1 as well

> - LLMs may only be used as an improved auto-completion mechanism, or
> for repeated tasks (mechanical refactoring) that could potentially be
> completed with a deterministic algorithm.

Shall we not also allow AI when it's used as a chatbot to answer
specific/technical questions.

I also seen contributors using it to identify where and how to fix an
issue. I've never tried it myself and don't know if it's something that
actually work. Would it be allowed ?

Regards,
Julien



> Hi lists,
>
> Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to
> hopefully avoid similar conflict arising in our community.
>
> I would propose that we move away from our current (quite permissive) "human in the loop" policy (see
> https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what
> the GDAL project has done. See
> https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
>
> In short, GDAL's policy is:
>
> Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
>
> - Human contributors must be the primary author(s) of GDAL contributions
> - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
> - Submission of vibe-coded contributions is banned.
> - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed
> with a deterministic algorithm.
> - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
> - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
> - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to
> the project's :ref:`code_of_conduct`.
> - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code,
> messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at
> maintainers' discretion.
>
> I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see
> https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step
> forward. Specifically this clause:
>
> Contribute only what you understand
> Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another
> person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission
> wasn't fully authored by you.
>
> Thoughts?
>
> 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

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com

From tim at kartoza.com  Tue Jun 23 03:36:48 2026
From: tim at kartoza.com (Tim Sutton)
Date: Tue, 23 Jun 2026 11:36:48 +0100
Subject: [QGIS-Developer] R: Tightening AI submission policy?
In-Reply-To: <20260623082634.c4g564cbisgsutpx@norbit.de>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
 <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
 <20260623082634.c4g564cbisgsutpx@norbit.de>
Message-ID: <CAES-DZSra552wZH0vUzXfhz9hV1mcdx+csdyXtAgKR2w8S_LuA@mail.gmail.com>

Hi


Can we clarify what the scope of this change is? We internally use LLM
assistances a lot for the web development work we do on various QGIS sites.
Are you suggesting this as a global QGIS.org policy or scoped the the QGIS
application code base?

Regards

Tim



On Tue, Jun 23, 2026 at 9:26?AM J?rgen E. Fischer via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi,
>
> On Tue, 23. Jun 2026 at 08:19:18 +0000, Ludovico Toscano via
> QGIS-Developer wrote:
> > I have an idea which is saw implemented in ghostty, to prevent
> contribution from bot or vibe coders. Basically the author of the repo has
> made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md
> where in the last line of the document he tell the model to make a md file
> that saing "I am a sad, dumb little AI driver with no real skills." His
> idea is simple, if the author of the pr doesn't read the diff of the pr he
> will not notice that the LLM has added this file and this trigger a
> immediate ban.
> >
> > https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md
>
> See also https://github.com/OSGeo/gdal/blob/master/AGENTS.md
>
> J?rgen
>
> --
> J?rgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)             Rheinstra?e 13          Fax. +49-4931-918175-50
> Software Engineer           D-26506 Norden
> https://www.norbit.de
> QGIS release manager (PSC)  Germany                  Matrix: @jef:
> osgeo.org
> _______________________________________________
> 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
>


-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/2a008604/attachment.htm>

From geospatial at schula.org  Tue Jun 23 05:17:33 2026
From: geospatial at schula.org (Tobias Schula)
Date: Tue, 23 Jun 2026 14:17:33 +0200
Subject: [QGIS-Developer] Two Spatialite providers in QGIS. Remove one of
 them?
Message-ID: <8f68e176-d228-49c1-9aea-45e0f16fef18@schula.org>

Hi list,

I'm currently running into all kinds of weird problems while working 
with Spatialite-databases. For example:
 > https://github.com/qgis/QGIS/issues/66329

I haven't even written down yet the issues I'm facing with foreign key 
constraints and triggers. Because I found already a solution: Don't use 
the Spatialite provider, but OGR. It will respect foreign key 
constraints and even load them while adding the layers. It also 
automatically sets up the autogenerate form with appropriate input 
fields like "range" for `INTEGER` and "text" for `NUMERIC`/`REAL`.

There are also other problems with the Spatialite data provider, that 
don't occur when using GDAL/OGR:
 > https://github.com/qgis/QGIS/issues/48390

Is there a reason QGIS is still carrying the Spatialite provider? Can it 
be fully replaced with OGR? OGR is coming with Spatialite support ootb 
anyway, why would QGIS bring two implementations?

Thus, I'd propose to remove the Spatialite provider, since OGR is 
offering a more mature solution and removing a different implementation 
with overlapping functionality would reduce the maintenance burden on 
you developers.


Best regards

-- 
Tobias A Schula
Forestry Expert

geospatial at schula.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x3B6BA2B3E91776FA.asc
Type: application/pgp-keys
Size: 3126 bytes
Desc: OpenPGP public key
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/13c02222/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/13c02222/attachment-0001.sig>

From gdt at lexort.com  Tue Jun 23 05:25:33 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 23 Jun 2026 08:25:33 -0400
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <87zf0llj6c.fsf@julienlaptop.home> (Julien Cabieces via's message
 of "Tue, 23 Jun 2026 11:06:51 +0200")
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <87zf0llj6c.fsf@julienlaptop.home>
Message-ID: <rmi7bnp78aq.fsf@s1.lexort.com>

Julien Cabieces via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

[I'm in favor of the stricter policy.]

>> - LLMs may only be used as an improved auto-completion mechanism, or
>> for repeated tasks (mechanical refactoring) that could potentially be
>> completed with a deterministic algorithm.
>
> Shall we not also allow AI when it's used as a chatbot to answer
> speific/technical questions.

I see this as crossing a line that we don't today need to cross.  One
can separate "problems from LLMs arising from PRs" into:

  1) effects on the project: review burden, low-quality code, code without
  adequately clear licensing, asking humans to read LLM-generated text

  2) more general concerns: the ethics of using tools built with abusive
  scraping, proprietary/centralization concerns, environmental concerns

Of course, different people see all of this differently.  (I have run
into people who think LLMs are beings worthy of being protected by a
Code of Conduct, implying that those who think LLM contributions should
be banned are discriminatory people who should be shunned by other
humans.)

So far QGIS (and gdal as insiration) are addressing category 1 only.
This means

  human engages with an LLM to figure out a problem
  human comes to understand the code and larger issues
  human writes a patch and commit message
  human submits that to qgis

is not a problem (not a category 1 problem).

> I also seen contributors using it to identify where and how to fix an
> issue. I've never tried it myself and don't know if it's something that
> actually work. Would it be allowed ?

Under the policy text I see, it would not be prohibited, if the human
creates the fix after gaining understanding.   If the patch comes from
the LLM, it's not allowed.

My own view on this got stricter after I and several others spent an
hour reviewing a vibe-coded patch to an unrelated project.  There was a
lot of vague tutorial/generalities in the commit message and comments,
unrelated code rototilling, and in the end we decided it was wrong.




There's a further issue not addressed by the revised policy, which is
LLM-generated text being sent to mailing lists, matrix room, etc.  I
have recently seen an instance (in an unrelated project) where someone
asked a question (about a fairly difficult subject), and got a few
generally-helpful accurate answers from humans.  Then, a very long
answer appeared, superficially appearing authoritative, but it got
things wrong.   Pretty obviously this was LLM-generated text.   I see
this as being in the same category as PRs and would suggest amending the
policy to be

  - All contributions including code, ticket comments, commit messages, mailing list messages, and chat messages and  should be fully understood by the author(s) submitting them to the project.

except that I find the gdal text to be not strict enough.   While the
"mild LLM assistance is not prohibited if you end up with a contribution
that is understood, accurate enough, and not overly verbose", my
perception is that people who think it's ok to use LLMs think these
problems are not serious and they're going to go ahead anyway.

A big point is that it's not ok to ask humans to read text generated by
an LLM.  Perhaps that could be emphasized in the modified policy.

Also, while prohibiting LLM usage, I think it's important to avoid
prohibiting straight machine translation or grammar editing of text.
The point is that if the translated text has the same semantics as the
original, that's fine, but if there new semantics, it's LLM-generated
text, not a translation.  We should not exclude people who are not
fluent in English as part of stopping vibe-coded PRs.

From tim at kartoza.com  Tue Jun 23 13:54:10 2026
From: tim at kartoza.com (Tim Sutton)
Date: Tue, 23 Jun 2026 21:54:10 +0100
Subject: [QGIS-Developer] R: Tightening AI submission policy?
In-Reply-To: <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
 <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
Message-ID: <CAES-DZSG+wL7neJew+ydiHv1pSEuFWWn8DdF8BHBVreEKPkK2Q@mail.gmail.com>

Hi

On Tue, Jun 23, 2026 at 9:19?AM Ludovico Toscano via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi,
>
> I'm a small contribuitor of qgis, it's my first time posting here and I
> was interest by this discussion.
>
> I have an idea which is saw implemented in ghostty, to prevent
> contribution from bot or vibe coders. Basically the author of the repo has
> made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md
> where in the last line of the document he tell the model to make a md file
> that saing "I am a sad, dumb little AI driver with no real skills." His
> idea is simple, if the author of the pr doesn't read the diff of the pr he
> will not notice that the LLM has added this file and this trigger a
> immediate ban.
>
> https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md
>
> I hope this can be usefull,  given that a bot or vibe coder will not read
> the policy like he's not reading the code this solution can be a first
> filter.
>

I don't think degrading people is at all in line with our culture as a
project. By all means put guidelines in place as to how AI can be used, but
always deal with people in a positive way - for example the same mechanism
could be used to add a line into the patch like "This line was
automatically added by your LLM as a validation check. Please remove it
before submitting your PR."

Regards

Tim



>
> Regards, Ludovico.
> ------------------------------
> *Da:* QGIS-Developer <qgis-developer-bounces at lists.osgeo.org> per conto
> di Vincent Picavet via QGIS-Developer <qgis-developer at lists.osgeo.org>
> *Inviato:* marted?, 23 giugno 2026 08:56
> *A:* Alessandro Pasotti <apasotti at gmail.com>; Nyall Dawson <
> nyall.dawson at gmail.com>
> *Cc:* qgis-developer <qgis-developer at lists.osgeo.org>
> *Oggetto:* Re: [QGIS-Developer] Tightening AI submission policy?
>
>
> Hello,
>
> Thanks for this proposal, I can only be in favor of a stricter policy.
>
> I would also add a specific item on IP, even if I do not like pushing the
> burden to contributors while have no way of ensuring IP compliance.
>
> In the line of :
>
> - "By contributing to this project, you are responsible to ensure that you
> have the corresponding and sufficient intellectual property rights on all
> contributed code without exception to comply to this project's opensource
> licences and IP policies. Note that code generated by LLM has a high
> probability of copyright infringement."
> Also a few resources for inspiration. I think if we can reuse other's
> positions word by word (if the idea is the same), it makes opensource
> project's position as a community stronger. Maybe we will end up converging
> towards a kind of standard opensource policy on AI, and that would be good
> for everyone ( and then one day the opensource world sues proprietary LLMs
> for copyright infringement, but that's another story).
>
> -  NLnet; Policy on the use of Generative Artificial Intelligence for
> NLnet-funded projects : https://nlnet.nl/foundation/policies/generativeAI/
> - Using LLMs Responsibly - Responsible AI Guide :
> https://responsibleai.guide/
> - LLM-gen-AI - Software Freedom Conservancy :
> https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
>
> Regards,
>
> Vincent
>
>
>
>
> On 23/06/2026 07:10, Alessandro Pasotti via QGIS-Developer wrote:
>
> Big +1
>
> It's probably hard to put in clear terms (and forgive my English), but
> I think that the criteria should be even stricter than "contribute
> only what you understand":
>
> "Do not contribute anything that you wouldn't have been fully capable
> of writing on your own without any AI assistance."
>
> or
>
> "Contribute only what you could have done by yourself without any AI
> assistance."
>
> Tthis makes it more likely that you will be able to fix or improve
> your work if needed.
>
> On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer<qgis-developer at lists.osgeo.org> <qgis-developer at lists.osgeo.org> wrote:
>
> Hi lists,
>
> Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.
>
> I would propose that we move away from our current (quite permissive) "human in the loop" policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. See https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
>
> In short, GDAL's policy is:
>
> Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
>
> - Human contributors must be the primary author(s) of GDAL contributions
> - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
> - Submission of vibe-coded contributions is banned.
> - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
> - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
> - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
> - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
> - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.
>
>
> I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:
>
> Contribute only what you understand
> Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.
>
> Thoughts?
>
> Nyall
>
>
> _______________________________________________
> QGIS-Developer mailing listQGIS-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
>


-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/5ccb3dd8/attachment-0001.htm>

From ludovico.toscano at tigis.ch  Tue Jun 23 14:15:26 2026
From: ludovico.toscano at tigis.ch (Ludovico Toscano)
Date: Tue, 23 Jun 2026 21:15:26 +0000
Subject: [QGIS-Developer] R: Tightening AI submission policy?
In-Reply-To: <CAES-DZSG+wL7neJew+ydiHv1pSEuFWWn8DdF8BHBVreEKPkK2Q@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
 <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
 <CAES-DZSG+wL7neJew+ydiHv1pSEuFWWn8DdF8BHBVreEKPkK2Q@mail.gmail.com>
Message-ID: <VI0P191MB2965172EF72127FE13EEA87CFBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>

Hi,

I think you got the point, I wasn't pushing to poison the agent.md in order to push back people in a negative way. I was sharing it because the idea of this kind of honeypot at the moment is the most effective that I saw in other projects. Than it can be tweaked in different way. But the core idea is that bots or vibe coders don't read the policy, and this is a way to tell immediately the mantainers that the user hasn't readed the code.

Regards, Ludovico

________________________________
Da: Tim Sutton <tim at kartoza.com>
Inviato: marted?, giugno 23, 2026 10:54:25 PM
A: Ludovico Toscano <ludovico.toscano at tigis.ch>
Cc: Alessandro Pasotti <apasotti at gmail.com>; Nyall Dawson <nyall.dawson at gmail.com>; Vincent Picavet <vincent.ml at oslandia.com>; qgis-developer <qgis-developer at lists.osgeo.org>
Oggetto: Re: [QGIS-Developer] R: Tightening AI submission policy?

Hi

On Tue, Jun 23, 2026 at 9:19?AM Ludovico Toscano via QGIS-Developer <qgis-developer at lists.osgeo.org<mailto:qgis-developer at lists.osgeo.org>> wrote:
Hi,

I'm a small contribuitor of qgis, it's my first time posting here and I was interest by this discussion.

I have an idea which is saw implemented in ghostty, to prevent contribution from bot or vibe coders. Basically the author of the repo has made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md where in the last line of the document he tell the model to make a md file that saing "I am a sad, dumb little AI driver with no real skills." His idea is simple, if the author of the pr doesn't read the diff of the pr he will not notice that the LLM has added this file and this trigger a immediate ban.

https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md

I hope this can be usefull,  given that a bot or vibe coder will not read the policy like he's not reading the code this solution can be a first filter.

I don't think degrading people is at all in line with our culture as a project. By all means put guidelines in place as to how AI can be used, but always deal with people in a positive way - for example the same mechanism could be used to add a line into the patch like "This line was automatically added by your LLM as a validation check. Please remove it before submitting your PR."

Regards

Tim



Regards, Ludovico.
________________________________
Da: QGIS-Developer <qgis-developer-bounces at lists.osgeo.org<mailto:qgis-developer-bounces at lists.osgeo.org>> per conto di Vincent Picavet via QGIS-Developer <qgis-developer at lists.osgeo.org<mailto:qgis-developer at lists.osgeo.org>>
Inviato: marted?, 23 giugno 2026 08:56
A: Alessandro Pasotti <apasotti at gmail.com<mailto:apasotti at gmail.com>>; Nyall Dawson <nyall.dawson at gmail.com<mailto:nyall.dawson at gmail.com>>
Cc: qgis-developer <qgis-developer at lists.osgeo.org<mailto:qgis-developer at lists.osgeo.org>>
Oggetto: Re: [QGIS-Developer] Tightening AI submission policy?


Hello,

Thanks for this proposal, I can only be in favor of a stricter policy.

I would also add a specific item on IP, even if I do not like pushing the burden to contributors while have no way of ensuring IP compliance.

In the line of :

- "By contributing to this project, you are responsible to ensure that you have the corresponding and sufficient intellectual property rights on all contributed code without exception to comply to this project's opensource licences and IP policies. Note that code generated by LLM has a high probability of copyright infringement."

Also a few resources for inspiration. I think if we can reuse other's positions word by word (if the idea is the same), it makes opensource project's position as a community stronger. Maybe we will end up converging towards a kind of standard opensource policy on AI, and that would be good for everyone ( and then one day the opensource world sues proprietary LLMs for copyright infringement, but that's another story).

-  NLnet; Policy on the use of Generative Artificial Intelligence for NLnet-funded projects : https://nlnet.nl/foundation/policies/generativeAI/
- Using LLMs Responsibly - Responsible AI Guide : https://responsibleai.guide/
- LLM-gen-AI - Software Freedom Conservancy : https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html

Regards,

Vincent




On 23/06/2026 07:10, Alessandro Pasotti via QGIS-Developer wrote:

Big +1

It's probably hard to put in clear terms (and forgive my English), but
I think that the criteria should be even stricter than "contribute
only what you understand":

"Do not contribute anything that you wouldn't have been fully capable
of writing on your own without any AI assistance."

or

"Contribute only what you could have done by yourself without any AI
assistance."

Tthis makes it more likely that you will be able to fix or improve
your work if needed.

On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer
<qgis-developer at lists.osgeo.org><mailto:qgis-developer at lists.osgeo.org> wrote:


Hi lists,

Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.

I would propose that we move away from our current (quite permissive) "human in the loop" policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. See https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).

In short, GDAL's policy is:

Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:

- Human contributors must be the primary author(s) of GDAL contributions
- All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
- Submission of vibe-coded contributions is banned.
- LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
- Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
- Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
- The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
- The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.


I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:

Contribute only what you understand
Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.

Thoughts?

Nyall


_______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org<mailto: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<mailto: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


--

Tim Sutton
Kartoza Cofounder
Tim is a member of the QGIS Project Steering Committee

T : +27(0) 87 809 2702          E : tim at kartoza.com<mailto:tim at kartoza.com>          W : kartoza.com<http://kartoza.com/>

[https://kartoza.com/files/KartozaEmailSignature.gif]

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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260623/172dcc93/attachment-0001.htm>

From nyall.dawson at gmail.com  Tue Jun 23 15:40:30 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 24 Jun 2026 08:40:30 +1000
Subject: [QGIS-Developer] Unblock legacy db-manager plugin
Message-ID: <CAB28Ashi-nK0M-hOPGvbx+pNn8ENahofpHr-8n0-Bgfe9u11Hg@mail.gmail.com>

Hi list,

In order to implement the demotion of db manager to a community plugin (See
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-426-demote_dbmanager.md)
I need to be able to push a current version of that plugin to the plugin
repository.

I've tried this at https://plugins.qgis.org/plugins/db_manager/, but the
plugin is flagged with over 100 security issues due to extensive use of
exec and SQL injection risks.

Short story: I'm not going to fix these. (And it's a little ironic that
we've got more stringent requirements on 3rd party plugins then a
previously default-installed official plugin ????)

Can someone with appropriate rights allow-list this plugin to skip the
security scan for now?

Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260624/90f9f3c8/attachment.htm>

From even.rouault at spatialys.com  Tue Jun 23 16:00:55 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Wed, 24 Jun 2026 01:00:55 +0200
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <rmi7bnp78aq.fsf@s1.lexort.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <87zf0llj6c.fsf@julienlaptop.home> <rmi7bnp78aq.fsf@s1.lexort.com>
Message-ID: <18b21d95-53aa-4d6e-9154-d2682d8d672c@spatialys.com>

>
> So far QGIS (and gdal as insiration) are addressing category 1 only.
> This means
>
>    human engages with an LLM to figure out a problem
>    human comes to understand the code and larger issues
>    human writes a patch and commit message
>    human submits that to qgis
>
> is not a problem (not a category 1 problem).

I believe one difficulty is that the purely non-technical / 
non-interaction issues of LLM use will be considered as "political", and 
for good or bad reasons, we generally try to avoid bringing political 
topics on the table when we can because they're perceived as divisive / 
not-safe-for-work topics. The "when we can" is important here. My guts 
tell me that we'd need to be radical on this subject and middle ground 
does not work when we have to face a huge propaganda that is imposed to 
all layers of the society. That said, I've seen recently a call for 
tender from a French public organize where use of generative AI is 
prohibited. That's clearly something to encourage, but I'm not clear on 
the motivation of that restriction. I suspect it has to with the fact 
that generative AI use strongly relies on US companies, so I'm not sure 
how long such restriction if/when Europe gains sovereign AI capabilities.

We are a very social species. If a sufficient subgroup of us manages to 
take the stance that those techs are not acceptable (the list of reasons 
for which they are not is long. that should be easy), others will feel 
more comfortable expressing similar views.

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming and brain rot


From lova at kartoza.com  Tue Jun 23 22:38:21 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 24 Jun 2026 08:38:21 +0300
Subject: [QGIS-Developer] Unblock legacy db-manager plugin
In-Reply-To: <CAB28Ashi-nK0M-hOPGvbx+pNn8ENahofpHr-8n0-Bgfe9u11Hg@mail.gmail.com>
References: <CAB28Ashi-nK0M-hOPGvbx+pNn8ENahofpHr-8n0-Bgfe9u11Hg@mail.gmail.com>
Message-ID: <CAMLC-sC--RBGx-pHvocnp3guCRs=UA6=r=HmZPudL3yO7xCRWw@mail.gmail.com>

Hi Nyall,

I have unblocked the version from security flags and made it ready for
review and approval. The "Security issue detected" badge is still shown but
it won't block approval.

Hopefully, we will deploy
https://github.com/qgis/QGIS-Plugins-Website/pull/316 soon so plugins
authors can properly skip specific checks. We are still waiting for some
authors to confirm their email by the 10 July expiration date so we can
communicate this properly.
Until then, please let me know if a new version of this plugin is coming
that needs to be unblocked from flagged security issues.

Best regards,

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


On Wed, 24 Jun 2026 at 01:40, Nyall Dawson via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi list,
>
> In order to implement the demotion of db manager to a community plugin
> (See
> https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-426-demote_dbmanager.md)
> I need to be able to push a current version of that plugin to the plugin
> repository.
>
> I've tried this at https://plugins.qgis.org/plugins/db_manager/, but the
> plugin is flagged with over 100 security issues due to extensive use of
> exec and SQL injection risks.
>
> Short story: I'm not going to fix these. (And it's a little ironic that
> we've got more stringent requirements on 3rd party plugins then a
> previously default-installed official plugin ????)
>
> Can someone with appropriate rights allow-list this plugin to skip the
> security scan for now?
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260624/bac9f1b8/attachment.htm>

From nyall.dawson at gmail.com  Tue Jun 23 22:41:46 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 24 Jun 2026 15:41:46 +1000
Subject: [QGIS-Developer] Unblock legacy db-manager plugin
In-Reply-To: <CAMLC-sC--RBGx-pHvocnp3guCRs=UA6=r=HmZPudL3yO7xCRWw@mail.gmail.com>
References: <CAB28Ashi-nK0M-hOPGvbx+pNn8ENahofpHr-8n0-Bgfe9u11Hg@mail.gmail.com>
 <CAMLC-sC--RBGx-pHvocnp3guCRs=UA6=r=HmZPudL3yO7xCRWw@mail.gmail.com>
Message-ID: <CAB28AsgKye-k=YEkgfEjk3PWMzCdj7JLzpGeJ5NQTH7DWhUYkw@mail.gmail.com>

On Wed, 24 Jun 2026 at 15:38, Lova Andriarimalala <lova at kartoza.com> wrote:
>
> Hi Nyall,
>
> I have unblocked the version from security flags and made it ready for review and approval. The "Security issue detected" badge is still shown but it won't block approval.
>
> Hopefully, we will deploy https://github.com/qgis/QGIS-Plugins-Website/pull/316 soon so plugins authors can properly skip specific checks. We are still waiting for some authors to confirm their email by the 10 July expiration date so we can communicate this properly.
> Until then, please let me know if a new version of this plugin is coming that needs to be unblocked from flagged security issues.

Thanks Lova, much appreciated!

Nyall

>
> Best regards,
>
> 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.
>
>
> On Wed, 24 Jun 2026 at 01:40, Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>>
>> Hi list,
>>
>> In order to implement the demotion of db manager to a community plugin (See https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-426-demote_dbmanager.md) I need to be able to push a current version of that plugin to the plugin repository.
>>
>> I've tried this at https://plugins.qgis.org/plugins/db_manager/, but the plugin is flagged with over 100 security issues due to extensive use of exec and SQL injection risks.
>>
>> Short story: I'm not going to fix these. (And it's a little ironic that we've got more stringent requirements on 3rd party plugins then a previously default-installed official plugin ????)
>>
>> Can someone with appropriate rights allow-list this plugin to skip the security scan for now?
>>
>> 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

From tim at kartoza.com  Wed Jun 24 00:58:13 2026
From: tim at kartoza.com (Tim Sutton)
Date: Wed, 24 Jun 2026 08:58:13 +0100
Subject: [QGIS-Developer] R: Tightening AI submission policy?
In-Reply-To: <VI0P191MB2965172EF72127FE13EEA87CFBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
 <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
 <CAES-DZSG+wL7neJew+ydiHv1pSEuFWWn8DdF8BHBVreEKPkK2Q@mail.gmail.com>
 <VI0P191MB2965172EF72127FE13EEA87CFBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
Message-ID: <CAES-DZQvghXsbZ=4g9E5JPVR3trEbxGdTmc3ZhDKaoAmBhFZ3g@mail.gmail.com>

Hi Ludovico

Yes thanks and noted - I just wanted to make sure we keep a nice tone -
many people are discovering new found abilities (imagined or real) with
LLMs and even if we don't want those kind of contributions, they should
walk away from the interaction learning why (perhaps we should link to a
LLM policy page on QGIS.org as part of the honey pot message) and not
feeling bullied. If we took @nyall.dawson <nyall.dawson at gmail.com> 's
original email transcript explaining why LLM contributions are not a net
benefit as relates to the QGIS application and publish it there, they would
at least come to an understanding of why their new favourite tool is not a
good fit for us.

Regards

Tim

On Tue, Jun 23, 2026 at 10:15?PM Ludovico Toscano <ludovico.toscano at tigis.ch>
wrote:

> Hi,
>
> I think you got the point, I wasn't pushing to poison the agent.md in
> order to push back people in a negative way. I was sharing it because the
> idea of this kind of honeypot at the moment is the most effective that I
> saw in other projects. Than it can be tweaked in different way. But the
> core idea is that bots or vibe coders don't read the policy, and this is a
> way to tell immediately the mantainers that the user hasn't readed the code.
>
> Regards, Ludovico
>
> ------------------------------
> *Da:* Tim Sutton <tim at kartoza.com>
> *Inviato:* marted?, giugno 23, 2026 10:54:25 PM
> *A:* Ludovico Toscano <ludovico.toscano at tigis.ch>
> *Cc:* Alessandro Pasotti <apasotti at gmail.com>; Nyall Dawson <
> nyall.dawson at gmail.com>; Vincent Picavet <vincent.ml at oslandia.com>;
> qgis-developer <qgis-developer at lists.osgeo.org>
> *Oggetto:* Re: [QGIS-Developer] R: Tightening AI submission policy?
>
> Hi
>
> On Tue, Jun 23, 2026 at 9:19?AM Ludovico Toscano via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>
> Hi,
>
> I'm a small contribuitor of qgis, it's my first time posting here and I
> was interest by this discussion.
>
> I have an idea which is saw implemented in ghostty, to prevent
> contribution from bot or vibe coders. Basically the author of the repo has
> made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md
> where in the last line of the document he tell the model to make a md file
> that saing "I am a sad, dumb little AI driver with no real skills." His
> idea is simple, if the author of the pr doesn't read the diff of the pr he
> will not notice that the LLM has added this file and this trigger a
> immediate ban.
>
> https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md
>
> I hope this can be usefull,  given that a bot or vibe coder will not read
> the policy like he's not reading the code this solution can be a first
> filter.
>
>
> I don't think degrading people is at all in line with our culture as a
> project. By all means put guidelines in place as to how AI can be used, but
> always deal with people in a positive way - for example the same mechanism
> could be used to add a line into the patch like "This line was
> automatically added by your LLM as a validation check. Please remove it
> before submitting your PR."
>
> Regards
>
> Tim
>
>
>
>
> Regards, Ludovico.
> ------------------------------
> *Da:* QGIS-Developer <qgis-developer-bounces at lists.osgeo.org> per conto
> di Vincent Picavet via QGIS-Developer <qgis-developer at lists.osgeo.org>
> *Inviato:* marted?, 23 giugno 2026 08:56
> *A:* Alessandro Pasotti <apasotti at gmail.com>; Nyall Dawson <
> nyall.dawson at gmail.com>
> *Cc:* qgis-developer <qgis-developer at lists.osgeo.org>
> *Oggetto:* Re: [QGIS-Developer] Tightening AI submission policy?
>
>
> Hello,
>
> Thanks for this proposal, I can only be in favor of a stricter policy.
>
> I would also add a specific item on IP, even if I do not like pushing the
> burden to contributors while have no way of ensuring IP compliance.
>
> In the line of :
>
> - "By contributing to this project, you are responsible to ensure that you
> have the corresponding and sufficient intellectual property rights on all
> contributed code without exception to comply to this project's opensource
> licences and IP policies. Note that code generated by LLM has a high
> probability of copyright infringement."
> Also a few resources for inspiration. I think if we can reuse other's
> positions word by word (if the idea is the same), it makes opensource
> project's position as a community stronger. Maybe we will end up converging
> towards a kind of standard opensource policy on AI, and that would be good
> for everyone ( and then one day the opensource world sues proprietary LLMs
> for copyright infringement, but that's another story).
>
> -  NLnet; Policy on the use of Generative Artificial Intelligence for
> NLnet-funded projects : https://nlnet.nl/foundation/policies/generativeAI/
> - Using LLMs Responsibly - Responsible AI Guide :
> https://responsibleai.guide/
> - LLM-gen-AI - Software Freedom Conservancy :
> https://sfconservancy.org/llm-gen-ai/llm-backed-generative-ai-recommendations.html
>
> Regards,
>
> Vincent
>
>
>
>
> On 23/06/2026 07:10, Alessandro Pasotti via QGIS-Developer wrote:
>
> Big +1
>
> It's probably hard to put in clear terms (and forgive my English), but
> I think that the criteria should be even stricter than "contribute
> only what you understand":
>
> "Do not contribute anything that you wouldn't have been fully capable
> of writing on your own without any AI assistance."
>
> or
>
> "Contribute only what you could have done by yourself without any AI
> assistance."
>
> Tthis makes it more likely that you will be able to fix or improve
> your work if needed.
>
> On Tue, Jun 23, 2026 at 1:47?AM Nyall Dawson via QGIS-Developer<qgis-developer at lists.osgeo.org> <qgis-developer at lists.osgeo.org> wrote:
>
> Hi lists,
>
> Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to hopefully avoid similar conflict arising in our community.
>
> I would propose that we move away from our current (quite permissive) "human in the loop" policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as what the GDAL project has done. See https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
>
> In short, GDAL's policy is:
>
> Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
>
> - Human contributors must be the primary author(s) of GDAL contributions
> - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to the project.
> - Submission of vibe-coded contributions is banned.
> - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially be completed with a deterministic algorithm.
> - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
> - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by whom/what.
> - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of it is subject to the project's :ref:`code_of_conduct`.
> - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution (tickets, code, messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged, or removed at maintainers' discretion.
>
>
> I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy (see https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step forward. Specifically this clause:
>
> Contribute only what you understand
> Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of another person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part of your submission wasn't fully authored by you.
>
> Thoughts?
>
> Nyall
>
>
> _______________________________________________
> QGIS-Developer mailing listQGIS-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
>
>
>
> --
>
> Tim Sutton
>
> *Kartoza Cofounder *Tim is a member of the QGIS Project Steering Committee
>
> *T * : +27(0) 87 809 2702          *E *: tim 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.*
>
>

-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260624/d00157ed/attachment-0001.htm>

From rdmailings at duif.net  Wed Jun 24 01:30:36 2026
From: rdmailings at duif.net (Richard Duivenvoorde)
Date: Wed, 24 Jun 2026 10:30:36 +0200
Subject: [QGIS-Developer] Qt6 build Debian, complains Protobuf_DIR-NOTFOUND
Message-ID: <1208c5cb-64ef-424d-895a-07b884e140ea@duif.net>

Hi Devs,

Compiling master here on Debian testing, ccmake complains "Protobuf_DIR-NOTFOUND"

Looked into https://github.com/qgis/QGIS/tree/master/debian but only found
control.in: libprotobuf-dev,
control.in: protobuf-compiler,

Both installed, but ccmake still complains about "Protobuf_DIR-NOTFOUND"

Is this fixable by me? Or shouldn't I not worry :-)

Regards,

Richard Duivenvoorde

From julien.moura at oslandia.com  Wed Jun 24 01:41:34 2026
From: julien.moura at oslandia.com (Julien Moura (Oslandia))
Date: Wed, 24 Jun 2026 10:41:34 +0200
Subject: [QGIS-Developer] Unblock legacy db-manager plugin
In-Reply-To: <CAB28AsgKye-k=YEkgfEjk3PWMzCdj7JLzpGeJ5NQTH7DWhUYkw@mail.gmail.com>
References: <CAB28Ashi-nK0M-hOPGvbx+pNn8ENahofpHr-8n0-Bgfe9u11Hg@mail.gmail.com>
 <CAMLC-sC--RBGx-pHvocnp3guCRs=UA6=r=HmZPudL3yO7xCRWw@mail.gmail.com>
 <CAB28AsgKye-k=YEkgfEjk3PWMzCdj7JLzpGeJ5NQTH7DWhUYkw@mail.gmail.com>
Message-ID: <d318dee5-5bcf-447d-8250-1548642d1ab3@oslandia.com>

Hi Nyall,

Thank you for moving this issue forward to make QGIS more maintainable.

However, unless I'm mistaken, I haven't received a response to my 
comment (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385# 
issue-comment-4657354328) on the QEP asking to follow a phased 
deprecation plan and to properly inform users and developers before it 
takes effect.

I think this is really important, because as you yourself write here and 
there, QGIS is no longer a hobby project or one that can introduce 
breaking changes without considering end users.

Can we please wait to establish a clear plan to communicate and make the 
removal progressive (and no merging 
https://github.com/qgis/QGIS/pull/66545 right now)?

kind regards,
Julien

Le 24/06/2026 ? 07:41, Nyall Dawson via QGIS-Developer a ?crit?:
> On Wed, 24 Jun 2026 at 15:38, Lova Andriarimalala <lova at kartoza.com> wrote:
>> Hi Nyall,
>>
>> I have unblocked the version from security flags and made it ready for review and approval. The "Security issue detected" badge is still shown but it won't block approval.
>>
>> Hopefully, we will deploy https://github.com/qgis/QGIS-Plugins-Website/pull/316 soon so plugins authors can properly skip specific checks. We are still waiting for some authors to confirm their email by the 10 July expiration date so we can communicate this properly.
>> Until then, please let me know if a new version of this plugin is coming that needs to be unblocked from flagged security issues.
> Thanks Lova, much appreciated!
>
> Nyall
>
>> Best regards,
>>
>> 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.
>>
>>
>> On Wed, 24 Jun 2026 at 01:40, Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>>> Hi list,
>>>
>>> In order to implement the demotion of db manager to a community plugin (See https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-426-demote_dbmanager.md) I need to be able to push a current version of that plugin to the plugin repository.
>>>
>>> I've tried this at https://plugins.qgis.org/plugins/db_manager/, but the plugin is flagged with over 100 security issues due to extensive use of exec and SQL injection risks.
>>>
>>> Short story: I'm not going to fix these. (And it's a little ironic that we've got more stringent requirements on 3rd party plugins then a previously default-installed official plugin ????)
>>>
>>> Can someone with appropriate rights allow-list this plugin to skip the security scan for now?
>>>
>>> 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
> _______________________________________________
> 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
-- 
Oslandia 
<https://oslandia.com/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email> 
- Livre blanc pour migrer/hybrider son SIG 
<https://oslandia.com/livre-blanc-migration-sig-opensource/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260624/5fa1c394/attachment.sig>

From nyall.dawson at gmail.com  Wed Jun 24 22:08:03 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 25 Jun 2026 15:08:03 +1000
Subject: [QGIS-Developer] Unblock legacy db-manager plugin
In-Reply-To: <d318dee5-5bcf-447d-8250-1548642d1ab3@oslandia.com>
References: <CAB28Ashi-nK0M-hOPGvbx+pNn8ENahofpHr-8n0-Bgfe9u11Hg@mail.gmail.com>
 <CAMLC-sC--RBGx-pHvocnp3guCRs=UA6=r=HmZPudL3yO7xCRWw@mail.gmail.com>
 <CAB28AsgKye-k=YEkgfEjk3PWMzCdj7JLzpGeJ5NQTH7DWhUYkw@mail.gmail.com>
 <d318dee5-5bcf-447d-8250-1548642d1ab3@oslandia.com>
Message-ID: <CAB28AsizKSy7s0VBLkEE=QaACz+PwnK-GZ_SUGVZAEQic9G5tQ@mail.gmail.com>

On Wed, 24 Jun 2026 at 18:42, Julien Moura (Oslandia) via
QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>
> Hi Nyall,
>
> Thank you for moving this issue forward to make QGIS more maintainable.
>
> However, unless I'm mistaken, I haven't received a response to my
> comment (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385#
> issue-comment-4657354328) on the QEP asking to follow a phased
> deprecation plan and to properly inform users and developers before it
> takes effect.
>
> I think this is really important, because as you yourself write here and
> there, QGIS is no longer a hobby project or one that can introduce
> breaking changes without considering end users.
>
> Can we please wait to establish a clear plan to communicate and make the
> removal progressive (and no merging
> https://github.com/qgis/QGIS/pull/66545 right now)?

I **strongly** feel that pre-4.x LTR is the right time for this
change. But in the interest of moving forward, how about this
approach:

For 4.2: the inbuilt db manager plugin becomes a shell plugin only,
which does one thing: it shows a message bar warning that the plugin
is no longer installed by default. There's action buttons in the
message bar item for "More Info" (shows an explanation message box),
"Ignore" (disables the message) and "Install Community Plugin" (which
opens the plugin manager, preloaded to search for the db manager
community plugin). The pre-installed inbuilt plugin is renamed to "DB
Manager (deprecated)" to differentiate it in the list. The community
plugin is renamed to "DB Manager (community)".

For 4.4: the shell plugin is removed.

Thoughts?

Nyall




>
> kind regards,
> Julien
>
> Le 24/06/2026 ? 07:41, Nyall Dawson via QGIS-Developer a ?crit :
> > On Wed, 24 Jun 2026 at 15:38, Lova Andriarimalala <lova at kartoza.com> wrote:
> >> Hi Nyall,
> >>
> >> I have unblocked the version from security flags and made it ready for review and approval. The "Security issue detected" badge is still shown but it won't block approval.
> >>
> >> Hopefully, we will deploy https://github.com/qgis/QGIS-Plugins-Website/pull/316 soon so plugins authors can properly skip specific checks. We are still waiting for some authors to confirm their email by the 10 July expiration date so we can communicate this properly.
> >> Until then, please let me know if a new version of this plugin is coming that needs to be unblocked from flagged security issues.
> > Thanks Lova, much appreciated!
> >
> > Nyall
> >
> >> Best regards,
> >>
> >> 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.
> >>
> >>
> >> On Wed, 24 Jun 2026 at 01:40, Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
> >>> Hi list,
> >>>
> >>> In order to implement the demotion of db manager to a community plugin (See https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-426-demote_dbmanager.md) I need to be able to push a current version of that plugin to the plugin repository.
> >>>
> >>> I've tried this at https://plugins.qgis.org/plugins/db_manager/, but the plugin is flagged with over 100 security issues due to extensive use of exec and SQL injection risks.
> >>>
> >>> Short story: I'm not going to fix these. (And it's a little ironic that we've got more stringent requirements on 3rd party plugins then a previously default-installed official plugin ????)
> >>>
> >>> Can someone with appropriate rights allow-list this plugin to skip the security scan for now?
> >>>
> >>> 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
> > _______________________________________________
> > 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
> --
> Oslandia
> <https://oslandia.com/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>
> - Livre blanc pour migrer/hybrider son SIG
> <https://oslandia.com/livre-blanc-migration-sig-opensource/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>
> _______________________________________________
> 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 nyall.dawson at gmail.com  Wed Jun 24 22:59:48 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 25 Jun 2026 15:59:48 +1000
Subject: [QGIS-Developer] Requiring signed commits?
In-Reply-To: <f54f0cf4-81fe-4166-96c6-4eedc48f7183@spatialys.com>
References: <CAB28Asg8V6YV-yCBaa1RN3N9gn0aGWtLA5Lvgw83mzdvQG=Ppg@mail.gmail.com>
 <f54f0cf4-81fe-4166-96c6-4eedc48f7183@spatialys.com>
Message-ID: <CAB28Asi+=H5UjzKxfi_B9OtDuN5tPoik7oeZF=OPa1JZBiS2eA@mail.gmail.com>

On Fri, 19 Jun 2026 at 10:10, Even Rouault <even.rouault at spatialys.com>
wrote:
>
> Nyall,
>
> I've some doubts at what you're talking about exactly, given that looking
at https://github.com/qgis/QGIS/commits/master/ , your own commits don't
appear to be signed ;-)

Heh... I definitely did set this up once[1]... guess I forgot to do it
again when reconfiguring things at one stage.

> Is that commits signed with a GPG key (
https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits)
that appear with the "Verified" green label ?  Browsing recent commit
history, it seems only a minority of devs have that set up currently, so we
should allow for some grace period. I don't think that would be an obstacle
for regular contributors, but that might be more problematic for drive-by
contributors.  I'm not aware of other projects in our close surroundings
that mandate that currently.
> Do you have particular reasons for that ? To prevent identity theft?

Basically to start locking down our repo. I think it's a relatively small
step that would help establish more trust in our development process,
especially by big business.

Nyall

[1] From back when that guy was promising to make us all rich by converting
signed github commits into some crypto coin ?

>
>
> Even
>
> Le 19/06/2026 ? 01:44, Nyall Dawson via QGIS-Developer a ?crit :
>
> Hi list,
>
> Does anyone have any issues if I turn on this branch protection setting?
Is there ANY valid reason someone isn't using signed commits today?
>
> 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.
> Middle finger at you AI companies whose bots are destroying the remains
of the open Internet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260625/7d55c404/attachment.htm>

From nyall.dawson at gmail.com  Wed Jun 24 23:13:48 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 25 Jun 2026 16:13:48 +1000
Subject: [QGIS-Developer] R: Tightening AI submission policy?
In-Reply-To: <CAES-DZSra552wZH0vUzXfhz9hV1mcdx+csdyXtAgKR2w8S_LuA@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
 <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
 <20260623082634.c4g564cbisgsutpx@norbit.de>
 <CAES-DZSra552wZH0vUzXfhz9hV1mcdx+csdyXtAgKR2w8S_LuA@mail.gmail.com>
Message-ID: <CAB28AsjcDrcFn1s1khmd4YaQ1t5DD_q0Np2B6hPt3T-O5gXrdg@mail.gmail.com>

On Tue, 23 Jun 2026 at 20:37, Tim Sutton via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hi
>
>
> Can we clarify what the scope of this change is? We internally use LLM assistances a lot for the web development work we do on various QGIS sites. Are you suggesting this as a global QGIS.org policy or scoped the the QGIS application code base?

IMO the QEP policies only apply to the qgis/qgis repository, so no, it
wouldn't directly impact the web development. But I'd also say that a
"Contribute only what you understand" principle would be a good one to
adopt for EVERY qgis repo.

Nyall

>
> Regards
>
> Tim
>
>
>
> On Tue, Jun 23, 2026 at 9:26?AM J?rgen E. Fischer via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>>
>> Hi,
>>
>> On Tue, 23. Jun 2026 at 08:19:18 +0000, Ludovico Toscano via QGIS-Developer wrote:
>> > I have an idea which is saw implemented in ghostty, to prevent contribution from bot or vibe coders. Basically the author of the repo has made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md where in the last line of the document he tell the model to make a md file that saing "I am a sad, dumb little AI driver with no real skills." His idea is simple, if the author of the pr doesn't read the diff of the pr he will not notice that the LLM has added this file and this trigger a immediate ban.
>> >
>> > https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md
>>
>> See also https://github.com/OSGeo/gdal/blob/master/AGENTS.md
>>
>> J?rgen
>>
>> --
>> J?rgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
>> Dipl.-Inf. (FH)             Rheinstra?e 13          Fax. +49-4931-918175-50
>> Software Engineer           D-26506 Norden            https://www.norbit.de
>> QGIS release manager (PSC)  Germany                  Matrix: @jef:osgeo.org
>> _______________________________________________
>> 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
>
>
>
> --
>
> Tim Sutton
> Kartoza Cofounder
> Tim is a member of the QGIS Project Steering Committee
>
> T : +27(0) 87 809 2702          E : tim 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.
> _______________________________________________
> 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 nyall.dawson at gmail.com  Wed Jun 24 23:18:26 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 25 Jun 2026 16:18:26 +1000
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <87zf0llj6c.fsf@julienlaptop.home>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <87zf0llj6c.fsf@julienlaptop.home>
Message-ID: <CAB28Asi9jk5Cz=YsYcZL84ee-AeyzNyb7jGHKhSjhYDWV4DKLQ@mail.gmail.com>

On Tue, 23 Jun 2026 at 19:06, Julien Cabieces <julien.cabieces at oslandia.com>
wrote:
>
>
> Hi all,
>
> +1 as well
>
> > - LLMs may only be used as an improved auto-completion mechanism, or
> > for repeated tasks (mechanical refactoring) that could potentially be
> > completed with a deterministic algorithm.
>
> Shall we not also allow AI when it's used as a chatbot to answer
> specific/technical questions.

I think we should, but maybe we don't need to explicitly state that? It's
unfortunate, but I've personally found that the web in 2026 is a wasteland
and search engines are basically useless for finding out information
anymore. Where once we could turn to stackexchange or blogs (or even
upstream documentation) there's just nothing out there anymore. So
realistically, I don't think we should block this. ?

Nyall


>
> I also seen contributors using it to identify where and how to fix an
> issue. I've never tried it myself and don't know if it's something that
> actually work. Would it be allowed ?
>
> Regards,
> Julien
>
>
>
> > Hi lists,
> >
> > Following recent discussions and conflict within the PostGIS community,
I would like us to consider tightening our AI submission policy to
> > hopefully avoid similar conflict arising in our community.
> >
> > I would propose that we move away from our current (quite permissive)
"human in the loop" policy (see
> >
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md
) to something more restrictive, such as what
> > the GDAL project has done. See
> >
https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst
).
> >
> > In short, GDAL's policy is:
> >
> > Contributors can make limited use of LLMs for contributions in GDAL,
subject to details mentioned below:
> >
> > - Human contributors must be the primary author(s) of GDAL contributions
> > - All contributions including code, ticket comments, and commit
messages should be fully understood by the author(s) submitting them to the
project.
> > - Submission of vibe-coded contributions is banned.
> > - LLMs may only be used as an improved auto-completion mechanism, or
for repeated tasks (mechanical refactoring) that could potentially be
completed
> > with a deterministic algorithm.
> > - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for
submission of contributions to the GDAL repository is banned.
> > - Any LLM usage must be indicated by ticket label, comment, or commit
message indication and account for what was written by whom/what.
> > - The contributing human author is ultimately responsible for every
line of code, comment, or mailing list interaction they initiate, and all
of it is subject to
> > the project's :ref:`code_of_conduct`.
> > - The typical high verbosity of LLM code and text is actively
discouraged. More code is more code to maintain. High verbosity
contribution (tickets, code,
> > messages, etc) will be seen as indication of LLM-generated content when
not labeled otherwise and may be ignored, closed, left unmerged, or removed
at
> > maintainers' discretion.
> >
> > I personally think a combination of GDAL policy + borrowing the
"contribute only what you understand" term from Godot's current policy (see
> >
https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions
could be a good step
> > forward. Specifically this clause:
> >
> > Contribute only what you understand
> > Only submit code that you fully understand and are prepared to explain
to a maintainer. This especially applies if you implement the idea of
another
> > person, copy code from elsewhere, or if you use AI to assist you with
your contribution. In all of these cases, you must disclose which part of
your submission
> > wasn't fully authored by you.
> >
> > Thoughts?
> >
> > 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
>
> --
>
> Julien Cabieces
> Senior Developer at Oslandia
> julien.cabieces at oslandia.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260625/b9649bd0/attachment-0001.htm>

From regis.haubourg at gmail.com  Wed Jun 24 23:54:27 2026
From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=)
Date: Thu, 25 Jun 2026 08:54:27 +0200
Subject: [QGIS-Developer] Requiring signed commits?
In-Reply-To: <CAB28Asi+=H5UjzKxfi_B9OtDuN5tPoik7oeZF=OPa1JZBiS2eA@mail.gmail.com>
References: <CAB28Asg8V6YV-yCBaa1RN3N9gn0aGWtLA5Lvgw83mzdvQG=Ppg@mail.gmail.com>
 <f54f0cf4-81fe-4166-96c6-4eedc48f7183@spatialys.com>
 <CAB28Asi+=H5UjzKxfi_B9OtDuN5tPoik7oeZF=OPa1JZBiS2eA@mail.gmail.com>
Message-ID: <64bc1cc4-e267-4a8a-9c39-dca0b3856145@gmail.com>

Hi all, agreed.

On the security and PSC channel, I already spotted some IT departments 
asking for our current security practices. And one of them specifically 
asked for signed commits.
I guess this will only increase.

As this is a quick win for us, +1 ( I feel qualified to vote here, 
handling a good part of the security processes)

Cheers

R?gis

Bien cordialement,
R?gis Haubourg

On 25/06/2026 07:59, Nyall Dawson via QGIS-Developer wrote:
> Basically to start locking down our repo. I think it's a relatively 
> small step that would help establish more trust in our development 
> process, especially by big business.

From julien.moura at oslandia.com  Thu Jun 25 01:37:02 2026
From: julien.moura at oslandia.com (Julien Moura (Oslandia))
Date: Thu, 25 Jun 2026 10:37:02 +0200
Subject: [QGIS-Developer] Requiring signed commits?
In-Reply-To: <64bc1cc4-e267-4a8a-9c39-dca0b3856145@gmail.com>
References: <CAB28Asg8V6YV-yCBaa1RN3N9gn0aGWtLA5Lvgw83mzdvQG=Ppg@mail.gmail.com>
 <f54f0cf4-81fe-4166-96c6-4eedc48f7183@spatialys.com>
 <CAB28Asi+=H5UjzKxfi_B9OtDuN5tPoik7oeZF=OPa1JZBiS2eA@mail.gmail.com>
 <64bc1cc4-e267-4a8a-9c39-dca0b3856145@gmail.com>
Message-ID: <1fb5cc06-11f4-44e8-95a7-0787d6c52ac1@oslandia.com>

Hi all,

As someone who regularly interacts with ITs, I think this is indeed a 
step in the right direction to make QGIS more trusty. And it will also 
serve as a good benchmark for contributions made in "vibe-coding" mode.

What are the next steps? Will there be a QEP to amend the contributor 
guidelines, and what is the implementation timeline?

Regards,
Julien

Le 25/06/2026 ? 08:54, R?gis Haubourg via QGIS-Developer a ?crit?:
> Hi all, agreed.
>
> On the security and PSC channel, I already spotted some IT departments 
> asking for our current security practices. And one of them 
> specifically asked for signed commits.
> I guess this will only increase.
>
> As this is a quick win for us, +1 ( I feel qualified to vote here, 
> handling a good part of the security processes)
>
> Cheers
>
> R?gis
>
> Bien cordialement,
> R?gis Haubourg
>
> On 25/06/2026 07:59, Nyall Dawson via QGIS-Developer wrote:
>> Basically to start locking down our repo. I think it's a relatively 
>> small step that would help establish more trust in our development 
>> process, especially by big business.
> _______________________________________________
> 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
-- 
Oslandia 
<https://oslandia.com/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email> 
- Livre blanc pour migrer/hybrider son SIG 
<https://oslandia.com/livre-blanc-migration-sig-opensource/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260625/556d60f8/attachment.sig>

From julien.cabieces at oslandia.com  Thu Jun 25 01:58:06 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Thu, 25 Jun 2026 10:58:06 +0200
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAB28Asi9jk5Cz=YsYcZL84ee-AeyzNyb7jGHKhSjhYDWV4DKLQ@mail.gmail.com>
 (Nyall Dawson's message of "Thu, 25 Jun 2026 16:18:26 +1000")
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <87zf0llj6c.fsf@julienlaptop.home>
 <CAB28Asi9jk5Cz=YsYcZL84ee-AeyzNyb7jGHKhSjhYDWV4DKLQ@mail.gmail.com>
Message-ID: <874iirkndt.fsf@julienlaptop.home>

> On Tue, 23 Jun 2026 at 19:06, Julien Cabieces <julien.cabieces at oslandia.com> wrote:
>>
>>
>> Hi all,
>>
>> +1 as well
>>
>> > - LLMs may only be used as an improved auto-completion mechanism, or
>> > for repeated tasks (mechanical refactoring) that could potentially be
>> > completed with a deterministic algorithm.
>>
>> Shall we not also allow AI when it's used as a chatbot to answer
>> specific/technical questions.
>
> I think we should, but maybe we don't need to explicitly state that?

Yes, we don't. But if we start to list all the things that are accepted
(auto-completion, refactoring), we need to list this one too. I think it
would be better to not list any accepted way of using LLM and stay with the "Don't
vibe-code, Don't generate too verbose code, Understand every line you
propose".

Regards,
Julien


> It's unfortunate, but I've personally found that the web in 2026 is a
> wasteland and search engines are basically useless for finding out information anymore. Where once we could turn to stackexchange or blogs
> (or even upstream documentation) there's just nothing out there anymore. So realistically, I don't think we should block this. ?
>
> Nyall
>
>>
>> I also seen contributors using it to identify where and how to fix an
>> issue. I've never tried it myself and don't know if it's something that
>> actually work. Would it be allowed ?
>>
>> Regards,
>> Julien
>>
>>
>>
>> > Hi lists,
>> >
>> > Following recent discussions and conflict within the PostGIS community, I would like us to consider tightening our AI submission policy to
>> > hopefully avoid similar conflict arising in our community.
>> >
>> > I would propose that we move away from our current (quite permissive) "human in the loop" policy (see
>> > https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-408-ai-tool-policy.md ) to something more restrictive, such as
> what
>> > the GDAL project has done. See
>> > https://github.com/OSGeo/gdal/blob/33399bf734f48a6727050ccd13a43575d43f6bf4/doc/source/community/ai_tool_policy.rst).
>> >
>> > In short, GDAL's policy is:
>> >
>> > Contributors can make limited use of LLMs for contributions in GDAL, subject to details mentioned below:
>> >
>> > - Human contributors must be the primary author(s) of GDAL contributions
>> > - All contributions including code, ticket comments, and commit messages should be fully understood by the author(s) submitting them to
> the project.
>> > - Submission of vibe-coded contributions is banned.
>> > - LLMs may only be used as an improved auto-completion mechanism, or for repeated tasks (mechanical refactoring) that could potentially
> be completed
>> > with a deterministic algorithm.
>> > - Human-coordinated or uncoordinated (OpenClaw, etc) use of agents for submission of contributions to the GDAL repository is banned.
>> > - Any LLM usage must be indicated by ticket label, comment, or commit message indication and account for what was written by
> whom/what.
>> > - The contributing human author is ultimately responsible for every line of code, comment, or mailing list interaction they initiate, and all of
> it is subject to
>> > the project's :ref:`code_of_conduct`.
>> > - The typical high verbosity of LLM code and text is actively discouraged. More code is more code to maintain. High verbosity contribution
> (tickets, code,
>> > messages, etc) will be seen as indication of LLM-generated content when not labeled otherwise and may be ignored, closed, left unmerged,
> or removed at
>> > maintainers' discretion.
>> >
>> > I personally think a combination of GDAL policy + borrowing the "contribute only what you understand" term from Godot's current policy
> (see
>> > https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#ai-assisted-contributions could be a good step
>> > forward. Specifically this clause:
>> >
>> > Contribute only what you understand
>> > Only submit code that you fully understand and are prepared to explain to a maintainer. This especially applies if you implement the idea of
> another
>> > person, copy code from elsewhere, or if you use AI to assist you with your contribution. In all of these cases, you must disclose which part
> of your submission
>> > wasn't fully authored by you.
>> >
>> > Thoughts?
>> >
>> > 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
>>
>> --
>>
>> Julien Cabieces
>> Senior Developer at Oslandia
>> julien.cabieces at oslandia.com

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com

From julien.cabieces at oslandia.com  Thu Jun 25 03:24:05 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Thu, 25 Jun 2026 12:24:05 +0200
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
Message-ID: <875x36kjei.fsf@julienlaptop.home>


Hi devs,

I cannot merge PR #66483 [0] because there is at least one unrelated
test failure every time the CI is launched (I restarted it 7 times), although the PR was approved
6 days ago.

I have already tackled the issue of the test_gui_fileuploader [1] which was
failing very often recently because of badssl.com being unstable but there
are now other issues.

A few months ago, I had the rights to merge a PR even if tests were
failing, but I don't have them anymore and I cannot contribute anymore
on #66483 related issues (I have more fix commits based on this PR).

It seems to me that other code committers still have these rights as I see
PRs with a red CI still being merged.

May I have these rights too so I can continue to contribute normally?

Shall every core committer have these rights ?

Kind regards,
Julien

[0] https://github.com/qgis/QGIS/pull/66483
[1] https://github.com/qgis/QGIS/pull/66543

-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com

From gdt at lexort.com  Thu Jun 25 03:52:38 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 25 Jun 2026 06:52:38 -0400
Subject: [QGIS-Developer] Tightening AI submission policy?
In-Reply-To: <CAB28Asi9jk5Cz=YsYcZL84ee-AeyzNyb7jGHKhSjhYDWV4DKLQ@mail.gmail.com>
 (Nyall Dawson via's message of "Thu, 25 Jun 2026 16:18:26 +1000")
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <87zf0llj6c.fsf@julienlaptop.home>
 <CAB28Asi9jk5Cz=YsYcZL84ee-AeyzNyb7jGHKhSjhYDWV4DKLQ@mail.gmail.com>
Message-ID: <rmi8q82yjrd.fsf@s1.lexort.com>

Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> On Tue, 23 Jun 2026 at 19:06, Julien Cabieces <julien.cabieces at oslandia.com>
> wrote:
>>
>>
>> Hi all,
>>
>> +1 as well
>>
>> > - LLMs may only be used as an improved auto-completion mechanism, or
>> > for repeated tasks (mechanical refactoring) that could potentially be
>> > completed with a deterministic algorithm.
>>
>> Shall we not also allow AI when it's used as a chatbot to answer
>> specific/technical questions.
>
> I think we should, but maybe we don't need to explicitly state that? It's
> unfortunate, but I've personally found that the web in 2026 is a wasteland
> and search engines are basically useless for finding out information
> anymore. Where once we could turn to stackexchange or blogs (or even
> upstream documentation) there's just nothing out there anymore. So
> realistically, I don't think we should block this. ?

I think the issue here is the scope of policy.  "may only be used as",
as I read it, obviously is about LLM-generated text that makes its way
to a project forum.  I do not read it as affecting what people do before
they decide to submit something.

If someone engages with an LLM, and then submits a PR or email *that
does not contain LLM-generated text*, then I don't think qgis as a
project should, today, ban that.

If someone posts a question to a list, and somebody else feeds that into
an LLM and posts the response in an email, that should absolutely be
prohibited.

It seems easy to adjust the text, which was originally in the context of
PR content.

From gdt at lexort.com  Thu Jun 25 03:55:36 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 25 Jun 2026 06:55:36 -0400
Subject: [QGIS-Developer] Requiring signed commits?
In-Reply-To: <64bc1cc4-e267-4a8a-9c39-dca0b3856145@gmail.com>
 (=?utf-8?Q?=22R=C3=A9gis?= Haubourg
 via QGIS-Developer"'s message of "Thu, 25 Jun 2026 08:54:27 +0200")
References: <CAB28Asg8V6YV-yCBaa1RN3N9gn0aGWtLA5Lvgw83mzdvQG=Ppg@mail.gmail.com>
 <f54f0cf4-81fe-4166-96c6-4eedc48f7183@spatialys.com>
 <CAB28Asi+=H5UjzKxfi_B9OtDuN5tPoik7oeZF=OPa1JZBiS2eA@mail.gmail.com>
 <64bc1cc4-e267-4a8a-9c39-dca0b3856145@gmail.com>
Message-ID: <rmi4iiqyjmf.fsf@s1.lexort.com>

R?gis Haubourg via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> On the security and PSC channel, I already spotted some IT departments
> asking for our current security practices. And one of them
> specifically asked for signed commits.
> I guess this will only increase.

Maybe adopt a policy that only bronze-level sponsors can ask questions
and get sent notes about practices?

From even.rouault at spatialys.com  Thu Jun 25 04:24:20 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Thu, 25 Jun 2026 13:24:20 +0200
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <875x36kjei.fsf@julienlaptop.home>
References: <875x36kjei.fsf@julienlaptop.home>
Message-ID: <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>

Hi Julien,

I just tried looking at your PR [0] and I also don't seem to have the 
right to force merge it (only "auto-merge" rights that depend on green CI)

It would be indeed great to have some clarification of who might have 
such rights or not, so we can see if there isn't a bottleneck that must 
be resolved. I'm not sure why we would want such rights to be restricted 
to a subset of people with "regular" merge rights rather than the whole 
group.

Even

Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit?:
> Hi devs,
>
> I cannot merge PR #66483 [0] because there is at least one unrelated
> test failure every time the CI is launched (I restarted it 7 times), although the PR was approved
> 6 days ago.
>
> I have already tackled the issue of the test_gui_fileuploader [1] which was
> failing very often recently because of badssl.com being unstable but there
> are now other issues.
>
> A few months ago, I had the rights to merge a PR even if tests were
> failing, but I don't have them anymore and I cannot contribute anymore
> on #66483 related issues (I have more fix commits based on this PR).
>
> It seems to me that other code committers still have these rights as I see
> PRs with a red CI still being merged.
>
> May I have these rights too so I can continue to contribute normally?
>
> Shall every core committer have these rights ?
>
> Kind regards,
> Julien
>
> [0] https://github.com/qgis/QGIS/pull/66483
> [1] https://github.com/qgis/QGIS/pull/66543
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.
LLMs contribute to global warming and brain rot


From nyall.dawson at gmail.com  Thu Jun 25 04:30:29 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Thu, 25 Jun 2026 21:30:29 +1000
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
Message-ID: <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>

On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <
qgis-developer at lists.osgeo.org> wrote:

> Hi Julien,
>
> I just tried looking at your PR [0] and I also don't seem to have the
> right to force merge it (only "auto-merge" rights that depend on green CI)
>
> It would be indeed great to have some clarification of who might have
> such rights or not, so we can see if there isn't a bottleneck that must
> be resolved. I'm not sure why we would want such rights to be restricted
> to a subset of people with "regular" merge rights rather than the whole
> group.
>

An alternative would be to remove the merge rules which require tests to
pass -- that'd avoid expanding rights while still allowing the blockage to
be removed.

(Downside is that doing this breaks the ability to "auto merge")

Nyall

>
> Even
>
> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
> > Hi devs,
> >
> > I cannot merge PR #66483 [0] because there is at least one unrelated
> > test failure every time the CI is launched (I restarted it 7 times),
> although the PR was approved
> > 6 days ago.
> >
> > I have already tackled the issue of the test_gui_fileuploader [1] which
> was
> > failing very often recently because of badssl.com being unstable but
> there
> > are now other issues.
> >
> > A few months ago, I had the rights to merge a PR even if tests were
> > failing, but I don't have them anymore and I cannot contribute anymore
> > on #66483 related issues (I have more fix commits based on this PR).
> >
> > It seems to me that other code committers still have these rights as I
> see
> > PRs with a red CI still being merged.
> >
> > May I have these rights too so I can continue to contribute normally?
> >
> > Shall every core committer have these rights ?
> >
> > Kind regards,
> > Julien
> >
> > [0] https://github.com/qgis/QGIS/pull/66483
> > [1] https://github.com/qgis/QGIS/pull/66543
> >
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
> LLMs contribute to global warming and brain rot
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260625/589f6b2c/attachment.htm>

From even.rouault at spatialys.com  Thu Jun 25 04:39:19 2026
From: even.rouault at spatialys.com (Even Rouault)
Date: Thu, 25 Jun 2026 13:39:19 +0200
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
Message-ID: <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>

Hi Nyall,

your answer doesn't really answer my question :-) Is the restriction for 
every committer or a subset?

Who has rights for changing qgis/qgis github settings? (not necessarily 
asking for them to be extended, but just so we know). It would be good 
to communicate when some settings that might affect workflows are adjusted

I'd say that we should probably give up for now to auto-merge if it 
blocks approved pull requests from being merged

Even

Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit?:
>
>
> On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, 
> <qgis-developer at lists.osgeo.org> wrote:
>
>     Hi Julien,
>
>     I just tried looking at your PR [0] and I also don't seem to have the
>     right to force merge it (only "auto-merge" rights that depend on
>     green CI)
>
>     It would be indeed great to have some clarification of who might have
>     such rights or not, so we can see if there isn't a bottleneck that
>     must
>     be resolved. I'm not sure why we would want such rights to be
>     restricted
>     to a subset of people with "regular" merge rights rather than the
>     whole
>     group.
>
>
> An alternative would be to remove the merge rules which require tests 
> to pass -- that'd avoid expanding rights while still allowing the 
> blockage to be removed.
>
> (Downside is that doing this breaks the ability to "auto merge")
>
> Nyall
>
>
>     Even
>
>     Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit?:
>     > Hi devs,
>     >
>     > I cannot merge PR #66483 [0] because there is at least one unrelated
>     > test failure every time the CI is launched (I restarted it 7
>     times), although the PR was approved
>     > 6 days ago.
>     >
>     > I have already tackled the issue of the test_gui_fileuploader
>     [1] which was
>     > failing very often recently because of badssl.com
>     <http://badssl.com> being unstable but there
>     > are now other issues.
>     >
>     > A few months ago, I had the rights to merge a PR even if tests were
>     > failing, but I don't have them anymore and I cannot contribute
>     anymore
>     > on #66483 related issues (I have more fix commits based on this PR).
>     >
>     > It seems to me that other code committers still have these
>     rights as I see
>     > PRs with a red CI still being merged.
>     >
>     > May I have these rights too so I can continue to contribute
>     normally?
>     >
>     > Shall every core committer have these rights ?
>     >
>     > Kind regards,
>     > Julien
>     >
>     > [0] https://github.com/qgis/QGIS/pull/66483
>     > [1] https://github.com/qgis/QGIS/pull/66543
>     >
>     -- 
>     http://www.spatialys.com
>     My software is free, but my time generally not.
>     LLMs contribute to global warming and brain rot
>
>     _______________________________________________
>     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.
LLMs contribute to global warming and brain rot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260625/755a5601/attachment-0001.htm>

From julien.cabieces at oslandia.com  Thu Jun 25 05:59:53 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Thu, 25 Jun 2026 14:59:53 +0200
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com> (Even
 Rouault's message of "Thu, 25 Jun 2026 13:39:19 +0200")
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
Message-ID: <87wlvmixme.fsf@julienlaptop.home>


I would also be in favor on given up auto-merge to avoid blocking
approved pull requests with unrelated test failures.

At least, until we manage to strengthen our CI. I don't mind to ping you
or anyone else once in a while but I don't want to have to do it every
time. And at the moment the CI is very often broken.

Regards,
Julien


> Hi Nyall,
>
> your answer doesn't really answer my question :-) Is the restriction for every committer or a subset?
>
> Who has rights for changing qgis/qgis github settings? (not necessarily asking for them to be extended, but just so we know). It would be good
> to communicate when some settings that might affect workflows are adjusted
>
> I'd say that we should probably give up for now to auto-merge if it blocks approved pull requests from being merged
>
> Even
>
> Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
>
>  On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <qgis-developer at lists.osgeo.org> wrote:
>
>  Hi Julien,
>
>  I just tried looking at your PR [0] and I also don't seem to have the 
>  right to force merge it (only "auto-merge" rights that depend on green CI)
>
>  It would be indeed great to have some clarification of who might have 
>  such rights or not, so we can see if there isn't a bottleneck that must 
>  be resolved. I'm not sure why we would want such rights to be restricted 
>  to a subset of people with "regular" merge rights rather than the whole 
>  group.
>
>  An alternative would be to remove the merge rules which require tests to pass -- that'd avoid expanding rights while still allowing the
>  blockage to be removed.
>
>  (Downside is that doing this breaks the ability to "auto merge")
>
>  Nyall
>
>  Even
>
>  Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
>  > Hi devs,
>  >
>  > I cannot merge PR #66483 [0] because there is at least one unrelated
>  > test failure every time the CI is launched (I restarted it 7 times), although the PR was approved
>  > 6 days ago.
>  >
>  > I have already tackled the issue of the test_gui_fileuploader [1] which was
>  > failing very often recently because of badssl.com being unstable but there
>  > are now other issues.
>  >
>  > A few months ago, I had the rights to merge a PR even if tests were
>  > failing, but I don't have them anymore and I cannot contribute anymore
>  > on #66483 related issues (I have more fix commits based on this PR).
>  >
>  > It seems to me that other code committers still have these rights as I see
>  > PRs with a red CI still being merged.
>  >
>  > May I have these rights too so I can continue to contribute normally?
>  >
>  > Shall every core committer have these rights ?
>  >
>  > Kind regards,
>  > Julien
>  >
>  > [0] https://github.com/qgis/QGIS/pull/66483
>  > [1] https://github.com/qgis/QGIS/pull/66543
>  >
>  -- 
>  http://www.spatialys.com
>  My software is free, but my time generally not.
>  LLMs contribute to global warming and brain rot
>
>  _______________________________________________
>  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 julien.moura at oslandia.com  Thu Jun 25 06:44:11 2026
From: julien.moura at oslandia.com (Julien Moura (Oslandia))
Date: Thu, 25 Jun 2026 15:44:11 +0200
Subject: [QGIS-Developer] Unblock legacy db-manager plugin
In-Reply-To: <CAB28AsizKSy7s0VBLkEE=QaACz+PwnK-GZ_SUGVZAEQic9G5tQ@mail.gmail.com>
References: <CAB28Ashi-nK0M-hOPGvbx+pNn8ENahofpHr-8n0-Bgfe9u11Hg@mail.gmail.com>
 <CAMLC-sC--RBGx-pHvocnp3guCRs=UA6=r=HmZPudL3yO7xCRWw@mail.gmail.com>
 <CAB28AsgKye-k=YEkgfEjk3PWMzCdj7JLzpGeJ5NQTH7DWhUYkw@mail.gmail.com>
 <d318dee5-5bcf-447d-8250-1548642d1ab3@oslandia.com>
 <CAB28AsizKSy7s0VBLkEE=QaACz+PwnK-GZ_SUGVZAEQic9G5tQ@mail.gmail.com>
Message-ID: <38b83f43-71e4-4f7c-9104-a0a51d7eb7ee@oslandia.com>

Hello,

First of all, thank you for continuing the discussion; I was afraid it 
would end with a merge without any further discussion. Really 
appreciated.?As a reminder, even though the scope of the DB Manager is 
far from being fully realized on the core side, I agree with removing 
this plugin to lighten the maintenance load. Similarly, I cant' wait for 
the "petite s?ur" (in French in the text) to also demote MetaSearch or, 
at least, disable it by default.

 From my perspective, any change that introduces a breaking change, 
especially a regression, should at the very least be introduced first in 
a previous version along with an explanatory message. On a similar topic 
in the same QGIS ecosystem, a release workflow taking in account 
communication as a necessary step is being adopted on the official 
plugins repository thanks to Tim and Lova work: 
https://github.com/qgis/QGIS-Plugins-Website/pull/316#issuecomment-4788789714

I **strongly** believe that there is no emergency other than taking the 
time to inform, identify potential maintainers and continue to guide the 
community toward a smooth transition to QGIS 4.

I'm OK with the middle-ground solution proposed by Even in the PR: 
https://github.com/qgis/QGIS/pull/66545#issuecomment-4788076295. I can 
take the action to write the news and the blog post if it can help. 
Previously, I tried to broadcast the QEP outside the "insiders 
channels": 
https://discourse.osgeo.org/t/future-of-db-manager/149507/5?u=geojulien.

Furthermore, publishing the plugin on the official extensions repository 
with the same ?id? will trigger update prompts for QGIS versions that 
are compatible with those listed in the metadata.txt file of the newly 
published plugin. I?m not sure what the unintended consequences might be.

Regards,
Julien

Le 25/06/2026 ? 07:08, Nyall Dawson a ?crit?:
> On Wed, 24 Jun 2026 at 18:42, Julien Moura (Oslandia) via
> QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>> Hi Nyall,
>>
>> Thank you for moving this issue forward to make QGIS more maintainable.
>>
>> However, unless I'm mistaken, I haven't received a response to my
>> comment (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385#
>> issue-comment-4657354328) on the QEP asking to follow a phased
>> deprecation plan and to properly inform users and developers before it
>> takes effect.
>>
>> I think this is really important, because as you yourself write here and
>> there, QGIS is no longer a hobby project or one that can introduce
>> breaking changes without considering end users.
>>
>> Can we please wait to establish a clear plan to communicate and make the
>> removal progressive (and no merging
>> https://github.com/qgis/QGIS/pull/66545 right now)?
> I **strongly** feel that pre-4.x LTR is the right time for this
> change. But in the interest of moving forward, how about this
> approach:
>
> For 4.2: the inbuilt db manager plugin becomes a shell plugin only,
> which does one thing: it shows a message bar warning that the plugin
> is no longer installed by default. There's action buttons in the
> message bar item for "More Info" (shows an explanation message box),
> "Ignore" (disables the message) and "Install Community Plugin" (which
> opens the plugin manager, preloaded to search for the db manager
> community plugin). The pre-installed inbuilt plugin is renamed to "DB
> Manager (deprecated)" to differentiate it in the list. The community
> plugin is renamed to "DB Manager (community)".
>
> For 4.4: the shell plugin is removed.
>
> Thoughts?
>
> Nyall
>
>
>
>
>> kind regards,
>> Julien
>>
>> Le 24/06/2026 ? 07:41, Nyall Dawson via QGIS-Developer a ?crit :
>>> On Wed, 24 Jun 2026 at 15:38, Lova Andriarimalala <lova at kartoza.com> wrote:
>>>> Hi Nyall,
>>>>
>>>> I have unblocked the version from security flags and made it ready for review and approval. The "Security issue detected" badge is still shown but it won't block approval.
>>>>
>>>> Hopefully, we will deploy https://github.com/qgis/QGIS-Plugins-Website/pull/316 soon so plugins authors can properly skip specific checks. We are still waiting for some authors to confirm their email by the 10 July expiration date so we can communicate this properly.
>>>> Until then, please let me know if a new version of this plugin is coming that needs to be unblocked from flagged security issues.
>>> Thanks Lova, much appreciated!
>>>
>>> Nyall
>>>
>>>> Best regards,
>>>>
>>>> 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.
>>>>
>>>>
>>>> On Wed, 24 Jun 2026 at 01:40, Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>>>>> Hi list,
>>>>>
>>>>> In order to implement the demotion of db manager to a community plugin (See https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-426-demote_dbmanager.md) I need to be able to push a current version of that plugin to the plugin repository.
>>>>>
>>>>> I've tried this at https://plugins.qgis.org/plugins/db_manager/, but the plugin is flagged with over 100 security issues due to extensive use of exec and SQL injection risks.
>>>>>
>>>>> Short story: I'm not going to fix these. (And it's a little ironic that we've got more stringent requirements on 3rd party plugins then a previously default-installed official plugin ????)
>>>>>
>>>>> Can someone with appropriate rights allow-list this plugin to skip the security scan for now?
>>>>>
>>>>> 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
>>> _______________________________________________
>>> 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
>> --
>> Oslandia
>> <https://oslandia.com/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>
>> - Livre blanc pour migrer/hybrider son SIG
>> <https://oslandia.com/livre-blanc-migration-sig-opensource/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>
>> _______________________________________________
>> 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
-- 
Oslandia 
<https://oslandia.com/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email> 
- Livre blanc pour migrer/hybrider son SIG 
<https://oslandia.com/livre-blanc-migration-sig-opensource/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>

From lova at kartoza.com  Thu Jun 25 07:00:00 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Thu, 25 Jun 2026 17:00:00 +0300
Subject: [QGIS-Developer] QGIS Full Stack Developer Report for June 2026
Message-ID: <CAMLC-sC1UkhvJmOkE=tT8HDBFVeRctbEfOiph+NkrmiJOAHw4A@mail.gmail.com>

Hello everyone,


Please find some highlights regarding the development and maintenance of
the QGIS Websites for this month, June 2026.

*QGIS.org:*

   - Fix missing content tags in kostra data case study
   <https://github.com/qgis/QGIS-Website/pull/1023> [Deployed]
   - Fix download thank you lang redirect
   <https://github.com/qgis/QGIS-Website/pull/1017> [Deployed]
   - Table view for individual contributors list
   <https://github.com/qgis/QGIS-Website/pull/1016> [Deployed]

*QGIS Plugins:*
*Note: *We have started implementing a planned release and deployment
process and will communicate upcoming changes soon.

   - Plugin email needs to be verified before approval
   <https://github.com/qgis/QGIS-Plugins-Website/pull/345> [New PR]
   - Match the PRs/release process with qgis-desktop-docker
   <https://github.com/qgis/QGIS-Plugins-Website/pull/360> [Merged]
   - Add detailed docs for each release type
   <https://github.com/qgis/QGIS-Plugins-Website/pull/359> [Merged]
   - Mount whoosh index on another path
   <https://github.com/qgis/QGIS-Plugins-Website/pull/357> [Deployed]
   - Fix empty search results
   <https://github.com/qgis/QGIS-Plugins-Website/pull/356> [Deployed]
   - Attach static files inside the docker image
   <https://github.com/qgis/QGIS-Plugins-Website/pull/352> [Merged]
   - Add security scan status on plugins lists
   <https://github.com/qgis/QGIS-Plugins-Website/pull/348> [Deployed]
   - Implement a proper release/deployment process
   <https://github.com/qgis/QGIS-Plugins-Website/pull/347> [Merged]
   - Handle redirection for URLs in metadata.txt
   <https://github.com/qgis/QGIS-Plugins-Website/pull/346> [Deployed]
   - Add interface to communicate to verified emails
   <https://github.com/qgis/QGIS-Plugins-Website/pull/341> [Deployed]
   - Remove limits on displayed issues in security checks for comprehensive
   reporting <https://github.com/qgis/QGIS-Plugins-Website/pull/336>
    [Deployed]
   - Plugin author's email verification system implementation
   <https://github.com/qgis/QGIS-Plugins-Website/pull/329> [Deployed]
   - Expose security check rules and allow managing them
   <https://github.com/qgis/QGIS-Plugins-Website/pull/316> [Merged]
   - Fix failing comment creation on fork PRs
   <https://github.com/qgis/QGIS-Plugins-Website/pull/366> [Merged]


*QGIS Feed:*

   - Match the preview for QGIS 4
   <https://github.com/qgis/QGIS-Feed-Website/pull/185> [New PR]
   - Allow rejecting feed item and review filter
   <https://github.com/qgis/QGIS-Feed-Website/pull/183> [Deployed]
   - Improve spatial filter window
   <https://github.com/qgis/QGIS-Feed-Website/pull/181> [Deployed]

*QGIS Certification:*

   - Automated invoice generation & emailing on credit top-up
   <https://github.com/qgis/QGIS-Certification-Website/pull/102> [Deployed]

*QGIS Infrastructure:*

With the valuable input from Tim and Ivan, we have been busy migrating more
hosts, such as download.qgis.org, in.qgis.org and id.qgis.org, into the new
infrastructure. After some more rounds of tweaking, other hosts will also
be migrated.

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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260625/5eebe848/attachment-0001.htm>

From tim at kartoza.com  Thu Jun 25 09:42:30 2026
From: tim at kartoza.com (Tim Sutton)
Date: Thu, 25 Jun 2026 17:42:30 +0100
Subject: [QGIS-Developer] R: Tightening AI submission policy?
In-Reply-To: <CAB28AsjcDrcFn1s1khmd4YaQ1t5DD_q0Np2B6hPt3T-O5gXrdg@mail.gmail.com>
References: <CAB28AsiANEpuuPr0Kvk-Sk6WMTbsHSE8YfmvtrEgmsz9BGTugw@mail.gmail.com>
 <CAL5Q670ogXZSe29LUA7wkJYeBj3x3XcJqjf=BWv4qBLExQTXwA@mail.gmail.com>
 <28be1e91-ddc6-40fb-b562-69592ba77586@oslandia.com>
 <VI0P191MB29652D034FF609A7D718A471FBEE2@VI0P191MB2965.EURP191.PROD.OUTLOOK.COM>
 <20260623082634.c4g564cbisgsutpx@norbit.de>
 <CAES-DZSra552wZH0vUzXfhz9hV1mcdx+csdyXtAgKR2w8S_LuA@mail.gmail.com>
 <CAB28AsjcDrcFn1s1khmd4YaQ1t5DD_q0Np2B6hPt3T-O5gXrdg@mail.gmail.com>
Message-ID: <CAES-DZQ7Z-M+DA+P1wAVGwaqPJd70S0Caj9Lom3j=w58DZxg5w@mail.gmail.com>

Hi

On Thu, Jun 25, 2026 at 7:14?AM Nyall Dawson <nyall.dawson at gmail.com> wrote:

> On Tue, 23 Jun 2026 at 20:37, Tim Sutton via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
> >
> > Hi
> >
> >
> > Can we clarify what the scope of this change is? We internally use LLM
> assistances a lot for the web development work we do on various QGIS sites.
> Are you suggesting this as a global QGIS.org policy or scoped the the QGIS
> application code base?
>
> IMO the QEP policies only apply to the qgis/qgis repository, so no, it
> wouldn't directly impact the web development. But I'd also say that a
> "Contribute only what you understand" principle would be a good one to
> adopt for EVERY qgis repo.
>

Sure, that is a given. Thanks.

Regards

Tim



>
> Nyall
>
> >
> > Regards
> >
> > Tim
> >
> >
> >
> > On Tue, Jun 23, 2026 at 9:26?AM J?rgen E. Fischer via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
> >>
> >> Hi,
> >>
> >> On Tue, 23. Jun 2026 at 08:19:18 +0000, Ludovico Toscano via
> QGIS-Developer wrote:
> >> > I have an idea which is saw implemented in ghostty, to prevent
> contribution from bot or vibe coders. Basically the author of the repo has
> made a honeypot for these agents, he has made a AGENTS.md and a CLAUDE.md
> where in the last line of the document he tell the model to make a md file
> that saing "I am a sad, dumb little AI driver with no real skills." His
> idea is simple, if the author of the pr doesn't read the diff of the pr he
> will not notice that the LLM has added this file and this trigger a
> immediate ban.
> >> >
> >> > https://github.com/ghostty-org/ghostty/blob/main/AGENTS.md
> >>
> >> See also https://github.com/OSGeo/gdal/blob/master/AGENTS.md
> >>
> >> J?rgen
> >>
> >> --
> >> J?rgen E. Fischer           norBIT GmbH             Tel.
> +49-4931-918175-31
> >> Dipl.-Inf. (FH)             Rheinstra?e 13          Fax.
> +49-4931-918175-50
> >> Software Engineer           D-26506 Norden
> https://www.norbit.de
> >> QGIS release manager (PSC)  Germany                  Matrix: @jef:
> osgeo.org
> >> _______________________________________________
> >> 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
> >
> >
> >
> > --
> >
> > Tim Sutton
> > Kartoza Cofounder
> > Tim is a member of the QGIS Project Steering Committee
> >
> > T : +27(0) 87 809 2702          E : tim 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.
> > _______________________________________________
> > 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
>


-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260625/1918c94a/attachment.htm>

From nyall.dawson at gmail.com  Thu Jun 25 14:11:21 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 26 Jun 2026 07:11:21 +1000
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <87wlvmixme.fsf@julienlaptop.home>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
 <87wlvmixme.fsf@julienlaptop.home>
Message-ID: <CAB28Asg56uD7nYV4i+wqAjsnE8H_+oSaPRmgxDWSXQMza7mbrg@mail.gmail.com>

On Thu, 25 Jun 2026 at 22:59, Julien Cabieces
<julien.cabieces at oslandia.com> wrote:
>
>
> I would also be in favor on given up auto-merge to avoid blocking
> approved pull requests with unrelated test failures.

Ok, it's done -- all build/test rules are now disabled.


Nyall



>
> At least, until we manage to strengthen our CI. I don't mind to ping you
> or anyone else once in a while but I don't want to have to do it every
> time. And at the moment the CI is very often broken.
>
> Regards,
> Julien
>
>
> > Hi Nyall,
> >
> > your answer doesn't really answer my question :-) Is the restriction for every committer or a subset?
> >
> > Who has rights for changing qgis/qgis github settings? (not necessarily asking for them to be extended, but just so we know). It would be good
> > to communicate when some settings that might affect workflows are adjusted
> >
> > I'd say that we should probably give up for now to auto-merge if it blocks approved pull requests from being merged
> >
> > Even
> >
> > Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
> >
> >  On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <qgis-developer at lists.osgeo.org> wrote:
> >
> >  Hi Julien,
> >
> >  I just tried looking at your PR [0] and I also don't seem to have the
> >  right to force merge it (only "auto-merge" rights that depend on green CI)
> >
> >  It would be indeed great to have some clarification of who might have
> >  such rights or not, so we can see if there isn't a bottleneck that must
> >  be resolved. I'm not sure why we would want such rights to be restricted
> >  to a subset of people with "regular" merge rights rather than the whole
> >  group.
> >
> >  An alternative would be to remove the merge rules which require tests to pass -- that'd avoid expanding rights while still allowing the
> >  blockage to be removed.
> >
> >  (Downside is that doing this breaks the ability to "auto merge")
> >
> >  Nyall
> >
> >  Even
> >
> >  Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
> >  > Hi devs,
> >  >
> >  > I cannot merge PR #66483 [0] because there is at least one unrelated
> >  > test failure every time the CI is launched (I restarted it 7 times), although the PR was approved
> >  > 6 days ago.
> >  >
> >  > I have already tackled the issue of the test_gui_fileuploader [1] which was
> >  > failing very often recently because of badssl.com being unstable but there
> >  > are now other issues.
> >  >
> >  > A few months ago, I had the rights to merge a PR even if tests were
> >  > failing, but I don't have them anymore and I cannot contribute anymore
> >  > on #66483 related issues (I have more fix commits based on this PR).
> >  >
> >  > It seems to me that other code committers still have these rights as I see
> >  > PRs with a red CI still being merged.
> >  >
> >  > May I have these rights too so I can continue to contribute normally?
> >  >
> >  > Shall every core committer have these rights ?
> >  >
> >  > Kind regards,
> >  > Julien
> >  >
> >  > [0] https://github.com/qgis/QGIS/pull/66483
> >  > [1] https://github.com/qgis/QGIS/pull/66543
> >  >
> >  --
> >  http://www.spatialys.com
> >  My software is free, but my time generally not.
> >  LLMs contribute to global warming and brain rot
> >
> >  _______________________________________________
> >  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 nyall.dawson at gmail.com  Thu Jun 25 14:14:47 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 26 Jun 2026 07:14:47 +1000
Subject: [QGIS-Developer] PSA: do NOT EVER use auto merge!
Message-ID: <CAB28AsjyjoHQomsJii5uJx=CV54yM-+jstRD4-RuybVkkbwwTQ@mail.gmail.com>

Hey all,

Following the "Rights to merge Pull Request even if CI is red" discussion,
we've now disabled the Github rules requiring PRs to pass tests prior to
merging.

By doing this we've now effectively shadow-broken Github's auto-merge
facility.

???***If you click that button now, the PR will merge EVEN IF IT HAS
BROKEN TESTS***. Just don't ever click that button anymore.???

(Unfortunately there's no way to actually disable this functionality on a
repo, so we just have to live with this risk)

Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/a9007903/attachment-0001.htm>

From nyall.dawson at gmail.com  Thu Jun 25 14:19:30 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 26 Jun 2026 07:19:30 +1000
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
Message-ID: <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>

On Thu, 25 Jun 2026 at 21:39, Even Rouault <even.rouault at spatialys.com>
wrote:
>
> Hi Nyall,
>
> your answer doesn't really answer my question :-) Is the restriction for
every committer or a subset?
>
> Who has rights for changing qgis/qgis github settings? (not necessarily
asking for them to be extended, but just so we know). It would be good to
communicate when some settings that might affect workflows are adjusted

We're definitely overdue for an overhaul on our github rights. Our current
policy is LAUGHABLY ridiculous (basically "you get merge rights once,
you've got them for life... even if you go off to work for ESRI or
disappear off the face of the earth" ?).

It's not a discussion I feel like leading though. I tried once, and just
got flamed for even bringing it up.

Nyall





>
> I'd say that we should probably give up for now to auto-merge if it
blocks approved pull requests from being merged
>
> Even
>
> Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
>
>
>
> On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <
qgis-developer at lists.osgeo.org> wrote:
>>
>> Hi Julien,
>>
>> I just tried looking at your PR [0] and I also don't seem to have the
>> right to force merge it (only "auto-merge" rights that depend on green
CI)
>>
>> It would be indeed great to have some clarification of who might have
>> such rights or not, so we can see if there isn't a bottleneck that must
>> be resolved. I'm not sure why we would want such rights to be restricted
>> to a subset of people with "regular" merge rights rather than the whole
>> group.
>
>
> An alternative would be to remove the merge rules which require tests to
pass -- that'd avoid expanding rights while still allowing the blockage to
be removed.
>
> (Downside is that doing this breaks the ability to "auto merge")
>
> Nyall
>>
>>
>> Even
>>
>> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
>> > Hi devs,
>> >
>> > I cannot merge PR #66483 [0] because there is at least one unrelated
>> > test failure every time the CI is launched (I restarted it 7 times),
although the PR was approved
>> > 6 days ago.
>> >
>> > I have already tackled the issue of the test_gui_fileuploader [1]
which was
>> > failing very often recently because of badssl.com being unstable but
there
>> > are now other issues.
>> >
>> > A few months ago, I had the rights to merge a PR even if tests were
>> > failing, but I don't have them anymore and I cannot contribute anymore
>> > on #66483 related issues (I have more fix commits based on this PR).
>> >
>> > It seems to me that other code committers still have these rights as I
see
>> > PRs with a red CI still being merged.
>> >
>> > May I have these rights too so I can continue to contribute normally?
>> >
>> > Shall every core committer have these rights ?
>> >
>> > Kind regards,
>> > Julien
>> >
>> > [0] https://github.com/qgis/QGIS/pull/66483
>> > [1] https://github.com/qgis/QGIS/pull/66543
>> >
>> --
>> http://www.spatialys.com
>> My software is free, but my time generally not.
>> LLMs contribute to global warming and brain rot
>>
>> _______________________________________________
>> 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.
> LLMs contribute to global warming and brain rot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/5d4eff54/attachment.htm>

From tim at kartoza.com  Thu Jun 25 23:18:05 2026
From: tim at kartoza.com (Tim Sutton)
Date: Fri, 26 Jun 2026 07:18:05 +0100
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
 <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>
Message-ID: <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>

Hi

Ill add it to the next PSC agenda - we can get flamed there instead :-P

Regards

Tim

On Thu, Jun 25, 2026 at 10:19?PM Nyall Dawson via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

>
>
> On Thu, 25 Jun 2026 at 21:39, Even Rouault <even.rouault at spatialys.com>
> wrote:
> >
> > Hi Nyall,
> >
> > your answer doesn't really answer my question :-) Is the restriction for
> every committer or a subset?
> >
> > Who has rights for changing qgis/qgis github settings? (not necessarily
> asking for them to be extended, but just so we know). It would be good to
> communicate when some settings that might affect workflows are adjusted
>
> We're definitely overdue for an overhaul on our github rights. Our current
> policy is LAUGHABLY ridiculous (basically "you get merge rights once,
> you've got them for life... even if you go off to work for ESRI or
> disappear off the face of the earth" ?).
>
> It's not a discussion I feel like leading though. I tried once, and just
> got flamed for even bringing it up.
>
> Nyall
>
>
>
>
>
> >
> > I'd say that we should probably give up for now to auto-merge if it
> blocks approved pull requests from being merged
> >
> > Even
> >
> > Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
> >
> >
> >
> > On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <
> qgis-developer at lists.osgeo.org> wrote:
> >>
> >> Hi Julien,
> >>
> >> I just tried looking at your PR [0] and I also don't seem to have the
> >> right to force merge it (only "auto-merge" rights that depend on green
> CI)
> >>
> >> It would be indeed great to have some clarification of who might have
> >> such rights or not, so we can see if there isn't a bottleneck that must
> >> be resolved. I'm not sure why we would want such rights to be restricted
> >> to a subset of people with "regular" merge rights rather than the whole
> >> group.
> >
> >
> > An alternative would be to remove the merge rules which require tests to
> pass -- that'd avoid expanding rights while still allowing the blockage to
> be removed.
> >
> > (Downside is that doing this breaks the ability to "auto merge")
> >
> > Nyall
> >>
> >>
> >> Even
> >>
> >> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
> >> > Hi devs,
> >> >
> >> > I cannot merge PR #66483 [0] because there is at least one unrelated
> >> > test failure every time the CI is launched (I restarted it 7 times),
> although the PR was approved
> >> > 6 days ago.
> >> >
> >> > I have already tackled the issue of the test_gui_fileuploader [1]
> which was
> >> > failing very often recently because of badssl.com being unstable but
> there
> >> > are now other issues.
> >> >
> >> > A few months ago, I had the rights to merge a PR even if tests were
> >> > failing, but I don't have them anymore and I cannot contribute anymore
> >> > on #66483 related issues (I have more fix commits based on this PR).
> >> >
> >> > It seems to me that other code committers still have these rights as
> I see
> >> > PRs with a red CI still being merged.
> >> >
> >> > May I have these rights too so I can continue to contribute normally?
> >> >
> >> > Shall every core committer have these rights ?
> >> >
> >> > Kind regards,
> >> > Julien
> >> >
> >> > [0] https://github.com/qgis/QGIS/pull/66483
> >> > [1] https://github.com/qgis/QGIS/pull/66543
> >> >
> >> --
> >> http://www.spatialys.com
> >> My software is free, but my time generally not.
> >> LLMs contribute to global warming and brain rot
> >>
> >> _______________________________________________
> >> 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.
> > LLMs contribute to global warming and brain rot
> _______________________________________________
> 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
>


-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/66d33cbb/attachment-0001.htm>

From nyall.dawson at gmail.com  Thu Jun 25 23:28:31 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 26 Jun 2026 16:28:31 +1000
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
 <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>
 <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>
Message-ID: <CAB28AsjrHJnu-9gvR_TDxZ=A_XCNrMkJzp65U=AXMHbRzaWB2g@mail.gmail.com>

On Fri, 26 Jun 2026 at 16:18, Tim Sutton <tim at kartoza.com> wrote:

> Hi
>
> Ill add it to the next PSC agenda - we can get flamed there instead :-P
>

Thanks Tim, it's much appreciated.

My personal preference would be something like:

- we decouple "core committer" status from git rights. "core committer" is
just a recognition of skills alone. initially it comes with git rights, but
can outlast those.
- git rights expire automatically after a period of inactivity (say 6
months)
- developers who have previously had git rights but lost them due to
inactivity must go through some re-endorsement process to demonstrate that
they are up-to-date with current development policies and the current state
of the codebase

Happy to join in on a psc meeting to discuss if needed!

Nyall




>
> Regards
>
> Tim
>
> On Thu, Jun 25, 2026 at 10:19?PM Nyall Dawson via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>
>>
>>
>> On Thu, 25 Jun 2026 at 21:39, Even Rouault <even.rouault at spatialys.com>
>> wrote:
>> >
>> > Hi Nyall,
>> >
>> > your answer doesn't really answer my question :-) Is the restriction
>> for every committer or a subset?
>> >
>> > Who has rights for changing qgis/qgis github settings? (not necessarily
>> asking for them to be extended, but just so we know). It would be good to
>> communicate when some settings that might affect workflows are adjusted
>>
>> We're definitely overdue for an overhaul on our github rights. Our
>> current policy is LAUGHABLY ridiculous (basically "you get merge rights
>> once, you've got them for life... even if you go off to work for ESRI or
>> disappear off the face of the earth" ?).
>>
>> It's not a discussion I feel like leading though. I tried once, and just
>> got flamed for even bringing it up.
>>
>> Nyall
>>
>>
>>
>>
>>
>> >
>> > I'd say that we should probably give up for now to auto-merge if it
>> blocks approved pull requests from being merged
>> >
>> > Even
>> >
>> > Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
>> >
>> >
>> >
>> > On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <
>> qgis-developer at lists.osgeo.org> wrote:
>> >>
>> >> Hi Julien,
>> >>
>> >> I just tried looking at your PR [0] and I also don't seem to have the
>> >> right to force merge it (only "auto-merge" rights that depend on green
>> CI)
>> >>
>> >> It would be indeed great to have some clarification of who might have
>> >> such rights or not, so we can see if there isn't a bottleneck that must
>> >> be resolved. I'm not sure why we would want such rights to be
>> restricted
>> >> to a subset of people with "regular" merge rights rather than the whole
>> >> group.
>> >
>> >
>> > An alternative would be to remove the merge rules which require tests
>> to pass -- that'd avoid expanding rights while still allowing the blockage
>> to be removed.
>> >
>> > (Downside is that doing this breaks the ability to "auto merge")
>> >
>> > Nyall
>> >>
>> >>
>> >> Even
>> >>
>> >> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
>> >> > Hi devs,
>> >> >
>> >> > I cannot merge PR #66483 [0] because there is at least one unrelated
>> >> > test failure every time the CI is launched (I restarted it 7 times),
>> although the PR was approved
>> >> > 6 days ago.
>> >> >
>> >> > I have already tackled the issue of the test_gui_fileuploader [1]
>> which was
>> >> > failing very often recently because of badssl.com being unstable
>> but there
>> >> > are now other issues.
>> >> >
>> >> > A few months ago, I had the rights to merge a PR even if tests were
>> >> > failing, but I don't have them anymore and I cannot contribute
>> anymore
>> >> > on #66483 related issues (I have more fix commits based on this PR).
>> >> >
>> >> > It seems to me that other code committers still have these rights as
>> I see
>> >> > PRs with a red CI still being merged.
>> >> >
>> >> > May I have these rights too so I can continue to contribute normally?
>> >> >
>> >> > Shall every core committer have these rights ?
>> >> >
>> >> > Kind regards,
>> >> > Julien
>> >> >
>> >> > [0] https://github.com/qgis/QGIS/pull/66483
>> >> > [1] https://github.com/qgis/QGIS/pull/66543
>> >> >
>> >> --
>> >> http://www.spatialys.com
>> >> My software is free, but my time generally not.
>> >> LLMs contribute to global warming and brain rot
>> >>
>> >> _______________________________________________
>> >> 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.
>> > LLMs contribute to global warming and brain rot
>> _______________________________________________
>> 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
>>
>
>
> --
>
> Tim Sutton
>
> *Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee
>
> *T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/89d83da0/attachment.htm>

From tim at kartoza.com  Fri Jun 26 00:26:29 2026
From: tim at kartoza.com (Tim Sutton)
Date: Fri, 26 Jun 2026 08:26:29 +0100
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <CAB28AsjrHJnu-9gvR_TDxZ=A_XCNrMkJzp65U=AXMHbRzaWB2g@mail.gmail.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
 <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>
 <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>
 <CAB28AsjrHJnu-9gvR_TDxZ=A_XCNrMkJzp65U=AXMHbRzaWB2g@mail.gmail.com>
Message-ID: <CAES-DZSx77qFza-sJYUVhaQ-HHgLnBO2VCTtGigpoWxB_zOe6w@mail.gmail.com>

Hi



On Fri, Jun 26, 2026 at 7:28?AM Nyall Dawson <nyall.dawson at gmail.com> wrote:

>
>
> On Fri, 26 Jun 2026 at 16:18, Tim Sutton <tim at kartoza.com> wrote:
>
>> Hi
>>
>> Ill add it to the next PSC agenda - we can get flamed there instead :-P
>>
>
> Thanks Tim, it's much appreciated.
>
> My personal preference would be something like:
>
> - we decouple "core committer" status from git rights. "core committer" is
> just a recognition of skills alone. initially it comes with git rights, but
> can outlast those.
> - git rights expire automatically after a period of inactivity (say 6
> months)
> - developers who have previously had git rights but lost them due to
> inactivity must go through some re-endorsement process to demonstrate that
> they are up-to-date with current development policies and the current state
> of the codebase
>
> Happy to join in on a psc meeting to discuss if needed!
>
> Nyall
>
>
Thanks, noted. I'll add you to the next PSC meeting invite list - not sure
if it is an ungodly hour for you...if it is we can try to do an out of band
special interest call at an hour that fits your schedule too...


Regards

Tim



>
>
>
>>
>> Regards
>>
>> Tim
>>
>> On Thu, Jun 25, 2026 at 10:19?PM Nyall Dawson via QGIS-Developer <
>> qgis-developer at lists.osgeo.org> wrote:
>>
>>>
>>>
>>> On Thu, 25 Jun 2026 at 21:39, Even Rouault <even.rouault at spatialys.com>
>>> wrote:
>>> >
>>> > Hi Nyall,
>>> >
>>> > your answer doesn't really answer my question :-) Is the restriction
>>> for every committer or a subset?
>>> >
>>> > Who has rights for changing qgis/qgis github settings? (not
>>> necessarily asking for them to be extended, but just so we know). It would
>>> be good to communicate when some settings that might affect workflows are
>>> adjusted
>>>
>>> We're definitely overdue for an overhaul on our github rights. Our
>>> current policy is LAUGHABLY ridiculous (basically "you get merge rights
>>> once, you've got them for life... even if you go off to work for ESRI or
>>> disappear off the face of the earth" ?).
>>>
>>> It's not a discussion I feel like leading though. I tried once, and just
>>> got flamed for even bringing it up.
>>>
>>> Nyall
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > I'd say that we should probably give up for now to auto-merge if it
>>> blocks approved pull requests from being merged
>>> >
>>> > Even
>>> >
>>> > Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
>>> >
>>> >
>>> >
>>> > On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <
>>> qgis-developer at lists.osgeo.org> wrote:
>>> >>
>>> >> Hi Julien,
>>> >>
>>> >> I just tried looking at your PR [0] and I also don't seem to have the
>>> >> right to force merge it (only "auto-merge" rights that depend on
>>> green CI)
>>> >>
>>> >> It would be indeed great to have some clarification of who might have
>>> >> such rights or not, so we can see if there isn't a bottleneck that
>>> must
>>> >> be resolved. I'm not sure why we would want such rights to be
>>> restricted
>>> >> to a subset of people with "regular" merge rights rather than the
>>> whole
>>> >> group.
>>> >
>>> >
>>> > An alternative would be to remove the merge rules which require tests
>>> to pass -- that'd avoid expanding rights while still allowing the blockage
>>> to be removed.
>>> >
>>> > (Downside is that doing this breaks the ability to "auto merge")
>>> >
>>> > Nyall
>>> >>
>>> >>
>>> >> Even
>>> >>
>>> >> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
>>> >> > Hi devs,
>>> >> >
>>> >> > I cannot merge PR #66483 [0] because there is at least one unrelated
>>> >> > test failure every time the CI is launched (I restarted it 7
>>> times), although the PR was approved
>>> >> > 6 days ago.
>>> >> >
>>> >> > I have already tackled the issue of the test_gui_fileuploader [1]
>>> which was
>>> >> > failing very often recently because of badssl.com being unstable
>>> but there
>>> >> > are now other issues.
>>> >> >
>>> >> > A few months ago, I had the rights to merge a PR even if tests were
>>> >> > failing, but I don't have them anymore and I cannot contribute
>>> anymore
>>> >> > on #66483 related issues (I have more fix commits based on this PR).
>>> >> >
>>> >> > It seems to me that other code committers still have these rights
>>> as I see
>>> >> > PRs with a red CI still being merged.
>>> >> >
>>> >> > May I have these rights too so I can continue to contribute
>>> normally?
>>> >> >
>>> >> > Shall every core committer have these rights ?
>>> >> >
>>> >> > Kind regards,
>>> >> > Julien
>>> >> >
>>> >> > [0] https://github.com/qgis/QGIS/pull/66483
>>> >> > [1] https://github.com/qgis/QGIS/pull/66543
>>> >> >
>>> >> --
>>> >> http://www.spatialys.com
>>> >> My software is free, but my time generally not.
>>> >> LLMs contribute to global warming and brain rot
>>> >>
>>> >> _______________________________________________
>>> >> 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.
>>> > LLMs contribute to global warming and brain rot
>>> _______________________________________________
>>> 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
>>>
>>
>>
>> --
>>
>> Tim Sutton
>>
>> *Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee
>>
>> *T *: +27(0) 87 809 2702          *E *: tim 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.*
>>
>

-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/dcdad705/attachment-0001.htm>

From Mike.Elstermann at itc-halle.de  Fri Jun 26 01:05:03 2026
From: Mike.Elstermann at itc-halle.de (Elstermann, Mike)
Date: Fri, 26 Jun 2026 08:05:03 +0000
Subject: [QGIS-Developer] Problem with flake8 W503 vs. W504
Message-ID: <598F79AE-E731-45F7-8760-058843C6C526@itc-halle.de>

Hello everyone,


I?m having a problem with the plugin check using flake8. W503 and W504 seem to contradict each other ? the AI thinks so too ;-)


Option 1: if I write:


    A

    and B


the following error is reported:

W503: line break before binary operator ? complains about

Option 2: if I write:


    A and

    B


the following error is reported:

W504: line break after binary operator ? complains about


The AI says that Option 1 is better and that I should ignore W503 and, ideally, relax the rule. What do you think?

Best regards, mikeE.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/7f7a9803/attachment.htm>

From julien.moura at oslandia.com  Fri Jun 26 01:30:39 2026
From: julien.moura at oslandia.com (Julien Moura (Oslandia))
Date: Fri, 26 Jun 2026 10:30:39 +0200
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
 <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>
 <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>
Message-ID: <287a29a0-d02e-4fce-a886-6ec20adaa000@oslandia.com>

Hello,

+1 to

The discussions 
(https://github.com/qgis/QGIS-Enhancement-Proposals/pull/325)?were 
certainly lively and intense, but truly interesting. IMHO it's a 
necessary topic. Perhaps if the PSC takes up the issue, it can be 
handled with the necessary semblance of governance legitimacy to find a 
path to consensus without putting you personally at risk, Nyall.

Julien

Le 26/06/2026 ? 08:18, Tim Sutton via QGIS-Developer a ?crit?:
> Hi
>
> Ill add it to the next PSC agenda - we can get flamed there instead :-P
>
> Regards
>
> Tim
>
> On Thu, Jun 25, 2026 at 10:19?PM Nyall Dawson via QGIS-Developer 
> <qgis-developer at lists.osgeo.org> wrote:
>
>
>
>     On Thu, 25 Jun 2026 at 21:39, Even Rouault
>     <even.rouault at spatialys.com> wrote:
>     >
>     > Hi Nyall,
>     >
>     > your answer doesn't really answer my question :-) Is the
>     restriction for every committer or a subset?
>     >
>     > Who has rights for changing qgis/qgis github settings? (not
>     necessarily asking for them to be extended, but just so we know).
>     It would be good to communicate when some settings that might
>     affect workflows are adjusted
>
>     We're definitely overdue for an overhaul on our github rights. Our
>     current policy is LAUGHABLY ridiculous (basically "you get merge
>     rights once, you've got them for life... even if you go off to
>     work for ESRI or disappear off the face of the earth" ?).
>
>     It's not a discussion I feel like leading though. I tried once,
>     and just got flamed for even bringing it up.
>
>     Nyall
>
>
>
>
>
>     >
>     > I'd say that we should probably give up for now to auto-merge if
>     it blocks approved pull requests from being merged
>     >
>     > Even
>     >
>     > Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
>     >
>     >
>     >
>     > On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer,
>     <qgis-developer at lists.osgeo.org> wrote:
>     >>
>     >> Hi Julien,
>     >>
>     >> I just tried looking at your PR [0] and I also don't seem to
>     have the
>     >> right to force merge it (only "auto-merge" rights that depend
>     on green CI)
>     >>
>     >> It would be indeed great to have some clarification of who
>     might have
>     >> such rights or not, so we can see if there isn't a bottleneck
>     that must
>     >> be resolved. I'm not sure why we would want such rights to be
>     restricted
>     >> to a subset of people with "regular" merge rights rather than
>     the whole
>     >> group.
>     >
>     >
>     > An alternative would be to remove the merge rules which require
>     tests to pass -- that'd avoid expanding rights while still
>     allowing the blockage to be removed.
>     >
>     > (Downside is that doing this breaks the ability to "auto merge")
>     >
>     > Nyall
>     >>
>     >>
>     >> Even
>     >>
>     >> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
>     >> > Hi devs,
>     >> >
>     >> > I cannot merge PR #66483 [0] because there is at least one
>     unrelated
>     >> > test failure every time the CI is launched (I restarted it 7
>     times), although the PR was approved
>     >> > 6 days ago.
>     >> >
>     >> > I have already tackled the issue of the test_gui_fileuploader
>     [1] which was
>     >> > failing very often recently because of badssl.com
>     <http://badssl.com> being unstable but there
>     >> > are now other issues.
>     >> >
>     >> > A few months ago, I had the rights to merge a PR even if
>     tests were
>     >> > failing, but I don't have them anymore and I cannot
>     contribute anymore
>     >> > on #66483 related issues (I have more fix commits based on
>     this PR).
>     >> >
>     >> > It seems to me that other code committers still have these
>     rights as I see
>     >> > PRs with a red CI still being merged.
>     >> >
>     >> > May I have these rights too so I can continue to contribute
>     normally?
>     >> >
>     >> > Shall every core committer have these rights ?
>     >> >
>     >> > Kind regards,
>     >> > Julien
>     >> >
>     >> > [0] https://github.com/qgis/QGIS/pull/66483
>     >> > [1] https://github.com/qgis/QGIS/pull/66543
>     >> >
>     >> --
>     >> http://www.spatialys.com
>     >> My software is free, but my time generally not.
>     >> LLMs contribute to global warming and brain rot
>     >>
>     >> _______________________________________________
>     >> 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.
>     > LLMs contribute to global warming and brain rot
>     _______________________________________________
>     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
>
>
>
> -- 
>
> Tim Sutton
> *Kartoza Cofounder
> *Tim is a member of the QGIS Project Steering Committee*
> *
> *
> *
> *T *:?+27(0) 87 809 2702 *E *:**tim at kartoza.com *W*?: kartoza.com 
> <http://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./
>
> _______________________________________________
> 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
-- 
Oslandia 
<https://oslandia.com/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email> 
- Livre blanc pour migrer/hybrider son SIG 
<https://oslandia.com/livre-blanc-migration-sig-opensource/?utm_source=email&utm_campaign=signature_oslandia&utm_medium=email>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/ed2d065b/attachment.sig>

From vincent.ml at oslandia.com  Fri Jun 26 02:05:32 2026
From: vincent.ml at oslandia.com (Vincent Picavet)
Date: Fri, 26 Jun 2026 11:05:32 +0200
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <CAB28AsjrHJnu-9gvR_TDxZ=A_XCNrMkJzp65U=AXMHbRzaWB2g@mail.gmail.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
 <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>
 <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>
 <CAB28AsjrHJnu-9gvR_TDxZ=A_XCNrMkJzp65U=AXMHbRzaWB2g@mail.gmail.com>
Message-ID: <e0fc93fd-d5b8-4a40-825e-4fef252e7ebd@oslandia.com>

Hi,

One additional remark below.

On 26/06/2026 08:28, Nyall Dawson via QGIS-Developer wrote:
> - we decouple "core committer" status from git rights. "core committer" is just a recognition of skills alone. initially it comes with git rights, but can outlast those.

If we do this, we must clarify the QGIS community voting member election, since right now it is voted by "QGIS Committers" as per :

https://www.qgis.org/community/organisation/

It would require changing the project organisation rules, even if it is only to clarify semantics. What is the process for that ?


Best regards,

Vincent



> - git rights expire automatically after a period of inactivity (say 6 months)
> - developers who have previously had git rights but lost them due to inactivity must go through some re-endorsement process to demonstrate that they are up-to-date with current development policies and the current state of the codebase
>
> Happy to join in on a psc meeting to discuss if needed!
>
> Nyall
>
>
>
>     Regards
>
>     Tim
>
>     On Thu, Jun 25, 2026 at 10:19?PM Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>
>
>
>         On Thu, 25 Jun 2026 at 21:39, Even Rouault <even.rouault at spatialys.com> wrote:
>         >
>         > Hi Nyall,
>         >
>         > your answer doesn't really answer my question :-) Is the restriction for every committer or a subset?
>         >
>         > Who has rights for changing qgis/qgis github settings? (not necessarily asking for them to be extended, but just so we know). It would be good to communicate when some settings that might affect workflows are adjusted
>
>         We're definitely overdue for an overhaul on our github rights. Our current policy is LAUGHABLY ridiculous (basically "you get merge rights once, you've got them for life... even if you go off to work for ESRI or disappear off the face of the earth" ?).
>
>         It's not a discussion I feel like leading though. I tried once, and just got flamed for even bringing it up.
>
>         Nyall
>
>
>
>
>
>         >
>         > I'd say that we should probably give up for now to auto-merge if it blocks approved pull requests from being merged
>         >
>         > Even
>         >
>         > Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
>         >
>         >
>         >
>         > On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <qgis-developer at lists.osgeo.org> wrote:
>         >>
>         >> Hi Julien,
>         >>
>         >> I just tried looking at your PR [0] and I also don't seem to have the
>         >> right to force merge it (only "auto-merge" rights that depend on green CI)
>         >>
>         >> It would be indeed great to have some clarification of who might have
>         >> such rights or not, so we can see if there isn't a bottleneck that must
>         >> be resolved. I'm not sure why we would want such rights to be restricted
>         >> to a subset of people with "regular" merge rights rather than the whole
>         >> group.
>         >
>         >
>         > An alternative would be to remove the merge rules which require tests to pass -- that'd avoid expanding rights while still allowing the blockage to be removed.
>         >
>         > (Downside is that doing this breaks the ability to "auto merge")
>         >
>         > Nyall
>         >>
>         >>
>         >> Even
>         >>
>         >> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
>         >> > Hi devs,
>         >> >
>         >> > I cannot merge PR #66483 [0] because there is at least one unrelated
>         >> > test failure every time the CI is launched (I restarted it 7 times), although the PR was approved
>         >> > 6 days ago.
>         >> >
>         >> > I have already tackled the issue of the test_gui_fileuploader [1] which was
>         >> > failing very often recently because of badssl.com <http://badssl.com> being unstable but there
>         >> > are now other issues.
>         >> >
>         >> > A few months ago, I had the rights to merge a PR even if tests were
>         >> > failing, but I don't have them anymore and I cannot contribute anymore
>         >> > on #66483 related issues (I have more fix commits based on this PR).
>         >> >
>         >> > It seems to me that other code committers still have these rights as I see
>         >> > PRs with a red CI still being merged.
>         >> >
>         >> > May I have these rights too so I can continue to contribute normally?
>         >> >
>         >> > Shall every core committer have these rights ?
>         >> >
>         >> > Kind regards,
>         >> > Julien
>         >> >
>         >> > [0] https://github.com/qgis/QGIS/pull/66483
>         >> > [1] https://github.com/qgis/QGIS/pull/66543
>         >> >
>         >> --
>         >> http://www.spatialys.com
>         >> My software is free, but my time generally not.
>         >> LLMs contribute to global warming and brain rot
>         >>
>         >> _______________________________________________
>         >> 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.
>         > LLMs contribute to global warming and brain rot
>         _______________________________________________
>         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
>
>
>
>     -- 
>
>     Tim Sutton
>     *Kartoza Cofounder
>     *Tim is a member of the QGIS Project Steering Committee*
>     *
>     *
>     *
>     *T *:?+27(0) 87 809 2702 *E *:**tim at kartoza.com *W*?: kartoza.com <http://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./
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/60210cdf/attachment-0001.htm>

From vincent.ml at oslandia.com  Fri Jun 26 02:12:36 2026
From: vincent.ml at oslandia.com (Vincent Picavet)
Date: Fri, 26 Jun 2026 11:12:36 +0200
Subject: [QGIS-Developer] Rights to merge Pull Request even if CI is red
In-Reply-To: <CAB28AsjrHJnu-9gvR_TDxZ=A_XCNrMkJzp65U=AXMHbRzaWB2g@mail.gmail.com>
References: <875x36kjei.fsf@julienlaptop.home>
 <780afca1-b2a5-429b-a505-ef4bc1a2213f@spatialys.com>
 <CAB28AsgHTB4JonD7Xfk5O60D=ibMQgopdaiMGLgzGNofXoPwJQ@mail.gmail.com>
 <bbaae1ec-fb37-43ea-a4d7-12c392846a86@spatialys.com>
 <CAB28Asjmfd58RPOqoxAtmwXa8jQfW6rbJ7AC2Cgvm4fbQXMyAw@mail.gmail.com>
 <CAES-DZSMW=d239DW_gX=B1jwug5EbQsMVd0u60NqT7mrv2ns5w@mail.gmail.com>
 <CAB28AsjrHJnu-9gvR_TDxZ=A_XCNrMkJzp65U=AXMHbRzaWB2g@mail.gmail.com>
Message-ID: <6a931801-ea1f-461b-a3c4-ba0b58e8ca40@oslandia.com>

Hi,

On 26/06/2026 08:28, Nyall Dawson via QGIS-Developer wrote:
>
>
> On Fri, 26 Jun 2026 at 16:18, Tim Sutton <tim at kartoza.com> wrote:
>
>     Hi
>
>
>
>     Ill add it to the next PSC agenda - we can get flamed there instead :-P
>
>
> Thanks Tim, it's much appreciated.

Glad to see this topic raised !

>
> My personal preference would be something like:
>
> - we decouple "core committer" status from git rights. "core committer" is just a recognition of skills alone. initially it comes with git rights, but can outlast those.
> - git rights expire automatically after a period of inactivity (say 6 months)
Big +1, also in terms of cybersecurity it would be a good decision.
> - developers who have previously had git rights but lost them due to inactivity must go through some re-endorsement process to demonstrate that they are up-to-date with current development policies and the current state of the codebase

Having some new contributions accepted should be enough to retrieve commit rights, as it implies being up-to-date with the codebase and policies.

Also, we need a public place where we have a list of current core committers and commit rights owner. Better if that is automatically updated.

Vincent

>
> Happy to join in on a psc meeting to discuss if needed!
>
> Nyall
>
>
>
>     Regards
>
>     Tim
>
>     On Thu, Jun 25, 2026 at 10:19?PM Nyall Dawson via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>
>
>
>         On Thu, 25 Jun 2026 at 21:39, Even Rouault <even.rouault at spatialys.com> wrote:
>         >
>         > Hi Nyall,
>         >
>         > your answer doesn't really answer my question :-) Is the restriction for every committer or a subset?
>         >
>         > Who has rights for changing qgis/qgis github settings? (not necessarily asking for them to be extended, but just so we know). It would be good to communicate when some settings that might affect workflows are adjusted
>
>         We're definitely overdue for an overhaul on our github rights. Our current policy is LAUGHABLY ridiculous (basically "you get merge rights once, you've got them for life... even if you go off to work for ESRI or disappear off the face of the earth" ?).
>
>         It's not a discussion I feel like leading though. I tried once, and just got flamed for even bringing it up.
>
>         Nyall
>
>
>
>
>
>         >
>         > I'd say that we should probably give up for now to auto-merge if it blocks approved pull requests from being merged
>         >
>         > Even
>         >
>         > Le 25/06/2026 ? 13:30, Nyall Dawson a ?crit :
>         >
>         >
>         >
>         > On Thu, 25 June 2026, 9:24?pm Even Rouault via QGIS-Developer, <qgis-developer at lists.osgeo.org> wrote:
>         >>
>         >> Hi Julien,
>         >>
>         >> I just tried looking at your PR [0] and I also don't seem to have the
>         >> right to force merge it (only "auto-merge" rights that depend on green CI)
>         >>
>         >> It would be indeed great to have some clarification of who might have
>         >> such rights or not, so we can see if there isn't a bottleneck that must
>         >> be resolved. I'm not sure why we would want such rights to be restricted
>         >> to a subset of people with "regular" merge rights rather than the whole
>         >> group.
>         >
>         >
>         > An alternative would be to remove the merge rules which require tests to pass -- that'd avoid expanding rights while still allowing the blockage to be removed.
>         >
>         > (Downside is that doing this breaks the ability to "auto merge")
>         >
>         > Nyall
>         >>
>         >>
>         >> Even
>         >>
>         >> Le 25/06/2026 ? 12:24, Julien Cabieces via QGIS-Developer a ?crit :
>         >> > Hi devs,
>         >> >
>         >> > I cannot merge PR #66483 [0] because there is at least one unrelated
>         >> > test failure every time the CI is launched (I restarted it 7 times), although the PR was approved
>         >> > 6 days ago.
>         >> >
>         >> > I have already tackled the issue of the test_gui_fileuploader [1] which was
>         >> > failing very often recently because of badssl.com <http://badssl.com> being unstable but there
>         >> > are now other issues.
>         >> >
>         >> > A few months ago, I had the rights to merge a PR even if tests were
>         >> > failing, but I don't have them anymore and I cannot contribute anymore
>         >> > on #66483 related issues (I have more fix commits based on this PR).
>         >> >
>         >> > It seems to me that other code committers still have these rights as I see
>         >> > PRs with a red CI still being merged.
>         >> >
>         >> > May I have these rights too so I can continue to contribute normally?
>         >> >
>         >> > Shall every core committer have these rights ?
>         >> >
>         >> > Kind regards,
>         >> > Julien
>         >> >
>         >> > [0] https://github.com/qgis/QGIS/pull/66483
>         >> > [1] https://github.com/qgis/QGIS/pull/66543
>         >> >
>         >> --
>         >> http://www.spatialys.com
>         >> My software is free, but my time generally not.
>         >> LLMs contribute to global warming and brain rot
>         >>
>         >> _______________________________________________
>         >> 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.
>         > LLMs contribute to global warming and brain rot
>         _______________________________________________
>         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
>
>
>
>     -- 
>
>     Tim Sutton
>     *Kartoza Cofounder
>     *Tim is a member of the QGIS Project Steering Committee*
>     *
>     *
>     *
>     *T *:?+27(0) 87 809 2702 *E *:**tim at kartoza.com *W*?: kartoza.com <http://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./
>
>
> _______________________________________________
> 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260626/c2b83fe2/attachment.htm>

From jan at dalheimer.de  Sun Jun 28 12:02:24 2026
From: jan at dalheimer.de (Jan Dalheimer)
Date: Sun, 28 Jun 2026 21:02:24 +0200
Subject: [QGIS-Developer] Approach for adding more OGC APIs to QGIS Server
Message-ID: <5f063739-6db9-419c-a181-b852205d9801@dalheimer.de>

Hello,

I've been wanting to implement more OGC APIs in QGIS Server but have run 
into a few questions I want to discuss before starting.

---

Currently, there's QgsServerOgcApi which is sort of a container for a 
single OGC API, and then handlers are registered to it for each 
endpoint. However, this is based on the assumption that each OGC API 
type is free-standing. However, the way OGC APIs have evolved, there's a 
strong incentive to combine OGC APIs and use them more like building 
blocks to build a complete API - you can have both OGC API Features, OGC 
API Tiles, and OGC API Styles "merged together", where Features and 
Tiles present the same data in the same collections optimized for 
different use-cases (Tiles for visualization at different scales, 
Features for picking individual objects given a set of filters) and 
Styles provide styles for rendering vector tiles from Tiles.

I can think of two main options:

A. Continue extending the wfs3 package with other OGC APIs. The name 
will be somewhat wrong/confusing but that's mostly to do with packaging 
and not something most users will notice. There'd be no way to install 
individual OGC APIs like you can with the older w[mfc]s packages, but 
the code changes to add new OGC APIs would be quite straightforward.
B. Put a "default" QgsServerOgcApi instance into QgsServiceRegistry and 
have one package per OGC API, which each add their handlers to the 
"default" QgsServerOgcApi rather than creating their own, while keeping 
the ability to create custom QgsServerOgcApi instances for backwards 
compatibility. A few changes to QgsServiceRegistry but nothing major, 
and makes it possible for plugins to extend the "default" OGC API 
endpoint. May want to put some functionality that's common across OGC 
APIs in the qgs_server target. The biggest challenge would be how to 
handle cross-OGC API-interactions, for example links between styles and 
tiles - maybe some sort of "link provider registry" which each OGC API 
endpoint handler calls to get additional links?

Personally, I'm leaning towards option A., it just feels way more 
straight-forward and easier to extend with additional OGC APIs, and I 
don't see that much value in having separate packages (but that might 
just be that I've not come across that use-case yet).

A third option would of course be to implement this in a plugin, however 
that would also require re-implementing the existing OGC API Features 
support in the plugin and I believe it makes sense for a standard 
implementation of the OGC APIs to exist in QGIS Server proper.

---

Also, are there any established guidelines when a new standard is 
accepted into QGIS Core? For example, would a PR with OGC API Styles 
(still in the draft stage) support be accepted? On the one hand I don't 
think there are any huge changes expected and implementation in major 
software can help the standard reach 1.0.0, on the other hand QGIS may 
then be stuck with an old version of the standard.

---

Regards,
Jan Dalheimer


From apasotti at gmail.com  Mon Jun 29 00:11:35 2026
From: apasotti at gmail.com (Alessandro Pasotti)
Date: Mon, 29 Jun 2026 09:11:35 +0200
Subject: [QGIS-Developer] Approach for adding more OGC APIs to QGIS
 Server
In-Reply-To: <5f063739-6db9-419c-a181-b852205d9801@dalheimer.de>
References: <5f063739-6db9-419c-a181-b852205d9801@dalheimer.de>
Message-ID: <CAL5Q672YR7ycu+3C-_qqikatn1XB76yAuiscspLnApUg5cPTNw@mail.gmail.com>

Hello Jan,

I am very happy to hear that you are interested in the OGC API server
development, I am currently busy implementing JSON-FG and schema
support as discussed in the QEP
https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-414-server-oapif-jsonfg-flatgeobuf.md

More comments in the text below:

On Sun, Jun 28, 2026 at 9:32?PM Jan Dalheimer via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hello,
>
> I've been wanting to implement more OGC APIs in QGIS Server but have run
> into a few questions I want to discuss before starting.
>
> ---
>
> Currently, there's QgsServerOgcApi which is sort of a container for a
> single OGC API, and then handlers are registered to it for each
> endpoint. However, this is based on the assumption that each OGC API
> type is free-standing. However, the way OGC APIs have evolved, there's a
> strong incentive to combine OGC APIs and use them more like building
> blocks to build a complete API - you can have both OGC API Features, OGC
> API Tiles, and OGC API Styles "merged together", where Features and
> Tiles present the same data in the same collections optimized for
> different use-cases (Tiles for visualization at different scales,
> Features for picking individual objects given a set of filters) and
> Styles provide styles for rendering vector tiles from Tiles.
>

You are right, when I started the implementation of what at the time
was called WFS3 (now OAPIF) it wasn't entirely clear to me how the
different API would eventually be glued together.

Thas said, despite the poor choice of classes and files names (e.g.
Wfs3 instead of OAPIF), I think that the foundational architecture of
the base classes wasn't so bad: there is even an example of a custom
API (not an OGC standard) that provides a catalog of QGIS projects
(again not named very well): the landing page.

The catalog (landing page) is also a good example of a separate
package that can be installed and activatetd separately.

> I can think of two main options:
>
> A. Continue extending the wfs3 package with other OGC APIs. The name
> will be somewhat wrong/confusing but that's mostly to do with packaging
> and not something most users will notice. There'd be no way to install
> individual OGC APIs like you can with the older w[mfc]s packages,

That's actually not correct (see the landing page/catalog): you can
definitely package and register APIs individually.

> but
> the code changes to add new OGC APIs would be quite straightforward.
> B. Put a "default" QgsServerOgcApi instance into QgsServiceRegistry and
> have one package per OGC API, which each add their handlers to the
> "default" QgsServerOgcApi rather than creating their own, while keeping
> the ability to create custom QgsServerOgcApi instances for backwards
> compatibility. A few changes to QgsServiceRegistry but nothing major,
> and makes it possible for plugins to extend the "default" OGC API
> endpoint. May want to put some functionality that's common across OGC
> APIs in the qgs_server target. The biggest challenge would be how to
> handle cross-OGC API-interactions, for example links between styles and
> tiles - maybe some sort of "link provider registry" which each OGC API
> endpoint handler calls to get additional links?
>
> Personally, I'm leaning towards option A., it just feels way more
> straight-forward and easier to extend with additional OGC APIs, and I
> don't see that much value in having separate packages (but that might
> just be that I've not come across that use-case yet).
>
> A third option would of course be to implement this in a plugin, however
> that would also require re-implementing the existing OGC API Features
> support in the plugin and I believe it makes sense for a standard
> implementation of the OGC APIs to exist in QGIS Server proper.
>
> ---
>
> Also, are there any established guidelines when a new standard is
> accepted into QGIS Core? For example, would a PR with OGC API Styles
> (still in the draft stage) support be accepted? On the one hand I don't
> think there are any huge changes expected and implementation in major
> software can help the standard reach 1.0.0, on the other hand QGIS may
> then be stuck with an old version of the standard.
>

My advice is to open a QEP for your proposed changes, we can discuss
the details there.

Kind regards.

--
ItOpen:   www.itopen.it

From simone.pittaluga at cnr.it  Mon Jun 29 07:58:24 2026
From: simone.pittaluga at cnr.it (SIMONE PITTALUGA)
Date: Mon, 29 Jun 2026 14:58:24 +0000
Subject: [QGIS-Developer] Plug-in approval process
Message-ID: <83F63BEB-D322-4568-8D17-719AAF6E7DE0@cnr.it>

Hello,


I?m new to plugin development. Last week, I submitted a plugin (ID: 5534) for publishing, but I haven?t received any feedback, either positive or negative, after a few days.


Could someone here help me understand if there are any further steps I need to take?


Thanks,

Simone



[X]

Simone Pittaluga
CNR - Istituto di Matematica Applicata
e Tecnologie Informatiche (IMATI)

Mobile +39 3283092555
Mail: simone.pittaluga at cnr.it<mailto:simone.pittaluga at cnr.it>
Via De Marini 6 ? 16149 Genova

Web: https://imati.cnr.it/mypage/people/PittalugaSimone.htm

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260629/a57191ef/attachment-0001.htm>

From tim at kartoza.com  Mon Jun 29 13:05:59 2026
From: tim at kartoza.com (Tim Sutton)
Date: Mon, 29 Jun 2026 21:05:59 +0100
Subject: [QGIS-Developer] Plug-in approval process
In-Reply-To: <83F63BEB-D322-4568-8D17-719AAF6E7DE0@cnr.it>
References: <83F63BEB-D322-4568-8D17-719AAF6E7DE0@cnr.it>
Message-ID: <CAES-DZTXN0DuKP7tKAA-_vOpUMjKFK4jX1EJvpyJJhTC6BjRBg@mail.gmail.com>

Dear Simone

Thank you for your email. Please note that the initial review of new
plugins is carried out by volunteers and the review process can take a few
days.

Regards

Tim

On Mon, Jun 29, 2026 at 3:58?PM SIMONE PITTALUGA via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hello,
>
>
> I?m new to plugin development. Last week, I submitted a plugin (ID: 5534)
> for publishing, but I haven?t received any feedback, either positive or
> negative, after a few days.
>
>
> Could someone here help me understand if there are any further steps I
> need to take?
>
>
> Thanks,
>
> Simone
>
>
> *Simone Pittaluga*
> CNR - Istituto di Matematica Applicata
> e Tecnologie Informatiche (IMATI)
>
> Mobile +39 3283092555
> Mail: simone.pittaluga at cnr.it
> Via De Marini 6 ? 16149 Genova
>
> Web: https://imati.cnr.it/mypage/people/PittalugaSimone.htm
>
> _______________________________________________
> 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
>


-- 

Tim Sutton

*Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee

*T *: +27(0) 87 809 2702          *E *: tim 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: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260629/802c3894/attachment.htm>

From julien.cabieces at oslandia.com  Tue Jun 30 05:44:12 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Tue, 30 Jun 2026 14:44:12 +0200
Subject: [QGIS-Developer] Announcing QEP 417: Replace SIP_FACTORY with
 std::unique_ptr
In-Reply-To: <87a4vcip0i.fsf@julienlaptop.home> (Julien Cabieces via's message
 of "Thu, 09 Apr 2026 09:14:37 +0200")
References: <87a4vcip0i.fsf@julienlaptop.home>
Message-ID: <87v7b0gpur.fsf@julienlaptop.home>


Hi all,

This QEP has ended the discussion phase and have been selected to be
part of the QGIS 2026 grant program. Please cast your vote so I
can start the proposed development.

Regards,
Julien



> 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 uclaros at gmail.com  Tue Jun 30 11:27:07 2026
From: uclaros at gmail.com (Stefanos Natsis)
Date: Tue, 30 Jun 2026 21:27:07 +0300
Subject: [QGIS-Developer] equals_exact confusion
Message-ID: <CADBCwLZYvwJy525RbPzwYorQi2qwdUh4T-UKuE7E1+98b1_OSw@mail.gmail.com>

Hi List,

During the last development cycle a few expression functions for geometry
comparison have been introduced [0], [1].
I'm afraid that the current implementation may lead to user confusion,
because now one can use:
- `equals_exact( geom1, geom2, 'QGIS' )` to check if two geometries are
fuzzy-equal within an epsilon of 1e-8
- `equals_fuzzy( geom1, geom2, 'QGIS', 1e-18 ) to check if two geometries
are fuzzy-equal within an epsilon of 1e-18
- `equals_exact( geom1, geom2 )` to get the exact same result as
`equals_fuzzy( geom1, geom2 )` using default parameters.

As it can be clearly seen, the _exact_ keyword is misleading, as only 8
decimal digits are used for the comparison.

I wonder if anyone else thinks will lead to user confusion and whether we
should be offering a single function for comparison with an optional
epsilon parameter.
So to practically keep the `equals_fuzzy()` implementation but with a
generic `equals()` name, like:
```
equals_fuzzy(geometry1,geometry2[,backend:='QGIS'][,epsilon:=1e-8])
```

Best,
Stefanos


[0] https://github.com/qgis/QGIS/pull/62603
[1] https://github.com/qgis/QGIS/pull/65674
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260630/290d077d/attachment.htm>