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>