From ijturton at gmail.com  Mon Aug  3 07:52:07 2026
From: ijturton at gmail.com (Ian Turton)
Date: Mon, 3 Aug 2026 15:52:07 +0100
Subject: [QGIS-Developer] How do I change the email associated with a plugin?
Message-ID: <CA+=cGJ=pP2AG0SWkVzQH38U9fE-eh1JR1CzNS0nbsBtf7J5g3A@mail.gmail.com>

I have discovered that one of my plugins is associated with an old work
address that no longer exists, how do I go about changing it?

It's https://plugins.qgis.org/plugins/osgb-plugin/#plugin-details if that
helps

Cheers

Ian

-- 
Ian Turton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260803/7e7a92ae/attachment.htm>

From r-yoshimi at coel-inc.jp  Mon Aug  3 23:58:15 2026
From: r-yoshimi at coel-inc.jp (=?big5?B?pk6ooyDU9w==?=)
Date: Tue, 4 Aug 2026 06:58:15 +0000
Subject: [QGIS-Developer] Line feature callout labels not rendering in
 headless/server QGIS 3.22, but work fine in Desktop 3.28
Message-ID: <OSZP286MB14196731EE708EAF12BFC963BDD42@OSZP286MB1419.JPNP286.PROD.OUTLOOK.COM>

Hi all,
My name is Yoshimi, a company employee based in Nagoya, Japan. I'm not a core GIS developer, but I've run into an issue during a project and would appreciate any pointers from this community.
I'm running into an issue where simple callout labels on LineString features fail to render at all when generated via a headless QGIS batch process (PyQGIS, Linux container), while the exact same .qml style and the exact same data render the callouts correctly when loaded manually in QGIS Desktop.
Environment:

  *   QGIS Desktop version (works correctly): 3.28.0, Windows
  *   QGIS server/headless version (fails): 3.22 (Ubuntu 22.04 apt package, qgis + python3-qgis), running in a Docker container, driven via PyQGIS (QgsApplication headless, no GUI event loop)
  *   Data source: PostGIS, LineString geometry, EPSG:6677
  *   Output: PDF via QgsLayoutExporter (print layout export)

Label/callout configuration (rule-based labeling):

<placement priority="5" placementFlags="10" placement="6" dist="30"
           overlapHandling="AllowOverlapIfRequired" .../>
<rendering unplacedVisibility="1" obstacle="0" .../>
<callout type="simple">
  ... anchorPoint="point_on_exterior" labelAnchorPoint="point_on_exterior"
      minLength="0" offsetFromAnchor="0" offsetFromLabel="0" ...
</callout>


Symptom:

  *   The line geometry itself renders correctly in the output PDF.
  *   The callout (leader line + label box) is completely absent in the batch/server output ? not partially clipped, not overlapping with anything, just not drawn at all.
  *   No errors or warnings appear in the QGIS process log during style loading (layer.loadNamedStyle() returns success) or during layout export.
  *   Forcing unplacedVisibility="1" (always show, even if placement fails) made no difference.
  *   Changing anchorPoint from pole_of_inaccessibility to point_on_exterior made no difference.
  *   Ruled out: NULL/empty label field values (confirmed via logs), layer density/overlap competition (confirmed via an isolated manual test loading only the affected features), clipping at the map item's boundary edge.
  *   The same .qml, loaded onto the same features in QGIS Desktop 3.28.0, renders the callouts perfectly.

Question: Is there a known behavioral difference between QGIS 3.22 and 3.28 (or between interactive Desktop rendering and headless/server rendering via QgsLayoutExporter) regarding callout placement for line geometries? Or any known issue/limitation with calloutType="simple" specifically in non-interactive/headless rendering contexts?
Any pointers on where to look (label engine internals, GEOS version dependency, changelog entries between 3.22 and 3.28 related to labeling/callouts, missing processEvents() calls, etc.) would be greatly appreciated.
Thanks, Yoshimi



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

From gdt at lexort.com  Tue Aug  4 04:57:37 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 04 Aug 2026 07:57:37 -0400
Subject: [QGIS-Developer] Line feature callout labels not rendering in
 headless/server QGIS 3.22, but work fine in Desktop 3.28
In-Reply-To: <OSZP286MB14196731EE708EAF12BFC963BDD42@OSZP286MB1419.JPNP286.PROD.OUTLOOK.COM>
 (=?utf-8?B?IuWQieimiyDltJo=?= via QGIS-Developer"'s message of "Tue, 4 Aug
 2026 06:58:15 +0000")
References: <OSZP286MB14196731EE708EAF12BFC963BDD42@OSZP286MB1419.JPNP286.PROD.OUTLOOK.COM>
Message-ID: <rmifr0uf68e.fsf@s1.lexort.com>

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

> Question: Is there a known behavioral difference between QGIS 3.22 and
> 3.28 (or between interactive Desktop rendering and headless/server
> rendering via QgsLayoutExporter) regarding callout placement for line
> geometries? Or any known issue/limitation with calloutType="simple"
> specifically in non-interactive/headless rendering contexts?

You are asking a question about ancient history.  3.22 was released in
2021-10 and 3.28 in 2022-10.  The current LTR is 3.44 and the current
release is 4.2.  It would not be surprising if there were bugs in 3.22,
but I doubt anyone is paying attention or has any interest in thinking
about them.

> Any pointers on where to look (label engine internals, GEOS version
> dependency, changelog entries between 3.22 and 3.28 related to
> labeling/callouts, missing processEvents() calls, etc.) would be
> greatly appreciated.

My advice is don't look into that, and update both your headless
rendering and desktop to 3.44.  If you aren't willing to upgrade, it
seems like the obvious experiments are to try 3.28.0 on Ubuntu both
headless and desktop.



From lova at kartoza.com  Tue Aug  4 06:04:34 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Tue, 4 Aug 2026 16:04:34 +0300
Subject: [QGIS-Developer] How do I change the email associated with a
 plugin?
In-Reply-To: <CA+=cGJ=pP2AG0SWkVzQH38U9fE-eh1JR1CzNS0nbsBtf7J5g3A@mail.gmail.com>
References: <CA+=cGJ=pP2AG0SWkVzQH38U9fE-eh1JR1CzNS0nbsBtf7J5g3A@mail.gmail.com>
Message-ID: <CAMLC-sC5NyNZGXcsYH0iKPrastBNMQwKMFvtY1=oFAm2C+CBDg@mail.gmail.com>

Hi Ian,

You can update the email address associated with your plugin directly in
the plugin's Edit form on the QGIS Plugins website (
https://plugins.qgis.org/plugins/osgb-plugin/update/). It's also advised to
update the email address in the metadata.txt if you ever upload a new
version in the future.
I hope this helps,

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 Mon, 3 Aug 2026 at 17:52, Ian Turton via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> I have discovered that one of my plugins is associated with an old work
> address that no longer exists, how do I go about changing it?
>
> It's https://plugins.qgis.org/plugins/osgb-plugin/#plugin-details if that
> helps
>
> Cheers
>
> Ian
>
> --
> Ian Turton
> _______________________________________________
> 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/20260804/ef2c2fbb/attachment.htm>

From jjenkner at web.de  Sat Aug  8 22:08:17 2026
From: jjenkner at web.de (Johannes Jenkner)
Date: Sun, 9 Aug 2026 05:08:17 +0000
Subject: [QGIS-Developer] Plugin falsely blocked by Bandit Security Analysis
Message-ID: <trinity-2a99f111-73e0-4d32-854b-e561f2e995c3-1786252097825@trinity-msg-rest-webde-webde-live-64fdfc8ff4-zsc8s>

An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260809/80e02c76/attachment.htm>

From jef at norbit.de  Sun Aug  9 09:27:42 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Sun, 9 Aug 2026 18:27:42 +0200
Subject: [QGIS-Developer] Plugin falsely blocked by Bandit Security
 Analysis
In-Reply-To: <trinity-2a99f111-73e0-4d32-854b-e561f2e995c3-1786252097825@trinity-msg-rest-webde-webde-live-64fdfc8ff4-zsc8s>
References: <trinity-2a99f111-73e0-4d32-854b-e561f2e995c3-1786252097825@trinity-msg-rest-webde-webde-live-64fdfc8ff4-zsc8s>
Message-ID: <20260809162742.6tqzqtktoyml2x3i@norbit.de>

Hi Johannes,

On Sun, 09. Aug 2026 at 05:08:17 +0000, Johannes Jenkner via QGIS-Developer wrote:
> Is the there anything I can do to unblock the plugin version and
> simultaneously keep the random numbers as essential part of my plugin
> algorithm?

You can add "# nosec" to the "offending" lines (and you should also move
the replacement arguments outside of the tr call).

J?rgen

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

From axel.n.c.andersson at gmail.com  Wed Aug 12 09:25:39 2026
From: axel.n.c.andersson at gmail.com (=?UTF-8?Q?Axel_H=C3=B6rteborn?=)
Date: Wed, 12 Aug 2026 18:25:39 +0200
Subject: [QGIS-Developer] Obtaining permission to approve plugins
Message-ID: <CAJj=OArJEA+m=LqUD2b-e8F-T+i0TDCDd2byLv5M2u4vjONbog@mail.gmail.com>

Hi list,

With the new release of the plugin package site:
https://blog.qgis.org/2026/07/06/coming-soon-qgis-plugins-website-v4-0-0/
it says "Plugins auto-approval will be explicit (two steps) and only
available for users who have permission to approve plugins". Is there any
guidance how to become a user with permission?

Best regards
Dr. Axel H?rteborn
Maintainer of GeoDataFarm <https://plugins.qgis.org/plugins/geodatafarm/> since
2018
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260812/5483dd0c/attachment.htm>

From valentin.buira at gmail.com  Wed Aug 12 10:08:37 2026
From: valentin.buira at gmail.com (Valentin Buira)
Date: Wed, 12 Aug 2026 19:08:37 +0200
Subject: [QGIS-Developer] Call for vote on QEP 415 and QEP 418
Message-ID: <CANrSSZnc9TBEHKdZoBNe+932UCmEoOFL42acZFDr49uNbE42RQ@mail.gmail.com>

Hi devs

These QEPs have ended the discussion phase and have been selected to be
part of the QGIS 2026 grant program.

Both QEPs were accepted by the PSC (in the  mailing list and later on
blog.qgis.org).  But I would like a formal vote by core contributors so I
can start the development.

Please cast your vote on the following QEPs:
* QEP 415: Refactor the evaluation of processing model with a dependency
graph [1]
* QEP 418: Better versioning for ".model3" file format [2]

Thanks in advance for taking the time to vote. I would prefer to have an
explicit vote rather than consider a QEP implicitly accepted due to a lack
of voting, since this could set a precedent for future QEPs.

Best regards,
Valentin

[1] https://github.com/qgis/QGIS-Enhancement-Proposals/pull/372
[2] https://github.com/qgis/QGIS-Enhancement-Proposals/pull/375
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260812/bcc8fed0/attachment.htm>

From r.nijssen at terglobo.nl  Thu Aug 13 22:02:03 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Fri, 14 Aug 2026 07:02:03 +0200
Subject: [QGIS-Developer] Slow WCS processing and Clipping WCS by extent not
 working
Message-ID: <cd089ed3-cae2-4d8f-bc2b-850edcc8368d@terglobo.nl>

Dear developers,

Currently I'm working on a process that uses a WCS service containing 
elevation data. I need 800x800m pieces from the elevation raster.

My graphical model uses a Raster Calculator algorithm, with one of the 
(2) layers being the WCS layer from my project. This works but is very 
slow. It takes about 1 minute to process the 800x800m calculation.

If I download the raster using gdal_translate, it only takes 2 seconds 
or so. I cannot find out what the Raster Calculator is doing differently.

On top of that, I need to do calculations for the same area 3x, so every 
location takes up over 3 minutes, and my entire process with many 
locations over 6 hours.

So I had some ideas to speed this up, but so far they all have downsides 
and I'm not sure what is the best way to proceed:

1. Using the Raster Calculator with only one layer and storing the 
output for the next 3 calculations. Will still take 1 minute extra, but 
is more effective (and a bit lame).

2. Using the Clip Raster by Extent algorithm, which seems perfect for 
this. But it does not work for WCS, cause it parses the QGIS layer 
source string directly into gdal_translate but GDAL needs another string 
and throws an error. Looking at the Python source code, this has 
probably never worked for WCS.

   2a. Fixing the Clip Raster by Extent algorithm. Cause it is in 
Python, I can give it a try. But I already found out that the Clip 
Raster by Mask algorithm has the same issue. And maybe more raster 
algorithms do. So that should be solved in less redundant way, right?

   2b. Asking a core developer to rewrite this properly in c++. Maybe in 
a way that uses the QGIS network manager so the http-calls get shown in 
the debugging panel? No idea what this would cost but I think I can get 
this funded somehow.

3. Making my own Python WCS downloader algorithm in Python (I think I 
will need to do this anyway to deliver my project on time, but I prefer 
more long term solutions for all QGIS users.)

Any suggestions?

Kind regards,
Raymond




Some data


This is the GDAL command QGIS generates to clip the extent (2) and the 
error:

GDAL command:
gdal_translate -projwin 148100.0 412300.0 148900.0 411500.0 -of GTiff 
"cache=AlwaysNetwork&crs=EPSG:28992&format=GEOTIFF&identifier=dsm_05m&url=https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0" 
/tmp/processing_NXPMbm/6597707893384cf9b74c2603ab45909d/OUTPUT.tif
GDAL command output:
ERROR 4: 
cache=AlwaysNetwork&crs=EPSG:28992&format=GEOTIFF&identifier=dsm_05m&url=https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0: 
No such file or directory
Process returned error code 1




This is the working WCS, url generated by QGIS and copied from the 
debugging panel:

https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0?SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&FORMAT=GEOTIFF&COVERAGE=dsm_05m&BBOX=142327.30414899752940983,408519.58202700602123514,156029.62145483330823481,415020.39733971789246425&CRS=EPSG:28992&RESPONSE_CRS=EPSG:28992&WIDTH=704&HEIGHT=334


From r.nijssen at terglobo.nl  Thu Aug 13 23:29:40 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Fri, 14 Aug 2026 08:29:40 +0200
Subject: [QGIS-Developer] Slow WCS processing and Clipping WCS by extent
 not working
In-Reply-To: <cd089ed3-cae2-4d8f-bc2b-850edcc8368d@terglobo.nl>
References: <cd089ed3-cae2-4d8f-bc2b-850edcc8368d@terglobo.nl>
Message-ID: <a7dbb71f-14c6-46b7-9c68-6e83fc051ef6@terglobo.nl>

Created an issue too:
https://github.com/qgis/QGIS/issues/67061


On 8/14/26 07:02, Raymond Nijssen via QGIS-Developer wrote:
> Dear developers,
> 
> Currently I'm working on a process that uses a WCS service containing 
> elevation data. I need 800x800m pieces from the elevation raster.
> 
> My graphical model uses a Raster Calculator algorithm, with one of the 
> (2) layers being the WCS layer from my project. This works but is very 
> slow. It takes about 1 minute to process the 800x800m calculation.
> 
> If I download the raster using gdal_translate, it only takes 2 seconds 
> or so. I cannot find out what the Raster Calculator is doing differently.
> 
> On top of that, I need to do calculations for the same area 3x, so every 
> location takes up over 3 minutes, and my entire process with many 
> locations over 6 hours.
> 
> So I had some ideas to speed this up, but so far they all have downsides 
> and I'm not sure what is the best way to proceed:
> 
> 1. Using the Raster Calculator with only one layer and storing the 
> output for the next 3 calculations. Will still take 1 minute extra, but 
> is more effective (and a bit lame).
> 
> 2. Using the Clip Raster by Extent algorithm, which seems perfect for 
> this. But it does not work for WCS, cause it parses the QGIS layer 
> source string directly into gdal_translate but GDAL needs another string 
> and throws an error. Looking at the Python source code, this has 
> probably never worked for WCS.
> 
>  ? 2a. Fixing the Clip Raster by Extent algorithm. Cause it is in 
> Python, I can give it a try. But I already found out that the Clip 
> Raster by Mask algorithm has the same issue. And maybe more raster 
> algorithms do. So that should be solved in less redundant way, right?
> 
>  ? 2b. Asking a core developer to rewrite this properly in c++. Maybe in 
> a way that uses the QGIS network manager so the http-calls get shown in 
> the debugging panel? No idea what this would cost but I think I can get 
> this funded somehow.
> 
> 3. Making my own Python WCS downloader algorithm in Python (I think I 
> will need to do this anyway to deliver my project on time, but I prefer 
> more long term solutions for all QGIS users.)
> 
> Any suggestions?
> 
> Kind regards,
> Raymond
> 
> 
> 
> 
> Some data
> 
> 
> This is the GDAL command QGIS generates to clip the extent (2) and the 
> error:
> 
> GDAL command:
> gdal_translate -projwin 148100.0 412300.0 148900.0 411500.0 -of GTiff 
> "cache=AlwaysNetwork&crs=EPSG:28992&format=GEOTIFF&identifier=dsm_05m&url=https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0" /tmp/processing_NXPMbm/6597707893384cf9b74c2603ab45909d/OUTPUT.tif
> GDAL command output:
> ERROR 4: 
> cache=AlwaysNetwork&crs=EPSG:28992&format=GEOTIFF&identifier=dsm_05m&url=https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0: No such file or directory
> Process returned error code 1
> 
> 
> 
> 
> This is the working WCS, url generated by QGIS and copied from the 
> debugging panel:
> 
> https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0? 
> SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&FORMAT=GEOTIFF&COVERAGE=dsm_05m&BBOX=142327.30414899752940983,408519.58202700602123514,156029.62145483330823481,415020.39733971789246425&CRS=EPSG:28992&RESPONSE_CRS=EPSG:28992&WIDTH=704&HEIGHT=334
> 
> _______________________________________________
> 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 Aug 19 00:07:11 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 19 Aug 2026 10:07:11 +0300
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
Message-ID: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>

Hello everyone,

Following the plugin rating abuse issue reported at
https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if
someone could help or share some thoughts about it.

We have released some fixes to enforce throttles (
https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject forged
cookies and add a cap votes per address (
https://github.com/qgis/QGIS-Plugins-Website/pull/423). However, it is not
fully working because every IP recorded against a vote is a Cloudflare edge
IP, not a real user IP. I checked 100 recent votes against Cloudflare's
published ranges: 100 out of 100 match. So the per-IP cap is counting
Cloudflare's proxy pool, which rotates per request. So, storing real client
IPs would probably require some discussions regarding GDPR and retention
angle.

The reporter also asks us to (a) purge the fake votes and recompute the
affected plugin scores, and (b) require a logged-in account to vote. Both
are policy calls, not just code. And noting that the latter will probably
break how the QGIS Desktop plugin manager submits ratings anonymously over
XML-RPC.

Thanks so much in advance for any input.

Lova Andriarimalala


*QGIS Full Stack Developer   *
*T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
kartoza.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260819/82c268ff/attachment.htm>

From denis.rouzaud at gmail.com  Wed Aug 19 00:16:36 2026
From: denis.rouzaud at gmail.com (Denis Rouzaud)
Date: Wed, 19 Aug 2026 09:16:36 +0200
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
Message-ID: <CAMtsY+Z2rwsFzpAUHPNnyk+7w30z3+mays3rgrMtDi8C8MQdNg@mail.gmail.com>

Hi,

We switch to osgeo logged-in users only and force to have a (constructive)
comment?
Otherwise votes are meaningless and useless I'd say.

Cheers,
Denis

Le mer. 19 ao?t 2026 ? 09:07, Lova Andriarimalala via QGIS-Developer <
qgis-developer at lists.osgeo.org> a ?crit :

> Hello everyone,
>
> Following the plugin rating abuse issue reported at
> https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
> https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if
> someone could help or share some thoughts about it.
>
> We have released some fixes to enforce throttles (
> https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject forged
> cookies and add a cap votes per address (
> https://github.com/qgis/QGIS-Plugins-Website/pull/423). However, it is
> not fully working because every IP recorded against a vote is a Cloudflare
> edge IP, not a real user IP. I checked 100 recent votes against
> Cloudflare's published ranges: 100 out of 100 match. So the per-IP cap is
> counting Cloudflare's proxy pool, which rotates per request. So, storing
> real client IPs would probably require some discussions regarding GDPR and
> retention angle.
>
> The reporter also asks us to (a) purge the fake votes and recompute the
> affected plugin scores, and (b) require a logged-in account to vote. Both
> are policy calls, not just code. And noting that the latter will probably
> break how the QGIS Desktop plugin manager submits ratings anonymously over
> XML-RPC.
>
> Thanks so much in advance for any input.
>
> Lova Andriarimalala
>
>
> *QGIS Full Stack Developer   *
> *T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
> kartoza.com
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260819/404f27c1/attachment.htm>

From regis.haubourg at gmail.com  Wed Aug 19 00:42:57 2026
From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=)
Date: Wed, 19 Aug 2026 09:42:57 +0200
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMtsY+Z2rwsFzpAUHPNnyk+7w30z3+mays3rgrMtDi8C8MQdNg@mail.gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <CAMtsY+Z2rwsFzpAUHPNnyk+7w30z3+mays3rgrMtDi8C8MQdNg@mail.gmail.com>
Message-ID: <4d70c538-b1b5-4c82-8172-9e87cd3fbcf9@gmail.com>

Hi, and thanks for the very clear situation overview Lova!

Firefox? requires to log to be able to rate.? I concur with Denis. 
Anonymous voting is now obsolete to me, as the ecosystem has grown and 
many companies rely on this ecosystem.

I would have no problem with a communication campaign announcing that 
rating is no more authorized for anonymous accounts, and should only be 
done from the website, as I don't think we want to add a sign in feature 
from QGIS desktop itself. This feature would open the gate to a bunch of 
security / privacy /compliance issues that I don't thing we want to add 
complexity right now, as this is one strength of QGIS, to have no link 
with our public infrastructure and no personal data collection.

So, I guess that would mean that we remove the rating feature from QGIS 
desktop and that the voting button only opens the web app at the right 
place.


Best regards

R?gis



On 19/08/2026 09:16, Denis Rouzaud via QGIS-Developer wrote:

> Hi,
>
> We switch to osgeo logged-in users only and force to have a 
> (constructive) comment?
> Otherwise votes are meaningless and useless I'd say.
>
> Cheers,
> Denis
>
> Le?mer. 19 ao?t 2026 ??09:07, Lova Andriarimalala via QGIS-Developer 
> <qgis-developer at lists.osgeo.org> a ?crit?:
>
>     Hello everyone,
>
>     Following the plugin rating abuse issue reported at
>     https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
>     https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder
>     if someone could help or share some thoughts about it.
>
>     We have released some fixes to enforce throttles
>     (https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject
>     forged cookies and add a cap votes per address
>     (https://github.com/qgis/QGIS-Plugins-Website/pull/423). However,
>     it is not fully working because every IP recorded against a vote
>     is a Cloudflare edge IP, not a real user IP. I checked 100 recent
>     votes against Cloudflare's published ranges: 100 out of 100 match.
>     So the per-IP cap is counting Cloudflare's proxy pool, which
>     rotates per request. So, storing real client IPs would probably
>     require some discussions regarding GDPR and retention angle.
>
>     The reporter also asks us to (a) purge the fake votes and
>     recompute the affected plugin scores, and (b) require a logged-in
>     account to vote. Both are policy calls, not just code. And noting
>     that the latter will probably break how the QGIS Desktop plugin
>     manager submits ratings anonymously over XML-RPC.
>
>     Thanks so much in advance for any input.
>
>     Lova Andriarimalala
>     *QGIS Full Stack Developer
>
>     *
>     *T *:?+27(0) 87 809 2702 *E *:**lova at kartoza.com *W*?: kartoza.com
>     <http://kartoza.com>
>
>     _______________________________________________
>     QGIS-Developer mailing list
>     QGIS-Developer at lists.osgeo.org
>     List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>     Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260819/92d1cce6/attachment-0001.htm>

From lova at kartoza.com  Wed Aug 19 02:56:31 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 19 Aug 2026 12:56:31 +0300
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <4d70c538-b1b5-4c82-8172-9e87cd3fbcf9@gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <CAMtsY+Z2rwsFzpAUHPNnyk+7w30z3+mays3rgrMtDi8C8MQdNg@mail.gmail.com>
 <4d70c538-b1b5-4c82-8172-9e87cd3fbcf9@gmail.com>
Message-ID: <CAMLC-sADG17-X65mbiNe0X4-gPSzD+VUWJaTV4p0GVeGrXbMww@mail.gmail.com>

Hi R?gis and Denis

Thank you for the input. I agree that shifting to authenticated ratings
with a proper comment system makes the most sense given the current
situation.

With that change, I wonder if it wouldn't be simpler to start with clean
rating records for all plugins rather than migrating those who rated with
an account from the current obsolete ones. This will prevent recalculating
all ratings based on the new rule or considering removing any rating based
on abuse (which is difficult to determine) if we even choose to keep the
obsolete records. With clean records, we could easily add the
mandatory constructive comments feature as Denis suggested.

On the QGIS Desktop side, this change will most likely require a QEP first
because the existing feature in current and previous versions will break
and I am not familiar with how to handle that.

I can also prepare a detailed plan for the changes and announcement
accordingly.

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, 19 Aug 2026 at 10:43, R?gis Haubourg <regis.haubourg at gmail.com>
wrote:

> Hi, and thanks for the very clear situation overview Lova!
>
> Firefox  requires to log to be able to rate.  I concur with Denis.
> Anonymous voting is now obsolete to me, as the ecosystem has grown and many
> companies rely on this ecosystem.
>
> I would have no problem with a communication campaign announcing that
> rating is no more authorized for anonymous accounts, and should only be
> done from the website, as I don't think we want to add a sign in feature
> from QGIS desktop itself. This feature would open the gate to a bunch of
> security / privacy /compliance issues that I don't thing we want to add
> complexity right now, as this is one strength of QGIS, to have no link with
> our public infrastructure and no personal data collection.
>
> So, I guess that would mean that we remove the rating feature from QGIS
> desktop and that the voting button only opens the web app at the right
> place.
>
>
> Best regards
>
> R?gis
>
>
>
> On 19/08/2026 09:16, Denis Rouzaud via QGIS-Developer wrote:
>
> Hi,
>
> We switch to osgeo logged-in users only and force to have a (constructive)
> comment?
> Otherwise votes are meaningless and useless I'd say.
>
> Cheers,
> Denis
>
> Le mer. 19 ao?t 2026 ? 09:07, Lova Andriarimalala via QGIS-Developer <
> qgis-developer at lists.osgeo.org> a ?crit :
>
>> Hello everyone,
>>
>> Following the plugin rating abuse issue reported at
>> https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
>> https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if
>> someone could help or share some thoughts about it.
>>
>> We have released some fixes to enforce throttles (
>> https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject forged
>> cookies and add a cap votes per address (
>> https://github.com/qgis/QGIS-Plugins-Website/pull/423). However, it is
>> not fully working because every IP recorded against a vote is a Cloudflare
>> edge IP, not a real user IP. I checked 100 recent votes against
>> Cloudflare's published ranges: 100 out of 100 match. So the per-IP cap is
>> counting Cloudflare's proxy pool, which rotates per request. So, storing
>> real client IPs would probably require some discussions regarding GDPR and
>> retention angle.
>>
>> The reporter also asks us to (a) purge the fake votes and recompute the
>> affected plugin scores, and (b) require a logged-in account to vote. Both
>> are policy calls, not just code. And noting that the latter will probably
>> break how the QGIS Desktop plugin manager submits ratings anonymously over
>> XML-RPC.
>>
>> Thanks so much in advance for any input.
>>
>> Lova Andriarimalala
>>
>>
>> *QGIS Full Stack Developer    *
>> *T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
>> kartoza.com
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> _______________________________________________
> QGIS-Developer mailing listQGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260819/e6ce23b8/attachment.htm>

From nyall.dawson at gmail.com  Wed Aug 19 03:12:33 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Wed, 19 Aug 2026 20:12:33 +1000
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMLC-sADG17-X65mbiNe0X4-gPSzD+VUWJaTV4p0GVeGrXbMww@mail.gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <CAMtsY+Z2rwsFzpAUHPNnyk+7w30z3+mays3rgrMtDi8C8MQdNg@mail.gmail.com>
 <4d70c538-b1b5-4c82-8172-9e87cd3fbcf9@gmail.com>
 <CAMLC-sADG17-X65mbiNe0X4-gPSzD+VUWJaTV4p0GVeGrXbMww@mail.gmail.com>
Message-ID: <CAB28AsjzNq7e1+JQqM-oF6am+GBh+vzYSCkUbK-LEp2_+nDg9w@mail.gmail.com>

On Wed, 19 Aug 2026 at 19:56, Lova Andriarimalala via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hi R?gis and Denis
>
> Thank you for the input. I agree that shifting to authenticated ratings with a proper comment system makes the most sense given the current situation.
>
> With that change, I wonder if it wouldn't be simpler to start with clean rating records for all plugins rather than migrating those who rated with an account from the current obsolete ones. This will prevent recalculating all ratings based on the new rule or considering removing any rating based on abuse (which is difficult to determine) if we even choose to keep the obsolete records. With clean records, we could easily add the mandatory constructive comments feature as Denis suggested.

I'd be +1 to that. For me, a bad rating with no reason gives the
plugin authors no help to improve, and becomes a permanent black mark
against a plugin that can never be removed. It'd be great if requiring
logged in users for ratings would also allow users to change an
existing rating (eg when the author responsively fixes a bug).

>
> On the QGIS Desktop side, this change will most likely require a QEP first because the existing feature in current and previous versions will break and I am not familiar with how to handle that.

I think that feature can be safely removed without a QEP. It's been
basically broken in the qt6 builds anyway (it's fallen back to a weird
slider widget which doesn't make sense). And it's not like removing it
will break any critical workflows for users.

Nyall


>
> I can also prepare a detailed plan for the changes and announcement accordingly.
>
> 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, 19 Aug 2026 at 10:43, R?gis Haubourg <regis.haubourg at gmail.com> wrote:
>>
>> Hi, and thanks for the very clear situation overview Lova!
>>
>> Firefox  requires to log to be able to rate.  I concur with Denis. Anonymous voting is now obsolete to me, as the ecosystem has grown and many companies rely on this ecosystem.
>>
>> I would have no problem with a communication campaign announcing that rating is no more authorized for anonymous accounts, and should only be done from the website, as I don't think we want to add a sign in feature from QGIS desktop itself. This feature would open the gate to a bunch of security / privacy /compliance issues that I don't thing we want to add complexity right now, as this is one strength of QGIS, to have no link with our public infrastructure and no personal data collection.
>>
>> So, I guess that would mean that we remove the rating feature from QGIS desktop and that the voting button only opens the web app at the right place.
>>
>>
>> Best regards
>>
>> R?gis
>>
>>
>>
>> On 19/08/2026 09:16, Denis Rouzaud via QGIS-Developer wrote:
>>
>> Hi,
>>
>> We switch to osgeo logged-in users only and force to have a (constructive) comment?
>> Otherwise votes are meaningless and useless I'd say.
>>
>> Cheers,
>> Denis
>>
>> Le mer. 19 ao?t 2026 ? 09:07, Lova Andriarimalala via QGIS-Developer <qgis-developer at lists.osgeo.org> a ?crit :
>>>
>>> Hello everyone,
>>>
>>> Following the plugin rating abuse issue reported at  https://github.com/qgis/QGIS-Plugins-Website/issues/416 and https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if someone could help or share some thoughts about it.
>>>
>>> We have released some fixes to enforce throttles (https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject forged cookies and add a cap votes per address (https://github.com/qgis/QGIS-Plugins-Website/pull/423). However, it is not fully working because every IP recorded against a vote is a Cloudflare edge IP, not a real user IP. I checked 100 recent votes against Cloudflare's published ranges: 100 out of 100 match. So the per-IP cap is counting Cloudflare's proxy pool, which rotates per request. So, storing real client IPs would probably require some discussions regarding GDPR and retention angle.
>>>
>>> The reporter also asks us to (a) purge the fake votes and recompute the affected plugin scores, and (b) require a logged-in account to vote. Both are policy calls, not just code. And noting that the latter will probably break how the QGIS Desktop plugin manager submits ratings anonymously over XML-RPC.
>>>
>>> Thanks so much in advance for any input.
>>>
>>> Lova Andriarimalala
>>> QGIS Full Stack Developer
>>>
>>> T : +27(0) 87 809 2702          E : lova at kartoza.com          W : kartoza.com
>>>
>>> _______________________________________________
>>> QGIS-Developer mailing list
>>> QGIS-Developer at lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> _______________________________________________
> 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 lnicola at dend.ro  Wed Aug 19 03:18:00 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Wed, 19 Aug 2026 13:18:00 +0300
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
Message-ID: <bf95cb37-e532-4f76-8598-eadb182b4333@app.fastmail.com>

Hi Lova,

Requiring users to log in seems fine to me, but you can use the X-Forwarded-For or CF-Connecting-IP headers to find out the real IP of the client.

Laurentiu

On Wed, Aug 19, 2026, at 10:07, Lova Andriarimalala via QGIS-Developer wrote:
> Hello everyone,
> 
> Following the plugin rating abuse issue reported at  https://github.com/qgis/QGIS-Plugins-Website/issues/416 and https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if someone could help or share some thoughts about it.
> 
> We have released some fixes to enforce throttles (https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject forged cookies and add a cap votes per address (https://github.com/qgis/QGIS-Plugins-Website/pull/423). However, it is not fully working because every IP recorded against a vote is a Cloudflare edge IP, not a real user IP. I checked 100 recent votes against Cloudflare's published ranges: 100 out of 100 match. So the per-IP cap is counting Cloudflare's proxy pool, which rotates per request. So, storing real client IPs would probably require some discussions regarding GDPR and retention angle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260819/06e9d514/attachment-0001.htm>

From gdt at lexort.com  Wed Aug 19 03:35:39 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 19 Aug 2026 06:35:39 -0400
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 (Lova Andriarimalala via's message of "Wed, 19 Aug 2026 10:07:11
 +0300")
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
Message-ID: <rmijypmieis.fsf@s1.lexort.com>

Lova Andriarimalala via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> Following the plugin rating abuse issue reported at
> https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
> https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if
> someone could help or share some thoughts about it.

Stepping back, why does the QGIS project feel the need to support a
rating system for third-party code at all?

Why not just remove all rating data, and remove the code in qgis to
fetch ratings and vote?


From r.nijssen at terglobo.nl  Wed Aug 19 05:18:47 2026
From: r.nijssen at terglobo.nl (Raymond Nijssen)
Date: Wed, 19 Aug 2026 14:18:47 +0200
Subject: [QGIS-Developer] Slow WCS processing and Clipping WCS by extent
 not working
In-Reply-To: <a7dbb71f-14c6-46b7-9c68-6e83fc051ef6@terglobo.nl>
References: <cd089ed3-cae2-4d8f-bc2b-850edcc8368d@terglobo.nl>
 <a7dbb71f-14c6-46b7-9c68-6e83fc051ef6@terglobo.nl>
Message-ID: <d00bd38f-eaa8-4ee0-bc09-b16db846c85e@terglobo.nl>

Just uploaded a processing script for downloading WCS, as a work around 
for this problem:

https://hub.qgis.org/scripts/17/

But hopefully it can be fixed in QGIS somehow. Any ideas anyone?

Raymond


On 8/14/26 08:29, Raymond Nijssen via QGIS-Developer wrote:
> Created an issue too:
> https://github.com/qgis/QGIS/issues/67061
> 
> 
> On 8/14/26 07:02, Raymond Nijssen via QGIS-Developer wrote:
>> Dear developers,
>>
>> Currently I'm working on a process that uses a WCS service containing 
>> elevation data. I need 800x800m pieces from the elevation raster.
>>
>> My graphical model uses a Raster Calculator algorithm, with one of the 
>> (2) layers being the WCS layer from my project. This works but is very 
>> slow. It takes about 1 minute to process the 800x800m calculation.
>>
>> If I download the raster using gdal_translate, it only takes 2 seconds 
>> or so. I cannot find out what the Raster Calculator is doing differently.
>>
>> On top of that, I need to do calculations for the same area 3x, so 
>> every location takes up over 3 minutes, and my entire process with 
>> many locations over 6 hours.
>>
>> So I had some ideas to speed this up, but so far they all have 
>> downsides and I'm not sure what is the best way to proceed:
>>
>> 1. Using the Raster Calculator with only one layer and storing the 
>> output for the next 3 calculations. Will still take 1 minute extra, 
>> but is more effective (and a bit lame).
>>
>> 2. Using the Clip Raster by Extent algorithm, which seems perfect for 
>> this. But it does not work for WCS, cause it parses the QGIS layer 
>> source string directly into gdal_translate but GDAL needs another 
>> string and throws an error. Looking at the Python source code, this 
>> has probably never worked for WCS.
>>
>> ?? 2a. Fixing the Clip Raster by Extent algorithm. Cause it is in 
>> Python, I can give it a try. But I already found out that the Clip 
>> Raster by Mask algorithm has the same issue. And maybe more raster 
>> algorithms do. So that should be solved in less redundant way, right?
>>
>> ?? 2b. Asking a core developer to rewrite this properly in c++. Maybe 
>> in a way that uses the QGIS network manager so the http-calls get 
>> shown in the debugging panel? No idea what this would cost but I think 
>> I can get this funded somehow.
>>
>> 3. Making my own Python WCS downloader algorithm in Python (I think I 
>> will need to do this anyway to deliver my project on time, but I 
>> prefer more long term solutions for all QGIS users.)
>>
>> Any suggestions?
>>
>> Kind regards,
>> Raymond
>>
>>
>>
>>
>> Some data
>>
>>
>> This is the GDAL command QGIS generates to clip the extent (2) and the 
>> error:
>>
>> GDAL command:
>> gdal_translate -projwin 148100.0 412300.0 148900.0 411500.0 -of GTiff 
>> "cache=AlwaysNetwork&crs=EPSG:28992&format=GEOTIFF&identifier=dsm_05m&url=https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0" /tmp/processing_NXPMbm/6597707893384cf9b74c2603ab45909d/OUTPUT.tif
>> GDAL command output:
>> ERROR 4: 
>> cache=AlwaysNetwork&crs=EPSG:28992&format=GEOTIFF&identifier=dsm_05m&url=https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0: No such file or directory
>> Process returned error code 1
>>
>>
>>
>>
>> This is the working WCS, url generated by QGIS and copied from the 
>> debugging panel:
>>
>> https://service.pdok.nl/rws/actueel-hoogtebestand-nederland/wcs/v1_0? 
>> SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&FORMAT=GEOTIFF&COVERAGE=dsm_05m&BBOX=142327.30414899752940983,408519.58202700602123514,156029.62145483330823481,415020.39733971789246425&CRS=EPSG:28992&RESPONSE_CRS=EPSG:28992&WIDTH=704&HEIGHT=334
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


From lova at kartoza.com  Wed Aug 19 05:27:07 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 19 Aug 2026 15:27:07 +0300
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAB28AsjzNq7e1+JQqM-oF6am+GBh+vzYSCkUbK-LEp2_+nDg9w@mail.gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <CAMtsY+Z2rwsFzpAUHPNnyk+7w30z3+mays3rgrMtDi8C8MQdNg@mail.gmail.com>
 <4d70c538-b1b5-4c82-8172-9e87cd3fbcf9@gmail.com>
 <CAMLC-sADG17-X65mbiNe0X4-gPSzD+VUWJaTV4p0GVeGrXbMww@mail.gmail.com>
 <CAB28AsjzNq7e1+JQqM-oF6am+GBh+vzYSCkUbK-LEp2_+nDg9w@mail.gmail.com>
Message-ID: <CAMLC-sBJ5Vsb=Bs6=SUA228Zau+VZg9dguU070FWgN12Vxo-9g@mail.gmail.com>

Hi Nyall,
> I'd be +1 to that. For me, a bad rating with no reason gives the
plugin authors no help to improve, and becomes a permanent black mark
against a plugin that can never be removed. It'd be great if requiring
logged in users for ratings would also allow users to change an
existing rating (eg when the author responsively fixes a bug).

Thanks for the feedback and the suggestion. I will take note of that.

> I think that feature can be safely removed without a QEP. It's been
basically broken in the qt6 builds anyway (it's fallen back to a weird
slider widget which doesn't make sense). And it's not like removing it
will break any critical workflows for users.

Removing it would then be more like a simple change. Thanks for letting me
know.

Best regards,

Lova Andriarimalala


*QGIS Full Stack Developer   *
*T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
kartoza.com



On Wed, 19 Aug 2026 at 13:12, Nyall Dawson <nyall.dawson at gmail.com> wrote:

> On Wed, 19 Aug 2026 at 19:56, Lova Andriarimalala via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
> >
> > Hi R?gis and Denis
> >
> > Thank you for the input. I agree that shifting to authenticated ratings
> with a proper comment system makes the most sense given the current
> situation.
> >
> > With that change, I wonder if it wouldn't be simpler to start with clean
> rating records for all plugins rather than migrating those who rated with
> an account from the current obsolete ones. This will prevent recalculating
> all ratings based on the new rule or considering removing any rating based
> on abuse (which is difficult to determine) if we even choose to keep the
> obsolete records. With clean records, we could easily add the mandatory
> constructive comments feature as Denis suggested.
>
> I'd be +1 to that. For me, a bad rating with no reason gives the
> plugin authors no help to improve, and becomes a permanent black mark
> against a plugin that can never be removed. It'd be great if requiring
> logged in users for ratings would also allow users to change an
> existing rating (eg when the author responsively fixes a bug).
>
> >
> > On the QGIS Desktop side, this change will most likely require a QEP
> first because the existing feature in current and previous versions will
> break and I am not familiar with how to handle that.
>
> I think that feature can be safely removed without a QEP. It's been
> basically broken in the qt6 builds anyway (it's fallen back to a weird
> slider widget which doesn't make sense). And it's not like removing it
> will break any critical workflows for users.
>
> Nyall
>
>
> >
> > I can also prepare a detailed plan for the changes and announcement
> accordingly.
> >
> > 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, 19 Aug 2026 at 10:43, R?gis Haubourg <regis.haubourg at gmail.com>
> wrote:
> >>
> >> Hi, and thanks for the very clear situation overview Lova!
> >>
> >> Firefox  requires to log to be able to rate.  I concur with Denis.
> Anonymous voting is now obsolete to me, as the ecosystem has grown and many
> companies rely on this ecosystem.
> >>
> >> I would have no problem with a communication campaign announcing that
> rating is no more authorized for anonymous accounts, and should only be
> done from the website, as I don't think we want to add a sign in feature
> from QGIS desktop itself. This feature would open the gate to a bunch of
> security / privacy /compliance issues that I don't thing we want to add
> complexity right now, as this is one strength of QGIS, to have no link with
> our public infrastructure and no personal data collection.
> >>
> >> So, I guess that would mean that we remove the rating feature from QGIS
> desktop and that the voting button only opens the web app at the right
> place.
> >>
> >>
> >> Best regards
> >>
> >> R?gis
> >>
> >>
> >>
> >> On 19/08/2026 09:16, Denis Rouzaud via QGIS-Developer wrote:
> >>
> >> Hi,
> >>
> >> We switch to osgeo logged-in users only and force to have a
> (constructive) comment?
> >> Otherwise votes are meaningless and useless I'd say.
> >>
> >> Cheers,
> >> Denis
> >>
> >> Le mer. 19 ao?t 2026 ? 09:07, Lova Andriarimalala via QGIS-Developer <
> qgis-developer at lists.osgeo.org> a ?crit :
> >>>
> >>> Hello everyone,
> >>>
> >>> Following the plugin rating abuse issue reported at
> https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
> https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if
> someone could help or share some thoughts about it.
> >>>
> >>> We have released some fixes to enforce throttles (
> https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject forged
> cookies and add a cap votes per address (
> https://github.com/qgis/QGIS-Plugins-Website/pull/423). However, it is
> not fully working because every IP recorded against a vote is a Cloudflare
> edge IP, not a real user IP. I checked 100 recent votes against
> Cloudflare's published ranges: 100 out of 100 match. So the per-IP cap is
> counting Cloudflare's proxy pool, which rotates per request. So, storing
> real client IPs would probably require some discussions regarding GDPR and
> retention angle.
> >>>
> >>> The reporter also asks us to (a) purge the fake votes and recompute
> the affected plugin scores, and (b) require a logged-in account to vote.
> Both are policy calls, not just code. And noting that the latter will
> probably break how the QGIS Desktop plugin manager submits ratings
> anonymously over XML-RPC.
> >>>
> >>> Thanks so much in advance for any input.
> >>>
> >>> Lova Andriarimalala
> >>> QGIS Full Stack Developer
> >>>
> >>> T : +27(0) 87 809 2702          E : lova at kartoza.com          W :
> kartoza.com
> >>>
> >>> _______________________________________________
> >>> QGIS-Developer mailing list
> >>> QGIS-Developer at lists.osgeo.org
> >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >>
> >> _______________________________________________
> >> QGIS-Developer mailing list
> >> QGIS-Developer at lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> > _______________________________________________
> > 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/20260819/06f98c29/attachment-0001.htm>

From lova at kartoza.com  Wed Aug 19 05:58:01 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Wed, 19 Aug 2026 15:58:01 +0300
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <rmijypmieis.fsf@s1.lexort.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <rmijypmieis.fsf@s1.lexort.com>
Message-ID: <CAMLC-sBK-F5geby3iaZ0Ct__Tz=COi3JzSiGU-Fb9z2vMrFfZw@mail.gmail.com>

Hi Lauren?iu and Greg,

> but you can use the X-Forwarded-For or CF-Connecting-IP headers to find
out the real IP of the client.

That's correct, and I guess it's the right way.
But for the rating specifically, we need to store them in the DB if we want
to correctly manage the rating abuse which requires a another discussion
and as mentioned by Regis earlier: "This feature would open the gate to a
bunch of security / privacy /compliance issues that I don't thing we want
to add complexity right now, as this is one strength of QGIS, to have no
link with our public infrastructure and no personal data collection. "

> Stepping back, why does the QGIS project feel the need to support a
rating system for third-party code at all?

Unfortunately, I don't have the direct answer to that. I was involved in
implementing download statistics by country for each plugin and I think
this is similar. Basically, they provide insights/metrics for plugin
developers and maybe for users as well.

> Why not just remove all rating data, and remove the code in qgis to
fetch ratings and vote?

Technically, that aligns with part of my suggestion earlier. However, this
should include (re)-implementing a clean proper rating system that requires
users to be authenticated and leave a comment, which would help plugin
developers improve their plugins as Denis and Nyall mentioned.

Best regards,


Lova Andriarimalala


*QGIS Full Stack Developer   *
*T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
kartoza.com





On Wed, 19 Aug 2026 at 13:35, Greg Troxel via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Lova Andriarimalala via QGIS-Developer <qgis-developer at lists.osgeo.org>
> writes:
>
> > Following the plugin rating abuse issue reported at
> > https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
> > https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if
> > someone could help or share some thoughts about it.
>
> Stepping back, why does the QGIS project feel the need to support a
> rating system for third-party code at all?
>
> Why not just remove all rating data, and remove the code in qgis to
> fetch ratings and vote?
>
> _______________________________________________
> 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/20260819/e7ccdcaf/attachment.htm>

From gdt at lexort.com  Wed Aug 19 06:28:10 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 19 Aug 2026 09:28:10 -0400
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMLC-sBK-F5geby3iaZ0Ct__Tz=COi3JzSiGU-Fb9z2vMrFfZw@mail.gmail.com>
 (Lova Andriarimalala's message of "Wed, 19 Aug 2026 15:58:01 +0300")
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <rmijypmieis.fsf@s1.lexort.com>
 <CAMLC-sBK-F5geby3iaZ0Ct__Tz=COi3JzSiGU-Fb9z2vMrFfZw@mail.gmail.com>
Message-ID: <rmia4qigryt.fsf@s1.lexort.com>

Lova Andriarimalala <lova at kartoza.com> writes:

> Hi Lauren?iu and Greg,
>
>> Stepping back, why does the QGIS project feel the need to support a
>> rating system for third-party code at all?
>
> Unfortunately, I don't have the direct answer to that. I was involved in
> implementing download statistics by country for each plugin and I think
> this is similar. Basically, they provide insights/metrics for plugin
> developers and maybe for users as well.

Makes sense about statistics.  That has the same faking problem.   I do
realize that there is some insight.

But the real question is whether the insight gained is worth the cost of
implementing ratings in a way which
  - has adequate protection from fake ratings
  - complies with GDPR and other rules
  - complies with Free Software community ethics

There's a lot of cost to doing it right.

>> Why not just remove all rating data, and remove the code in qgis to
>> fetch ratings and vote?
>
> Technically, that aligns with part of my suggestion earlier. However, this
> should include (re)-implementing a clean proper rating system that requires
> users to be authenticated and leave a comment, which would help plugin
> developers improve their plugins as Denis and Nyall mentioned.

Why do you it "should include reimplementing..."?  That's a decision
that the answer to the previous question is that ratings are so
important that any cost to properly implement is justified.  I see no
basis to decide that.

IMHO plugins should have a public forge or at least an issue tracker.
(Speaking of Free Software norms, that shouldn't be on github!)  People
that want to make suggestions to plugin authors can use that.  I have
filed issues to plugins, with varying effects.


Another aspect of this is that popular voting, even if we somehow ensure
that each voter is a community member, that all votes are cast by
humans, and that no human community member can vote with two or more
identities, is that opinions need to be considered in light of the
experience/reputation of the voter.


I see this voting system as sufficiently problematic that I don't find
it of much value.

From denis.rouzaud at gmail.com  Thu Aug 20 02:22:04 2026
From: denis.rouzaud at gmail.com (Denis Rouzaud)
Date: Thu, 20 Aug 2026 11:22:04 +0200
Subject: [QGIS-Developer] Next 4.x LTR
Message-ID: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>

Dear PSC, dear Devs,

On the release schedule, the next LTR still targets 4.2.4 in October.

Two things to consider from
https://github.com/qgis/QGIS-Enhancement-Proposals/pull/377:
- HTML print layout support is targeted for 4.4 (which is/seems to be a big
blocker, requiring a backport)
- The stability of 4.2 is questioned

I also feel that we could wait for 4.4 to do a LTR but the timing is
getting critical. "Enterprise" users are wondering what is the current
status, and we don't have a clear answer.

I believe it would be the right time to take a decision on this? So we
can tell users a bit more in advance.
Or is the decision already taken to stick to the plan?

A related matter is the following question of keeping backports to 3.44.

Cheers,
Denis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260820/72f13cf5/attachment.htm>

From david at opengis.ch  Thu Aug 20 03:24:12 2026
From: david at opengis.ch (David Signer)
Date: Thu, 20 Aug 2026 12:24:12 +0200
Subject: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
In-Reply-To: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
Message-ID: <CAETFtH=t0e3bgbFU3QvJZxGRBz80f-pkAmu6RzpA2TXf2BsuNw@mail.gmail.com>

Thanks, Denis, for raising this topic.

I understand the considerations publishing 4.2 as LTR. But I believe many
users would be disappointed by another rescheduling. They have been waiting
quite a while for a release with more than 4 months of support, especially
since we already rescheduled release 4.0. For most of them, an LTR is
nothing else than a release that gets longer support.

Of course, we would need to make it clear that e.g. HTML support is not
provided and that moving from 3 to 4 is a big step that carries some risks.

I just wanted to point this out. Anyway I'm open to being convinced that a
reschedule is really necessary. Thanks anyway and cheers
Dave

On Thu, Aug 20, 2026 at 11:22?AM Denis Rouzaud via QGIS-PSC <
qgis-psc at lists.osgeo.org> wrote:

> Dear PSC, dear Devs,
>
> On the release schedule, the next LTR still targets 4.2.4 in October.
>
> Two things to consider from
> https://github.com/qgis/QGIS-Enhancement-Proposals/pull/377:
> - HTML print layout support is targeted for 4.4 (which is/seems to be a
> big blocker, requiring a backport)
> - The stability of 4.2 is questioned
>
> I also feel that we could wait for 4.4 to do a LTR but the timing is
> getting critical. "Enterprise" users are wondering what is the current
> status, and we don't have a clear answer.
>
> I believe it would be the right time to take a decision on this? So we
> can tell users a bit more in advance.
> Or is the decision already taken to stick to the plan?
>
> A related matter is the following question of keeping backports to 3.44.
>
> Cheers,
> Denis
>
>
> _______________________________________________
> QGIS-PSC mailing list
> QGIS-PSC at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260820/240cb6f3/attachment-0001.htm>

From jef at norbit.de  Thu Aug 20 05:14:07 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Thu, 20 Aug 2026 14:14:07 +0200
Subject: [QGIS-Developer] Next 4.x LTR
In-Reply-To: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
Message-ID: <20260820121407.tx6cjh5kqkawnwga@norbit.de>

Hi Denis,

On Thu, 20. Aug 2026 at 11:22:04 +0200, Denis Rouzaud via QGIS-Developer wrote:
> On the release schedule, the next LTR still targets 4.2.4 in October.

Well, actually that's already done.  The branch is what is LTR and that's
release-4_2 with the ltr-4_2 tag.  So rescheduling would at least mean to
remove that tag (and AFAIK everyone who already pulled it, would have to delete
it manually).

That the new LTR doesn't get instantantly to the LTR repos is just because the
repos get an update all four weeks and while the new ltr is still the latest
release, we would have only one release to feed to both.   Therefore the
previous ltr release is still put into the ltr package repos, while the new ltr
release that is also the latest release goes into the other repos.  The ltr
enters the ltr repos once there's a new release.  That way both repos get
continuous updates and following the ltr repos gives you a new ltr only after
it has been around for a while.

But in my view the LTR started with the branch and gets more stability just
because it's longer maintained.


J?rgen

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

From gdt at lexort.com  Thu Aug 20 05:22:32 2026
From: gdt at lexort.com (Greg Troxel)
Date: Thu, 20 Aug 2026 08:22:32 -0400
Subject: [QGIS-Developer] Next 4.x LTR
In-Reply-To: <20260820121407.tx6cjh5kqkawnwga@norbit.de> (=?utf-8?Q?=22J?=
 =?utf-8?Q?=C3=BCrgen?= E. Fischer
 via QGIS-Developer"'s message of "Thu, 20 Aug 2026 14:14:07 +0200")
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
 <20260820121407.tx6cjh5kqkawnwga@norbit.de>
Message-ID: <rmilda1f0c7.fsf@s1.lexort.com>

J?rgen E. Fischer via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> Hi Denis,
>
> On Thu, 20. Aug 2026 at 11:22:04 +0200, Denis Rouzaud via QGIS-Developer wrote:
>> On the release schedule, the next LTR still targets 4.2.4 in October.
>
> Well, actually that's already done.  The branch is what is LTR and that's
> release-4_2 with the ltr-4_2 tag.  So rescheduling would at least mean to
> remove that tag (and AFAIK everyone who already pulled it, would have to delete
> it manually).
>
> That the new LTR doesn't get instantantly to the LTR repos is just because the
> repos get an update all four weeks and while the new ltr is still the latest
> release, we would have only one release to feed to both.   Therefore the
> previous ltr release is still put into the ltr package repos, while the new ltr
> release that is also the latest release goes into the other repos.  The ltr
> enters the ltr repos once there's a new release.  That way both repos get
> continuous updates and following the ltr repos gives you a new ltr only after
> it has been around for a while.

As someone who believes that what matters is source code and
declarations about source code -- and that binary distribution should
follow from that and not be that important semantically -- I find this
pretty boggling.

As I understand it, today the "current LTR" is 3.44.13.   The 4.2 branch
series has not yet been blessed as LTR, even if there is a tag in a repo
indicating a plan to do that at some point.

At some point, there will be a declaration that 4.2.x is an LTR, and
3.44.y will become the old LTR -- but that as I understand it hasn't
happened yet.


It sounds like there are legitimate concerns that 4.2 is not suitable
for production use, as in  it isn't possible to announce "We don't know
anything about your environment, but for almost everyone, the right
thing to do is to update to 4.2.x as soon as we declare it LTR".   Of
course, everyone -- from big enterprises to individuals -- should do
backups and test their workflows before upgrading.

What does PSC think about whether say 90% of qgis users: are they (or
will they be in October) better served by 4.2 than 3.44?

From julien.cabieces at oslandia.com  Thu Aug 20 05:39:23 2026
From: julien.cabieces at oslandia.com (Julien Cabieces)
Date: Thu, 20 Aug 2026 14:39:23 +0200
Subject: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
In-Reply-To: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
 (Denis Rouzaud via's message of "Thu, 20 Aug 2026 11:22:04 +0200")
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
Message-ID: <87jyplezk4.fsf@julienlaptop.home>


Hi all,

And thank you Denis for raising this topic. I was also debatting this
matter yesterday with some colleagues.

> Dear PSC, dear Devs,
>
> On the release schedule, the next LTR still targets 4.2.4 in October.
>
> Two things to consider from https://github.com/qgis/QGIS-Enhancement-Proposals/pull/377:
> - HTML print layout support is targeted for 4.4 (which is/seems to be
> a big blocker, requiring a backport)

I'm wondering if it would be possible to backport it to 4.2 before 4.2.4.

> - The stability of 4.2 is questioned
>

I also hear this kind of opinion here and there, from users and
developers. Do we have factual elements that tend to demonstrate that the
4.2 is not stable enough ? Are there any other strong blocking points ?

I'm not against a rescheduling but like David pointed out, It's not
without consequences.

Regards,
Julien

> I also feel that we could wait for 4.4 to do a LTR but the timing is getting critical. "Enterprise" users are wondering what is the current status,
> and we don't have a clear answer.
>
> I believe it would be the right time to take a decision on this? So we can tell users a bit more in advance.
> Or is the decision already taken to stick to the plan?
>
> A related matter is the following question of keeping backports to 3.44.
>
> Cheers,
> Denis
>
> _______________________________________________
> QGIS-PSC mailing list
> QGIS-PSC at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc

-- 

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

From nabaz.gharib at gmail.com  Thu Aug 20 06:28:26 2026
From: nabaz.gharib at gmail.com (nabaz gharib)
Date: Thu, 20 Aug 2026 13:28:26 +0000
Subject: [QGIS-Developer] Enhancing RTL Text Rendering & Labeling (Curved
 Labels, Annotations)
Message-ID: <GVYP280MB059274426D30FFB0071D55B8F4A42@GVYP280MB0592.SWEP280.PROD.OUTLOOK.COM>

Hello DEV team,

First off, huge respect and gratitude to the QGIS core team and contributors for building such an incredible open-source GIS tool. The work done here is phenomenal!

I wanted to open a discussion around a long-standing challenge that significantly impacts cartographers working with Right-to-Left (RTL) scripts (such as Kurdish, Arabic, Persian, etc.): complete RTL text rendering support.
While basic RTL text rendering works well in many standard places, it frequently breaks during advanced cartographic styling?most notably with curved/along-line labels, map annotations, callouts, and multi-line formatting.
Here are several open GitHub issues tracking these challenges:
https://github.com/qgis/QGIS/issues/57123
https://github.com/qgis/QGIS/issues/65311
https://github.com/qgis/QGIS/issues/21940
https://github.com/qgis/QGIS/issues/54098
While these may look like minor visual bugs from the outside, they create major bottlenecks for daily professional mapping workflows in RTL languages. I wish I had the C++/Qt background to jump in and submit PRs myself!
Finally, I appreciate if dev team pay attention to better RTL support.

Again thanks for your efforts.

Best Regards.
Nabaz


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

From Ethan.Snyder at rve.com  Thu Aug 20 06:23:04 2026
From: Ethan.Snyder at rve.com (Ethan Snyder)
Date: Thu, 20 Aug 2026 13:23:04 +0000
Subject: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
In-Reply-To: <CAETFtH=t0e3bgbFU3QvJZxGRBz80f-pkAmu6RzpA2TXf2BsuNw@mail.gmail.com>
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
 <CAETFtH=t0e3bgbFU3QvJZxGRBz80f-pkAmu6RzpA2TXf2BsuNw@mail.gmail.com>
Message-ID: <CO6PR01MB74658E99EA9936F2DF0097919BA42@CO6PR01MB7465.prod.exchangelabs.com>

If I may make a request,

If it is decided to move forward with 4.2 to become the next LTR, could we add a new item in the OSGeo4W Network installer for qgis-3-ltr?
This so that we don?t loose access to 3.44 LTR when the 4.x LTR is eventually released.
The missing HTML frame support in QGIS 4 is currently the blocker for us.

Thanks,

[cid:image001.png at 01DD3085.80116470]
Ethan Snyder
Senior GIS/GPS Technician & Software Engineer
ethan.snyder at rve.com<mailto:ethan.snyder at rve.com>

From: David Signer <david at opengis.ch>
Sent: Thursday, August 20, 2026 6:24 AM
To: Denis Rouzaud <denis.rouzaud at gmail.com>
Cc: QGIS PSC <qgis-psc at lists.osgeo.org>; qgis-developer <qgis-developer at lists.osgeo.org>
Subject: Re: [QGIS-Developer] [Qgis-psc] Next 4.x LTR

Thanks, Denis, for raising this topic.
I understand the considerations publishing 4.2 as LTR. But I believe many users would be disappointed by another rescheduling. They have been waiting quite a while for a release with more than 4 months of support, especially since we already rescheduled release 4.0. For most of them, an LTR is nothing else than a release that gets longer support.

Of course, we would need to make it clear that e.g. HTML support is not provided and that moving from 3 to 4 is a big step that carries some risks.

I just wanted to point this out. Anyway I'm open to being convinced that a reschedule is really necessary. Thanks anyway and cheers
Dave
On Thu, Aug 20, 2026 at 11:22?AM Denis Rouzaud via QGIS-PSC <qgis-psc at lists.osgeo.org<mailto:qgis-psc at lists.osgeo.org>> wrote:
Dear PSC, dear Devs,

On the release schedule, the next LTR still targets 4.2.4 in October.

Two things to consider from https://github.com/qgis/QGIS-Enhancement-Proposals/pull/377<https://github.com/qgis/QGIS-Enhancement-Proposals/pull/377>:
- HTML print layout support is targeted for 4.4 (which is/seems to be a big blocker, requiring a backport)
- The stability of 4.2 is questioned

I also feel that we could wait for 4.4 to do a LTR but the timing is getting critical. "Enterprise" users are wondering what is the current status, and we don't have a clear answer.

I believe it would be the right time to take a decision on this? So we can tell users a bit more in advance.
Or is the decision already taken to stick to the plan?

A related matter is the following question of keeping backports to 3.44.

Cheers,
Denis


_______________________________________________
QGIS-PSC mailing list
QGIS-PSC at lists.osgeo.org<mailto:QGIS-PSC at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/qgis-psc<https://lists.osgeo.org/mailman/listinfo/qgis-psc>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260820/69471e07/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 12185 bytes
Desc: image001.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260820/69471e07/attachment-0001.png>

From jef at norbit.de  Thu Aug 20 06:36:05 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Thu, 20 Aug 2026 15:36:05 +0200
Subject: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
In-Reply-To: <CO6PR01MB74658E99EA9936F2DF0097919BA42@CO6PR01MB7465.prod.exchangelabs.com>
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
 <CAETFtH=t0e3bgbFU3QvJZxGRBz80f-pkAmu6RzpA2TXf2BsuNw@mail.gmail.com>
 <CO6PR01MB74658E99EA9936F2DF0097919BA42@CO6PR01MB7465.prod.exchangelabs.com>
Message-ID: <20260820133605.nz42s36bcx5w6ndg@norbit.de>

Hi Ethan,

On Thu, 20. Aug 2026 at 13:23:04 +0000, Ethan Snyder via QGIS-Developer wrote:
> If it is decided to move forward with 4.2 to become the next LTR, could we
> add a new item in the OSGeo4W Network installer for qgis-3-ltr?

Not necessary.  You can install always install old packages from snapshots.
https://trac.osgeo.org/osgeo4w#Olderversionsfromreposnapshots

And the old MSI won't vanish either.

But there are obviously not going to be updated.


J?rgen

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

From lova at kartoza.com  Thu Aug 20 10:21:57 2026
From: lova at kartoza.com (Lova Andriarimalala)
Date: Thu, 20 Aug 2026 20:21:57 +0300
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <rmia4qigryt.fsf@s1.lexort.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <rmijypmieis.fsf@s1.lexort.com>
 <CAMLC-sBK-F5geby3iaZ0Ct__Tz=COi3JzSiGU-Fb9z2vMrFfZw@mail.gmail.com>
 <rmia4qigryt.fsf@s1.lexort.com>
Message-ID: <CAMLC-sBi+0zHN+xXLURDGhwM9u0p1pjrLi=f+1_REukp1KT_xg@mail.gmail.com>

Hi Greg,

Thanks so much for your inputs.

> Why do you it "should include reimplementing..."?  That's a decision
> that the answer to the previous question is that ratings are so
> important that any cost to properly implement is justified.  I see no
> basis to decide that.

I apologize if it sounds like a decision. I was just explaining the idea
based on previous suggestions.

> IMHO plugins should have a public forge or at least an issue tracker.
> (Speaking of Free Software norms, that shouldn't be on github!)  People
> that want to make suggestions to plugin authors can use that.  I have
> filed issues to plugins, with varying effects.

Sure, that makes total sense.

> Another aspect of this is that popular voting, even if we somehow ensure
> that each voter is a community member, that all votes are cast by
> humans, and that no human community member can vote with two or more
> identities, is that opinions need to be considered in light of the
> experience/reputation of the voter.
> I see this voting system as sufficiently problematic that I don't find
> it of much value.

I agree. So, in my understanding, the consensus is that we can safely
remove it from the plugin manager and then from plugins.qgis.org. Removing
it from plugins.qgis.org would probably require some communication so that
people relying on it are aware of the removal. If there are strong
motivations or suggestions regarding the system, is it possible to re-open
the discussion?

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, 19 Aug 2026 at 16:28, Greg Troxel <gdt at lexort.com> wrote:

> Lova Andriarimalala <lova at kartoza.com> writes:
>
> > Hi Lauren?iu and Greg,
> >
> >> Stepping back, why does the QGIS project feel the need to support a
> >> rating system for third-party code at all?
> >
> > Unfortunately, I don't have the direct answer to that. I was involved in
> > implementing download statistics by country for each plugin and I think
> > this is similar. Basically, they provide insights/metrics for plugin
> > developers and maybe for users as well.
>
> Makes sense about statistics.  That has the same faking problem.   I do
> realize that there is some insight.
>
> But the real question is whether the insight gained is worth the cost of
> implementing ratings in a way which
>   - has adequate protection from fake ratings
>   - complies with GDPR and other rules
>   - complies with Free Software community ethics
>
> There's a lot of cost to doing it right.
>
> >> Why not just remove all rating data, and remove the code in qgis to
> >> fetch ratings and vote?
> >
> > Technically, that aligns with part of my suggestion earlier. However,
> this
> > should include (re)-implementing a clean proper rating system that
> requires
> > users to be authenticated and leave a comment, which would help plugin
> > developers improve their plugins as Denis and Nyall mentioned.
>
> Why do you it "should include reimplementing..."?  That's a decision
> that the answer to the previous question is that ratings are so
> important that any cost to properly implement is justified.  I see no
> basis to decide that.
>
> IMHO plugins should have a public forge or at least an issue tracker.
> (Speaking of Free Software norms, that shouldn't be on github!)  People
> that want to make suggestions to plugin authors can use that.  I have
> filed issues to plugins, with varying effects.
>
>
> Another aspect of this is that popular voting, even if we somehow ensure
> that each voter is a community member, that all votes are cast by
> humans, and that no human community member can vote with two or more
> identities, is that opinions need to be considered in light of the
> experience/reputation of the voter.
>
>
> I see this voting system as sufficiently problematic that I don't find
> it of much value.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260820/399248ef/attachment.htm>

From nyall.dawson at gmail.com  Thu Aug 20 18:54:28 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 21 Aug 2026 11:54:28 +1000
Subject: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
In-Reply-To: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
Message-ID: <CAB28AsgVbbfhaf35nSc+mdLBt4M+7hi1ciz+5vWXAe_OU9VXYw@mail.gmail.com>

On Thu, 20 Aug 2026 at 19:22, Denis Rouzaud via QGIS-PSC
<qgis-psc at lists.osgeo.org> wrote:
>
> Dear PSC, dear Devs,
>
> On the release schedule, the next LTR still targets 4.2.4 in October.
>
> Two things to consider from https://github.com/qgis/QGIS-Enhancement-Proposals/pull/377:
> - HTML print layout support is targeted for 4.4 (which is/seems to be a big blocker, requiring a backport)
> - The stability of 4.2 is questioned
>
> I also feel that we could wait for 4.4 to do a LTR but the timing is getting critical. "Enterprise" users are wondering what is the current status, and we don't have a clear answer.
>
> I believe it would be the right time to take a decision on this? So we can tell users a bit more in advance.
> Or is the decision already taken to stick to the plan?

My 2c: tagging a release as an LTR isn't *just* a commitment to
supporting it for extra patch releases, it's also the project
officially recommending it as the stable release which should be used
by enterprise customers.

I don't think we're there yet for 4.2. 3.44 is a VERY solid release,
and I think we'd be doing our enterprise users a disservice by
officially promoting the idea that 4.4 is just as stable.

Nyall


>
> A related matter is the following question of keeping backports to 3.44.
>
> Cheers,
> Denis
>
>
> _______________________________________________
> QGIS-PSC mailing list
> QGIS-PSC at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc

From nyall.dawson at gmail.com  Thu Aug 20 22:29:09 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 21 Aug 2026 15:29:09 +1000
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMLC-sBi+0zHN+xXLURDGhwM9u0p1pjrLi=f+1_REukp1KT_xg@mail.gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <rmijypmieis.fsf@s1.lexort.com>
 <CAMLC-sBK-F5geby3iaZ0Ct__Tz=COi3JzSiGU-Fb9z2vMrFfZw@mail.gmail.com>
 <rmia4qigryt.fsf@s1.lexort.com>
 <CAMLC-sBi+0zHN+xXLURDGhwM9u0p1pjrLi=f+1_REukp1KT_xg@mail.gmail.com>
Message-ID: <CAB28Asj-TcwtiHH6pJ0cLZQ+04HJ2MvL7p3BHZaveb_NGaSyPw@mail.gmail.com>

On Fri, 21 Aug 2026 at 03:22, Lova Andriarimalala via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>

> I agree. So, in my understanding, the consensus is that we can safely remove it from the plugin manager and then from plugins.qgis.org. Removing it from plugins.qgis.org would probably require some communication so that people relying on it are aware of the removal. If there are strong motivations or suggestions regarding the system, is it possible to re-open the discussion?

I think there's still value in it, and showing it as a read-only
property directly in the plugin manager.

Nyall


>
> Best regards,
>
> Lova Andriarimalala
> QGIS Full Stack Developer
>
> T : +27(0) 87 809 2702          E : lova at kartoza.com          W : kartoza.com
>
>
>
> This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you
> have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying
> of the contents is prohibited.
>
>
> On Wed, 19 Aug 2026 at 16:28, Greg Troxel <gdt at lexort.com> wrote:
>>
>> Lova Andriarimalala <lova at kartoza.com> writes:
>>
>> > Hi Lauren?iu and Greg,
>> >
>> >> Stepping back, why does the QGIS project feel the need to support a
>> >> rating system for third-party code at all?
>> >
>> > Unfortunately, I don't have the direct answer to that. I was involved in
>> > implementing download statistics by country for each plugin and I think
>> > this is similar. Basically, they provide insights/metrics for plugin
>> > developers and maybe for users as well.
>>
>> Makes sense about statistics.  That has the same faking problem.   I do
>> realize that there is some insight.
>>
>> But the real question is whether the insight gained is worth the cost of
>> implementing ratings in a way which
>>   - has adequate protection from fake ratings
>>   - complies with GDPR and other rules
>>   - complies with Free Software community ethics
>>
>> There's a lot of cost to doing it right.
>>
>> >> Why not just remove all rating data, and remove the code in qgis to
>> >> fetch ratings and vote?
>> >
>> > Technically, that aligns with part of my suggestion earlier. However, this
>> > should include (re)-implementing a clean proper rating system that requires
>> > users to be authenticated and leave a comment, which would help plugin
>> > developers improve their plugins as Denis and Nyall mentioned.
>>
>> Why do you it "should include reimplementing..."?  That's a decision
>> that the answer to the previous question is that ratings are so
>> important that any cost to properly implement is justified.  I see no
>> basis to decide that.
>>
>> IMHO plugins should have a public forge or at least an issue tracker.
>> (Speaking of Free Software norms, that shouldn't be on github!)  People
>> that want to make suggestions to plugin authors can use that.  I have
>> filed issues to plugins, with varying effects.
>>
>>
>> Another aspect of this is that popular voting, even if we somehow ensure
>> that each voter is a community member, that all votes are cast by
>> humans, and that no human community member can vote with two or more
>> identities, is that opinions need to be considered in light of the
>> experience/reputation of the voter.
>>
>>
>> I see this voting system as sufficiently problematic that I don't find
>> it of much value.
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

From gdt at lexort.com  Fri Aug 21 04:03:02 2026
From: gdt at lexort.com (Greg Troxel)
Date: Fri, 21 Aug 2026 07:03:02 -0400
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAB28Asj-TcwtiHH6pJ0cLZQ+04HJ2MvL7p3BHZaveb_NGaSyPw@mail.gmail.com>
 (Nyall Dawson's message of "Fri, 21 Aug 2026 15:29:09 +1000")
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <rmijypmieis.fsf@s1.lexort.com>
 <CAMLC-sBK-F5geby3iaZ0Ct__Tz=COi3JzSiGU-Fb9z2vMrFfZw@mail.gmail.com>
 <rmia4qigryt.fsf@s1.lexort.com>
 <CAMLC-sBi+0zHN+xXLURDGhwM9u0p1pjrLi=f+1_REukp1KT_xg@mail.gmail.com>
 <CAB28Asj-TcwtiHH6pJ0cLZQ+04HJ2MvL7p3BHZaveb_NGaSyPw@mail.gmail.com>
Message-ID: <rmi1pbrbus9.fsf@s1.lexort.com>

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

> On Fri, 21 Aug 2026 at 03:22, Lova Andriarimalala via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
>
>> I agree. So, in my understanding, the consensus is that we can
>> safely remove it from the plugin manager and then from
>> plugins.qgis.org. Removing it from plugins.qgis.org would probably
>> require some communication so that people relying on it are aware of
>> the removal. If there are strong motivations or suggestions
>> regarding the system, is it possible to re-open the discussion?
>
> I think there's still value in it, and showing it as a read-only
> property directly in the plugin manager.

Do you mean:

   Fetch the existing stats and display them, but disable the ability to
   record new votes?

   Fetch, and keep the current anonymous vote counter?

   Fetch, and implement some kind of counting scheme with ?? other
   features?
   

From valentin.buira at gmail.com  Fri Aug 21 09:06:17 2026
From: valentin.buira at gmail.com (Valentin Buira)
Date: Fri, 21 Aug 2026 18:06:17 +0200
Subject: [QGIS-Developer] Rating abuse issue on the QGIS Plugins Website
In-Reply-To: <CAMLC-sADG17-X65mbiNe0X4-gPSzD+VUWJaTV4p0GVeGrXbMww@mail.gmail.com>
References: <CAMLC-sBkyHjNFwC0KsxpgHPF3V=HY1VM9fpQ1s8zRCfFKX80Tg@mail.gmail.com>
 <CAMtsY+Z2rwsFzpAUHPNnyk+7w30z3+mays3rgrMtDi8C8MQdNg@mail.gmail.com>
 <4d70c538-b1b5-4c82-8172-9e87cd3fbcf9@gmail.com>
 <CAMLC-sADG17-X65mbiNe0X4-gPSzD+VUWJaTV4p0GVeGrXbMww@mail.gmail.com>
Message-ID: <CANrSSZkni_gWNcqEbV_gnjGp0u+mZyRu6WSOMyzMGzov7qa-BQ@mail.gmail.com>

Hi Lova,

>  I agree that shifting to authenticated ratings with a proper comment
system makes the most sense given the current situation.

Thanks a lot for suggesting this, I had one bad review without explanation
on one of my plugins, and it still haunts me to this day!

If you're looking to draw some inspiration, I think over the years Steam
really nailed the rating system in their game store.

* They display two ratings, one rating average from recent reviews, and one
rating average for the overall reviews on the lifetime of the game.
* There is a bar chart with positive/negative rating along the year, so you
can see the evolution and "review bombing" [0]
* The review include info like hardware of the users, game version -> this
could be simplified to QGIS Version and Plugin version, and maybe OS
* Reviews always have comments
* You can filter reviews by your language, date, rating, positive/negative
etc...

Of course we don't have to have as compelling a rating system (And we
probably should not, we are not in the plugin selling nor video game
selling business after all). But I think it's interesting to look at it
anyway

Cheers,
Valentin

[0] one good example of this is "no man's sky" than went from most negative
to mostly positive alongs the updates
https://store.steampowered.com/app/275850/No_Mans_Sky/#app_reviews_hash

Le mer. 19 ao?t 2026 ? 11:57, Lova Andriarimalala via QGIS-Developer <
qgis-developer at lists.osgeo.org> a ?crit :

> Hi R?gis and Denis
>
> Thank you for the input. I agree that shifting to authenticated ratings
> with a proper comment system makes the most sense given the current
> situation.
>
> With that change, I wonder if it wouldn't be simpler to start with clean
> rating records for all plugins rather than migrating those who rated with
> an account from the current obsolete ones. This will prevent recalculating
> all ratings based on the new rule or considering removing any rating based
> on abuse (which is difficult to determine) if we even choose to keep the
> obsolete records. With clean records, we could easily add the
> mandatory constructive comments feature as Denis suggested.
>
> On the QGIS Desktop side, this change will most likely require a QEP first
> because the existing feature in current and previous versions will break
> and I am not familiar with how to handle that.
>
> I can also prepare a detailed plan for the changes and announcement
> accordingly.
>
> 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, 19 Aug 2026 at 10:43, R?gis Haubourg <regis.haubourg at gmail.com>
> wrote:
>
>> Hi, and thanks for the very clear situation overview Lova!
>>
>> Firefox  requires to log to be able to rate.  I concur with Denis.
>> Anonymous voting is now obsolete to me, as the ecosystem has grown and many
>> companies rely on this ecosystem.
>>
>> I would have no problem with a communication campaign announcing that
>> rating is no more authorized for anonymous accounts, and should only be
>> done from the website, as I don't think we want to add a sign in feature
>> from QGIS desktop itself. This feature would open the gate to a bunch of
>> security / privacy /compliance issues that I don't thing we want to add
>> complexity right now, as this is one strength of QGIS, to have no link with
>> our public infrastructure and no personal data collection.
>>
>> So, I guess that would mean that we remove the rating feature from QGIS
>> desktop and that the voting button only opens the web app at the right
>> place.
>>
>>
>> Best regards
>>
>> R?gis
>>
>>
>>
>> On 19/08/2026 09:16, Denis Rouzaud via QGIS-Developer wrote:
>>
>> Hi,
>>
>> We switch to osgeo logged-in users only and force to have a
>> (constructive) comment?
>> Otherwise votes are meaningless and useless I'd say.
>>
>> Cheers,
>> Denis
>>
>> Le mer. 19 ao?t 2026 ? 09:07, Lova Andriarimalala via QGIS-Developer <
>> qgis-developer at lists.osgeo.org> a ?crit :
>>
>>> Hello everyone,
>>>
>>> Following the plugin rating abuse issue reported at
>>> https://github.com/qgis/QGIS-Plugins-Website/issues/416 and
>>> https://github.com/qgis/QGIS-Plugins-Website/issues/420, I wonder if
>>> someone could help or share some thoughts about it.
>>>
>>> We have released some fixes to enforce throttles (
>>> https://github.com/qgis/QGIS-Plugins-Website/pull/418), reject forged
>>> cookies and add a cap votes per address (
>>> https://github.com/qgis/QGIS-Plugins-Website/pull/423). However, it is
>>> not fully working because every IP recorded against a vote is a Cloudflare
>>> edge IP, not a real user IP. I checked 100 recent votes against
>>> Cloudflare's published ranges: 100 out of 100 match. So the per-IP cap is
>>> counting Cloudflare's proxy pool, which rotates per request. So, storing
>>> real client IPs would probably require some discussions regarding GDPR and
>>> retention angle.
>>>
>>> The reporter also asks us to (a) purge the fake votes and recompute the
>>> affected plugin scores, and (b) require a logged-in account to vote. Both
>>> are policy calls, not just code. And noting that the latter will probably
>>> break how the QGIS Desktop plugin manager submits ratings anonymously over
>>> XML-RPC.
>>>
>>> Thanks so much in advance for any input.
>>>
>>> Lova Andriarimalala
>>>
>>>
>>> *QGIS Full Stack Developer    *
>>> *T *: +27(0) 87 809 2702          *E *: lova at kartoza.com          *W* :
>>> kartoza.com
>>>
>>> _______________________________________________
>>> QGIS-Developer mailing list
>>> QGIS-Developer at lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>> _______________________________________________
>> QGIS-Developer mailing listQGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260821/d86d2643/attachment.htm>

From jef at norbit.de  Mon Aug 24 06:14:57 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Mon, 24 Aug 2026 15:14:57 +0200
Subject: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
In-Reply-To: <CAB28AsgVbbfhaf35nSc+mdLBt4M+7hi1ciz+5vWXAe_OU9VXYw@mail.gmail.com>
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
 <CAB28AsgVbbfhaf35nSc+mdLBt4M+7hi1ciz+5vWXAe_OU9VXYw@mail.gmail.com>
Message-ID: <20260824131457.ac7w6kjfv64sr5dp@norbit.de>

Hi Nyall,

On Fri, 21. Aug 2026 at 11:54:28 +1000, Nyall Dawson via QGIS-Developer wrote:
> I don't think we're there yet for 4.2. 3.44 is a VERY solid release,
> and I think we'd be doing our enterprise users a disservice by
> officially promoting the idea that 4.4 is just as stable.

So your suggestion is to removed the ltr-4_2 tag and continue 3.44 as LTR for
the forseeable future until there is a 4.x release that is close to the
stability of 3.44?


J?rgen

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

From yawmensah3310 at gmail.com  Mon Aug 24 06:42:12 2026
From: yawmensah3310 at gmail.com (Yaw Mensah)
Date: Mon, 24 Aug 2026 09:42:12 -0400
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
Message-ID: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>

Hi,

I was wondering whether distributing QGIS Desktop through the Microsoft
Store has been considered before.

I have some experience packaging and publishing Windows applications
through the Microsoft Store and would be interested in helping investigate
this as an additional distribution option for QGIS.

Before I start experimenting with a package, I wanted to ask whether there
are known blockers or project concerns around this, particularly regarding
dependencies, signing, updates, or maintaining an additional distribution
channel.

If this is something the project would be open to exploring, I'd be happy
to investigate the packaging requirements and contribute a proof of concept.

Thanks,
Yaw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260824/85096465/attachment.htm>

From gdt at lexort.com  Mon Aug 24 10:49:30 2026
From: gdt at lexort.com (Greg Troxel)
Date: Mon, 24 Aug 2026 13:49:30 -0400
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
 (Yaw Mensah via's message of "Mon, 24 Aug 2026 09:42:12 -0400")
References: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
Message-ID: <rmifr031k9h.fsf@s1.lexort.com>

Yaw Mensah via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:

> I was wondering whether distributing QGIS Desktop through the Microsoft
> Store has been considered before.
>
> I have some experience packaging and publishing Windows applications
> through the Microsoft Store and would be interested in helping investigate
> this as an additional distribution option for QGIS.
>
> Before I start experimenting with a package, I wanted to ask whether there
> are known blockers or project concerns around this, particularly regarding
> dependencies, signing, updates, or maintaining an additional distribution
> channel.

Can you explain how the IP terms work?  When people get binaries
through the store, are they able to redisribute them to other people?
  - Do they have the technical ability to copy?
  - Is there anything in the MS Store terms that prohibit such copying?

I have no idea what the answers are here, but I think it's always an
important question when considering distribution methods.

(That's all assuming that qgis continues to be licensed under GPL2!)

From nyall.dawson at gmail.com  Mon Aug 24 17:26:09 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Tue, 25 Aug 2026 10:26:09 +1000
Subject: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
In-Reply-To: <20260824131457.ac7w6kjfv64sr5dp@norbit.de>
References: <CAMtsY+aO0vvzVVZMjviE+gj-p=qxDB-cs-MMNbx=szXfdrR-cQ@mail.gmail.com>
 <CAB28AsgVbbfhaf35nSc+mdLBt4M+7hi1ciz+5vWXAe_OU9VXYw@mail.gmail.com>
 <20260824131457.ac7w6kjfv64sr5dp@norbit.de>
Message-ID: <CAB28AsjHYEi8uHi=mUZ-PV78sfuE0H2AJ49AcRQE6GB1NguKRg@mail.gmail.com>

On Mon, 24 Aug 2026 at 23:15, J?rgen E. Fischer via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hi Nyall,
>
> On Fri, 21. Aug 2026 at 11:54:28 +1000, Nyall Dawson via QGIS-Developer wrote:
> > I don't think we're there yet for 4.2. 3.44 is a VERY solid release,
> > and I think we'd be doing our enterprise users a disservice by
> > officially promoting the idea that 4.4 is just as stable.
>
> So your suggestion is to removed the ltr-4_2 tag and continue 3.44 as LTR for
> the forseeable future until there is a 4.x release that is close to the
> stability of 3.44?

That's my feeling.

(I mean -- try opening a layout, selecting two items, and group ...
*CRASH*. This is the kind of fundamental issue I'm referring to when I
say 4.2 isn't a match for 3.44 for stability).

Nyall


>
>
> J?rgen
>
> --
> J?rgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)             Rheinstra?e 13          Fax. +49-4931-918175-50
> Software Engineer           D-26506 Norden            https://www.norbit.de
> QGIS release manager (PSC)  Germany                  Matrix: @jef:osgeo.org
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

From tim at kartoza.com  Tue Aug 25 14:15:19 2026
From: tim at kartoza.com (Tim Sutton)
Date: Tue, 25 Aug 2026 22:15:19 +0100
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <rmifr031k9h.fsf@s1.lexort.com>
References: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
 <rmifr031k9h.fsf@s1.lexort.com>
Message-ID: <CAES-DZR+nCk_bUfMX8vTChpStw30zGUCmr2oMiBeeCcoUNgxKw@mail.gmail.com>

Hi Yaw

Yes this is something we discuss occassionally - I think GIMP and / or
Inkscape are in the MS store too if I am not mistaken? I am going to add it
to the PSC meeting agenda again for next weeks call where we can discuss it
further and get back to you.

Regards

Tim



On Mon, Aug 24, 2026 at 6:49?PM Greg Troxel via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Yaw Mensah via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:
>
> > I was wondering whether distributing QGIS Desktop through the Microsoft
> > Store has been considered before.
> >
> > I have some experience packaging and publishing Windows applications
> > through the Microsoft Store and would be interested in helping
> investigate
> > this as an additional distribution option for QGIS.
> >
> > Before I start experimenting with a package, I wanted to ask whether
> there
> > are known blockers or project concerns around this, particularly
> regarding
> > dependencies, signing, updates, or maintaining an additional distribution
> > channel.
>
> Can you explain how the IP terms work?  When people get binaries
> through the store, are they able to redisribute them to other people?
>   - Do they have the technical ability to copy?
>   - Is there anything in the MS Store terms that prohibit such copying?
>
> I have no idea what the answers are here, but I think it's always an
> important question when considering distribution methods.
>
> (That's all assuming that qgis continues to be licensed under GPL2!)
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 

Tim Sutton

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

*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/20260825/b6cd4f68/attachment.htm>

From gdt at lexort.com  Tue Aug 25 15:54:46 2026
From: gdt at lexort.com (Greg Troxel)
Date: Tue, 25 Aug 2026 18:54:46 -0400
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <a464d273-889c-4ba9-837e-20aac8a0afd1@stripfamily.net> (David
 Strip's message of "Tue, 25 Aug 2026 16:42:53 -0600")
References: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
 <rmifr031k9h.fsf@s1.lexort.com>
 <CAES-DZR+nCk_bUfMX8vTChpStw30zGUCmr2oMiBeeCcoUNgxKw@mail.gmail.com>
 <a464d273-889c-4ba9-837e-20aac8a0afd1@stripfamily.net>
Message-ID: <rmio6epx13d.fsf@s1.lexort.com>

David Strip <qgis-user at stripfamily.net> writes:

> On 8/25/2026 3:15 PM, Tim Sutton via QGIS-Developer wrote: 
>
>  Hi Yaw
>
>  Yes this is something we discuss occassionally - I think GIMP and / or Inkscape are in the MS store too if I am not
>  mistaken? I am going to add it to the PSC meeting agenda again for next weeks call where we can discuss it further
>  and get back to you.
>
> I checked - yes, GIMP and Inkscape are in the store. QField is there too and lists the license as GPLv2 or later.  

Great, the next thing to check is if the terms are actually compatible.
Enough people are fuzzy on licensing and willing to break the rules
because they think app stores are important, that one can't conclude
it's ok.

For example, QField is in the apple app store, and that prohibits
distirbuting the app you receive.  That's outright incompatible with the
GPL, and QGIS does not have an apple exception.  I've raised this issue,
but I haven't seen any substantive comments addresssing it.  (I think
it's good there is no apple exception; the Free Software community
shouldn't have to break their own rules to accomodate Apple's choices to
be difficult about Free Software.)

From qgis-dev at stripfamily.net  Tue Aug 25 21:10:54 2026
From: qgis-dev at stripfamily.net (David Strip)
Date: Tue, 25 Aug 2026 22:10:54 -0600
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <rmio6epx13d.fsf@s1.lexort.com>
References: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
 <rmifr031k9h.fsf@s1.lexort.com>
 <CAES-DZR+nCk_bUfMX8vTChpStw30zGUCmr2oMiBeeCcoUNgxKw@mail.gmail.com>
 <a464d273-889c-4ba9-837e-20aac8a0afd1@stripfamily.net>
 <rmio6epx13d.fsf@s1.lexort.com>
Message-ID: <9b3cdbc6-07bb-423c-b375-ba0a8905edf1@stripfamily.net>

An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260825/52cc7094/attachment-0001.htm>

From deepti.venugopal at iiitb.ac.in  Tue Aug 25 23:49:20 2026
From: deepti.venugopal at iiitb.ac.in (Deepti Venugopal)
Date: Wed, 26 Aug 2026 06:49:20 +0000
Subject: [QGIS-Developer] Supervised Classifier Plugin - Issues
In-Reply-To: <TY2PPF7BEC1550BC99CF36AAC9140CB49E9DAAE2@TY2PPF7BEC1550B.apcprd06.prod.outlook.com>
References: <TY2PPF7BEC1550BC99CF36AAC9140CB49E9DAAE2@TY2PPF7BEC1550B.apcprd06.prod.outlook.com>
Message-ID: <TY2PPF7BEC1550B9F99B5B5F353EBB8A598DAAE2@TY2PPF7BEC1550B.apcprd06.prod.outlook.com>



________________________________


Hi Team,

In QGIS, installed Supervised Classifier plugin for my image classification problem statement.
[cid:e5e491ca-e793-419b-8250-97b15293f7c7]
[cid:72c963ba-bc77-47a8-8fe5-c3337c71ccc1]
As I thought this plugin would be plug n play but encountered 2 issues:


  1.
After installing the plugin, got issue with opening of ClassificationDialogBox
supervised_classifier.py", line 549, in show_classification_dialog               self.dialog = ClassificationDialog()               ^^^^^^^^^^^^^^^^^^^^              NameError: name 'ClassificationDialog' is not defined
Resolution: Added an import statement at the top of the file
  2.
During execution, I encountered lot of indentation errors as I opened the supervised_classifier.py file notepad++, fixed this in the entire file.


I have checked the QGIS-Developer Issues Archive website and above issues were not available. Hence am writing to the team to have a look and also would be helpful to know if there are any changes in my steps.

Thanks,
Deepti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/adbea15e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33066 bytes
Desc: image.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/adbea15e/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 35038 bytes
Desc: image.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/adbea15e/attachment-0003.png>

From deepti.venugopal at iiitb.ac.in  Tue Aug 25 23:55:45 2026
From: deepti.venugopal at iiitb.ac.in (Deepti Venugopal)
Date: Wed, 26 Aug 2026 06:55:45 +0000
Subject: [QGIS-Developer] Supervised Classifier Plugin - Issues
Message-ID: <TY2PPF7BEC1550B6E21605292ADDEC98E93DAAE2@TY2PPF7BEC1550B.apcprd06.prod.outlook.com>

Hi Team,

In QGIS, installed Supervised Classifier plugin for my image classification problem statement.
[cid:45c26f98-079f-4897-9271-175b8331dffd]
[cid:546b3bb2-a9ac-463d-ae99-c4ff40d28b4b]
As I thought this plugin would be plug n play but encountered 2 issues:


  1.
After installing the plugin, got issue with opening of ClassificationDialogBox
supervised_classifier.py", line 549, in show_classification_dialog               self.dialog = ClassificationDialog()               ^^^^^^^^^^^^^^^^^^^^              NameError: name 'ClassificationDialog' is not defined
Resolution: Added an import statement at the top of the file
  2.
During execution, I encountered lot of indentation errors as I opened the supervised_classifier.py file notepad++, fixed this in the entire file.


I have checked the QGIS-Developer Issues Archive website and above issues were not available. Hence am writing to the team to have a look and also would be helpful to know if there are any changes in my steps.

Thanks,
Deepti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/5cdf5fad/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33066 bytes
Desc: image.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/5cdf5fad/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 35038 bytes
Desc: image.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/5cdf5fad/attachment-0003.png>

From deepti.venugopal at iiitb.ac.in  Tue Aug 25 23:58:44 2026
From: deepti.venugopal at iiitb.ac.in (Deepti Venugopal)
Date: Wed, 26 Aug 2026 06:58:44 +0000
Subject: [QGIS-Developer] Supervised Classifier Plugin - Issues
Message-ID: <TY2PPF7BEC1550B09BDA7A6147E69D7A8C4DAAE2@TY2PPF7BEC1550B.apcprd06.prod.outlook.com>

Hi Team,

In QGIS, installed Supervised Classifier plugin for my image classification problem statement.
[cid:7c049d98-b193-4a7f-ae7f-aa581c098e59]
[cid:22e90dbc-ea0f-4873-838e-f52727d05a57]
As I thought this plugin would be plug n play but encountered 2 issues:


  1.
After installing the plugin, got issue with opening of ClassificationDialogBox
supervised_classifier.py", line 549, in show_classification_dialog               self.dialog = ClassificationDialog()               ^^^^^^^^^^^^^^^^^^^^              NameError: name 'ClassificationDialog' is not defined
Resolution: Added an import statement at the top of the file
  2.
During execution, I encountered lot of indentation errors as I opened the supervised_classifier.py file notepad++, fixed this in the entire file.


I have checked the QGIS-Developer Issues Archive website and above issues were not available. Hence am writing to the team to have a look and also would be helpful to know if there are any changes in my steps.

Thanks,
Deepti

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/4ef23b4f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33066 bytes
Desc: image.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/4ef23b4f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 35038 bytes
Desc: image.png
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/4ef23b4f/attachment-0003.png>

From custard at thornbill.net  Wed Aug 26 03:55:06 2026
From: custard at thornbill.net (ramon)
Date: Wed, 26 Aug 2026 10:55:06 +0000
Subject: [QGIS-Developer] Supervised Classifier Plugin - Issues
In-Reply-To: <TY2PPF7BEC1550B09BDA7A6147E69D7A8C4DAAE2@TY2PPF7BEC1550B.apcprd06.prod.outlook.com>
References: <TY2PPF7BEC1550B09BDA7A6147E69D7A8C4DAAE2@TY2PPF7BEC1550B.apcprd06.prod.outlook.com>
Message-ID: <C52A8C17-F4D2-4876-A359-8E1001C05C3F@thornbill.net>

Hi,

For the plugins you should be looking at the bug tracker for that plugin. It?s a link next ta "More infohomepage" in the screen shot and filing the bug there.

Regards,
Ramon
(Not a dev, just interested)

> On 26 Aug 2026, at 4:28?pm, Deepti Venugopal via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
>
> Hi Team,
>
> In QGIS, installed Supervised Classifier plugin for my image classification problem statement.
> <image.png>
> <image.png>
> As I thought this plugin would be plug n play but encountered 2 issues:
>
> - After installing the plugin, got issue with opening of ClassificationDialogBox
> supervised_classifier.py", line 549, in show_classification_dialog self.dialog = ClassificationDialog() ^^^^^^^^^^^^^^^^^^^^ NameError: name 'ClassificationDialog' is not defined
> Resolution: Added an import statement at the top of the file
> - During execution, I encountered lot of indentation errors as I opened the supervised_classifier.py file notepad++, fixed this in the entire file.
>
> I have checked the QGIS-Developer Issues Archive website and above issues were not available. Hence am writing to the team to have a look and also would be helpful to know if there are any changes in my steps.
>
> Thanks,
> Deepti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260826/d38144f0/attachment.htm>

From gdt at lexort.com  Wed Aug 26 06:10:09 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 26 Aug 2026 09:10:09 -0400
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <9b3cdbc6-07bb-423c-b375-ba0a8905edf1@stripfamily.net> (David
 Strip's message of "Tue, 25 Aug 2026 22:10:54 -0600")
References: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
 <rmifr031k9h.fsf@s1.lexort.com>
 <CAES-DZR+nCk_bUfMX8vTChpStw30zGUCmr2oMiBeeCcoUNgxKw@mail.gmail.com>
 <a464d273-889c-4ba9-837e-20aac8a0afd1@stripfamily.net>
 <rmio6epx13d.fsf@s1.lexort.com>
 <9b3cdbc6-07bb-423c-b375-ba0a8905edf1@stripfamily.net>
Message-ID: <rmiecfluixa.fsf@s1.lexort.com>

David Strip <qgis-dev at stripfamily.net> writes:

> On 8/25/2026 4:54 PM, Greg Troxel wrote:
>
>>  Great, the next thing to check is if the terms are actually compatible.
>> Enough people are fuzzy on licensing and willing to break the rules
>> because they think app stores are important, that one can't conclude
>> it's ok.
>
> Usual caveat - I am not a lawyer.
> The publisher agreement is here.
>
> The relevant section appears to be 3b - 
>
>  (b)   Third-Party Rights/Open-Source Licenses.  Your Offer and Offer Assets must not infringe or misappropriate any
>  intellectual property or personal right of any third party. If you license any portion of your Offer from a third
>  party or under any open-source license, you are solely responsible for compliance with such terms and for ensuring
>  that Microsoft, in its capacity as your agent or commissionaire, has the necessary rights to perform its obligations
>  to you under this Agreement. You are, at your sole cost and expense, responsible for securing, reporting, and
>  maintaining all necessary rights, clearances, and consents and paying all licensing fees (including applicable public
>  performance license fees or other consideration associated with providing music or video (and all content embodied
>  therein) in and through your Offer), and for undertaking all related reporting obligations.
>
> For open source licenses, MS appears to have removed itself from the licensing pathway between the person/organization
> submitting the product and the customer. It is thus incumbent on the submitter to provide the means for meeting the
> license requirements, such as providing links to the license and source code. Perhaps these links could be in the listing
> in the MS Store, or in the about screen of the app. This is already the case for the license in QGIS. 
>
> Obviously an actual lawyer would need to verify this interpretation. 

There are two sets of terms to consider.  One is the agreement between
the "app developer" and MS, and the other is between MS and people that
obtain software from the store.

The latter I think is at:
  https://www.microsoft.com/en-mt/store/b/terms-of-sale

which does say

  12. Software Licences and Use Rights.

  Software and other Digital Content, Digital Services and Additional
  Services made available to you through the Store are licensed, not
  sold, to you. Applications downloaded directly from the Store are
  subject to the Standard Application Licence Terms (?SALT?) unless
  different licence terms are provided with the application, with the
  exception of applications downloaded from the Office Store, which are
  not governed by the SALT and have separate license terms that are
  provided with the application.)

This is a key point and seems ok.

  Digital Content and Digital Services and Additional Services obtained
  through the Store are subject to the Usage Rules for Digital
  Goods. You understand and acknowledge that your rights with respect to
  Digital Content, Digital Services and Additional Services are limited
  by the Terms of Sale, copyright law and the Usage Rules for Digital
  Goods. Software licences purchased through the Store are subject to
  the licence agreement that accompanies the software, and you will be
  required to agree to the licence agreement before you purchase,
  download or install the software. Any reproduction or redistribution
  of Digital Content, Digital Services and Additional Services not in
  accordance with the relevant licence terms or usage rules, and
  applicable law is expressly prohibited and may result in severe
  penalties. Violators risk prosecution to the maximum extent of the
  law.

This "Usage Rules" bit sounds quite possibly not OK.  The link does not
load for me.

  Please contact Microsoft Store support if you would like a copy of the
  applicable licence agreement or warranty for boxed software, at no
  cost, before you open any software packaging.

  Other Terms and Conditions. In addition to software and other
  downloadable Products, Microsoft may offer to you other Products and
  Additional Services available in the Store, subject to separate end
  user licence agreements, terms of use, terms of service or other terms
  and conditions. If you purchase, install or use those Products or
  Additional Services, you may be required to also accept those terms as
  a condition of purchase, installation or use.



I think a big open question is if someone downloads e.g. gimp from the
MS Online Store, can they then make a copy of those bits and send them
to someone else?  Or are there technical barriers to exercising one's
rights under the Free Software license?

From lnicola at dend.ro  Wed Aug 26 06:28:08 2026
From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=)
Date: Wed, 26 Aug 2026 16:28:08 +0300
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <rmiecfluixa.fsf@s1.lexort.com>
References: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
 <rmifr031k9h.fsf@s1.lexort.com>
 <CAES-DZR+nCk_bUfMX8vTChpStw30zGUCmr2oMiBeeCcoUNgxKw@mail.gmail.com>
 <a464d273-889c-4ba9-837e-20aac8a0afd1@stripfamily.net>
 <rmio6epx13d.fsf@s1.lexort.com>
 <9b3cdbc6-07bb-423c-b375-ba0a8905edf1@stripfamily.net>
 <rmiecfluixa.fsf@s1.lexort.com>
Message-ID: <cd253f9d-ca00-4442-8d60-a26723d88329@app.fastmail.com>

Greg,

Windows makes it possible to extract and copy non-DRMed applications that you have installed. Is it easy? Maybe not, but it's comparable to copying a Linux package, and is a lot more likely to work compared to an RPM I might try to send someone. As long as Microsoft doesn't interfere with the GPL license, it's all right, even if copying the apps might require specialized tools [1]. This has been discussed before, e.g. in [2].

Laurentiu

[1]: https://learn.microsoft.com/en-us/windows/win32/appxpkg/make-appx-package--makeappx-exe-
[2]: https://jbkempf.com/blog/Windows-Store-and-the-GPL/

On Wed, Aug 26, 2026, at 16:10, Greg Troxel via QGIS-Developer wrote:
> David Strip <qgis-dev at stripfamily.net> writes:
>
>> On 8/25/2026 4:54 PM, Greg Troxel wrote:
>>
>>>  Great, the next thing to check is if the terms are actually compatible.
>>> Enough people are fuzzy on licensing and willing to break the rules
>>> because they think app stores are important, that one can't conclude
>>> it's ok.
>>
>> Usual caveat - I am not a lawyer.
>> The publisher agreement is here.
>>
>> The relevant section appears to be 3b - 
>>
>>  (b)   Third-Party Rights/Open-Source Licenses.  Your Offer and Offer Assets must not infringe or misappropriate any
>>  intellectual property or personal right of any third party. If you license any portion of your Offer from a third
>>  party or under any open-source license, you are solely responsible for compliance with such terms and for ensuring
>>  that Microsoft, in its capacity as your agent or commissionaire, has the necessary rights to perform its obligations
>>  to you under this Agreement. You are, at your sole cost and expense, responsible for securing, reporting, and
>>  maintaining all necessary rights, clearances, and consents and paying all licensing fees (including applicable public
>>  performance license fees or other consideration associated with providing music or video (and all content embodied
>>  therein) in and through your Offer), and for undertaking all related reporting obligations.
>>
>> For open source licenses, MS appears to have removed itself from the licensing pathway between the person/organization
>> submitting the product and the customer. It is thus incumbent on the submitter to provide the means for meeting the
>> license requirements, such as providing links to the license and source code. Perhaps these links could be in the listing
>> in the MS Store, or in the about screen of the app. This is already the case for the license in QGIS. 
>>
>> Obviously an actual lawyer would need to verify this interpretation. 
>
> There are two sets of terms to consider.  One is the agreement between
> the "app developer" and MS, and the other is between MS and people that
> obtain software from the store.
>
> The latter I think is at:
>   https://www.microsoft.com/en-mt/store/b/terms-of-sale
>
> which does say
>
>   12. Software Licences and Use Rights.
>
>   Software and other Digital Content, Digital Services and Additional
>   Services made available to you through the Store are licensed, not
>   sold, to you. Applications downloaded directly from the Store are
>   subject to the Standard Application Licence Terms (?SALT?) unless
>   different licence terms are provided with the application, with the
>   exception of applications downloaded from the Office Store, which are
>   not governed by the SALT and have separate license terms that are
>   provided with the application.)
>
> This is a key point and seems ok.
>
>   Digital Content and Digital Services and Additional Services obtained
>   through the Store are subject to the Usage Rules for Digital
>   Goods. You understand and acknowledge that your rights with respect to
>   Digital Content, Digital Services and Additional Services are limited
>   by the Terms of Sale, copyright law and the Usage Rules for Digital
>   Goods. Software licences purchased through the Store are subject to
>   the licence agreement that accompanies the software, and you will be
>   required to agree to the licence agreement before you purchase,
>   download or install the software. Any reproduction or redistribution
>   of Digital Content, Digital Services and Additional Services not in
>   accordance with the relevant licence terms or usage rules, and
>   applicable law is expressly prohibited and may result in severe
>   penalties. Violators risk prosecution to the maximum extent of the
>   law.
>
> This "Usage Rules" bit sounds quite possibly not OK.  The link does not
> load for me.
>
>   Please contact Microsoft Store support if you would like a copy of the
>   applicable licence agreement or warranty for boxed software, at no
>   cost, before you open any software packaging.
>
>   Other Terms and Conditions. In addition to software and other
>   downloadable Products, Microsoft may offer to you other Products and
>   Additional Services available in the Store, subject to separate end
>   user licence agreements, terms of use, terms of service or other terms
>   and conditions. If you purchase, install or use those Products or
>   Additional Services, you may be required to also accept those terms as
>   a condition of purchase, installation or use.
>
>
>
> I think a big open question is if someone downloads e.g. gimp from the
> MS Online Store, can they then make a copy of those bits and send them
> to someone else?  Or are there technical barriers to exercising one's
> rights under the Free Software license?
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

From gdt at lexort.com  Wed Aug 26 10:18:46 2026
From: gdt at lexort.com (Greg Troxel)
Date: Wed, 26 Aug 2026 13:18:46 -0400
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <cd253f9d-ca00-4442-8d60-a26723d88329@app.fastmail.com>
 (=?utf-8?Q?=22Lauren=C8=9Biu?= Nicola"'s message of "Wed, 26 Aug 2026
 16:28:08 +0300")
References: <CAENApSDbPWZOurzoKptaexKzWox_a4mCAg39iy9YAc==LCMjOQ@mail.gmail.com>
 <rmifr031k9h.fsf@s1.lexort.com>
 <CAES-DZR+nCk_bUfMX8vTChpStw30zGUCmr2oMiBeeCcoUNgxKw@mail.gmail.com>
 <a464d273-889c-4ba9-837e-20aac8a0afd1@stripfamily.net>
 <rmio6epx13d.fsf@s1.lexort.com>
 <9b3cdbc6-07bb-423c-b375-ba0a8905edf1@stripfamily.net>
 <rmiecfluixa.fsf@s1.lexort.com>
 <cd253f9d-ca00-4442-8d60-a26723d88329@app.fastmail.com>
Message-ID: <rmibjaou7ex.fsf@s1.lexort.com>

Lauren?iu Nicola <lnicola at dend.ro> writes:

> [2]: https://jbkempf.com/blog/Windows-Store-and-the-GPL/

Thanks!  That's exactly the kind of analysis I was looking for -- from a
principled Free Software supporter who is skeptical about Big Tech app
stores.

From andreas at qgis.org  Wed Aug 26 22:22:37 2026
From: andreas at qgis.org (Andreas Neumann)
Date: Thu, 27 Aug 2026 07:22:37 +0200
Subject: [QGIS-Developer] QGIS contributor meeting, Oct 7-9 in Laax
Message-ID: <CAB2Z92CmvGZjNUn_Sac1=Qauu1Ob-_H1W4C=RhvX6NCUy+Vyxg@mail.gmail.com>

Dear QGIS developers and contributors,

Time is flying and soon the QGIS international user conference, and along
with it, the QGIS contributor meeting will start.

This is a short reminder that you should check your details at
https://github.com/qgis/QGIS/wiki/29th-Contributor-Meeting-in-Switzerland

Specifically, check the dates of attendance and your T-Shirt sizes, so that
we can order T-Shirts in the right amounts and sizes - and can order
food and drinks accordingly.

We can still accommodate 5-8 contributors more than what we currently have
registered - so if you know someone who hasn't signed up yet, but might be
interested, please encourage them to come.

Looking forward to meeting you all in Laax,
Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260827/50ddc4a6/attachment.htm>

From tim at kartoza.com  Thu Aug 27 12:07:04 2026
From: tim at kartoza.com (Tim Sutton)
Date: Thu, 27 Aug 2026 20:07:04 +0100
Subject: [QGIS-Developer] Obtaining permission to approve plugins
In-Reply-To: <CAJj=OArJEA+m=LqUD2b-e8F-T+i0TDCDd2byLv5M2u4vjONbog@mail.gmail.com>
References: <CAJj=OArJEA+m=LqUD2b-e8F-T+i0TDCDd2byLv5M2u4vjONbog@mail.gmail.com>
Message-ID: <CAES-DZTwgdK2Z56M9uqHyzJDJ_bver9pxeAKqu9x7dpSLZft8w@mail.gmail.com>

Dear Axel

https://plugins.qgis.org/plugins/my

then you can find a documentation link on the left menu:

https://plugins.qgis.org/docs/approval

But reading our docs I think they fall short in explaining HOW to get
trusted user status - I will ask Lova to add notes on this when he gets
back next week and then we will revert to you.

Regards

Tim

On Wed, Aug 12, 2026 at 5:25?PM Axel H?rteborn via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi list,
>
> With the new release of the plugin package site:
> https://blog.qgis.org/2026/07/06/coming-soon-qgis-plugins-website-v4-0-0/
> it says "Plugins auto-approval will be explicit (two steps) and only
> available for users who have permission to approve plugins". Is there any
> guidance how to become a user with permission?
>
> Best regards
> Dr. Axel H?rteborn
> Maintainer of GeoDataFarm <https://plugins.qgis.org/plugins/geodatafarm/> since
> 2018
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 

Tim Sutton

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

*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/20260827/ef5abab6/attachment.htm>

From valentin.buira at gmail.com  Thu Aug 27 17:02:11 2026
From: valentin.buira at gmail.com (Valentin Buira)
Date: Fri, 28 Aug 2026 02:02:11 +0200
Subject: [QGIS-Developer] The squash, the merge,
 and the commit: What policy ?
Message-ID: <CANrSSZmoZFJUNK0hKHDOwyXAzZk15ApFLrJBkcZH-qdvpC4j9Q@mail.gmail.com>

Hi devs,

As the subject of my email suggests, I would like to open up a
discussion on our commit policy. And ultimately, how do we handle the
end of life of a PR. I think there are instances in our workflow where
there is a loss of history and information for git blame and other git
tools, because the commits that matter are buried within less
important commits.

I think the biggest culprit of noisy history in the git tree is
commits that should exist only in the span of a branch get merged into
master.
For example, imagine you are working on a feature with two commits
initially, and during review you happen to completely change the
implementation, then, after one final review you would have a local
history that looks like this:

  * Merge into master commit
   |   \
   |     * commit D fix typos, grammar, address final review
   |     |
   |     * commit C completely reworked the PR pls forget about A and B
   |     |
   |     * commit B
   |     |
   |     * commit A
   |  /
   |

On merge, commits A, B, and D get into the tree history and in the
inline git blame,  yet they don't matter for eyes outside of the local
branch.
Today, the PR description is the actual authoritative reference, and I
believe this is what should get in the history tree instead of
intermediate work commits.

* Because of this configuration, two things happen at the same time.
There is a loss of information for the git blame, overridden by the
latest meaningless commit message e.g "apply suggestion from code
review" "grammar". And at the same time, commits that are already
outdated as soon as they leave their working branch get merged into
the main branch anyway.

* Related to my previous point, git bisect to find regressions is made
more difficult because of noisy commits in-between the real changes.

* Reverting and cherry-picking a single feature is harder. When
reverting a PR, we have to revert as many commits as there were in the
original PR. The same applies to cherry picking.

* Vendor lock-in with Github. This one is adjacent to git but also
blends with it.
Currently, my workflow to understand a commit is the following : git
blame > open commit on github > click on the PR associated with the
commit to get the full picture of the changes.
So to effectively understand the history of QGIS we are effectively
dependent on github.
And I think github is becoming a liability. The uptime of github is
noticeably lower than it used to be. We are subject to any policies
they want regardless of how we feel (e.g their pro AI stance). And
more broadly github is based in the USA, which also means a lot of
uncertainty on what the current US administration could do next.
Unfortunately even switching to another git forge would make it
difficult to retrieve the history we have today embedded in github.


And now for a little anthology of commits we can find in the git tree:
git log -i -E --grep='fix (\w* )?build' --oneline | wc -l
1364 occurrences
git log -E --grep='auto sipify' --oneline  | wc -l
763
git log -i -E --grep="Apply suggestions? from (code review|@)" --oneline | wc -l
223
git log -i -E --grep="add?ress (review )?comments?" --oneline | wc -l
65
git log -i -E --grep="^fix typos?" --oneline | wc -l
387
git log -i -E --grep="make (\w* )?happy" --oneline | wc -l
47  // QGIS developers are like that, we like to make people happy


So, now that I have presented cases where I think we would benefit
from a more linear history, how do we reduce the noise to signal ratio
in our git history? I think we should tend towards atomic commits.

What is an atomic commit? Qt's wiki defines an atomic commit as a
"commit that should contain exactly one self-contained change." [0]
A self-contained change is itself not really defined in Qt's wiki, but
to me a self-contained change should provide at least:
* Buildable, and working
* All tests are passing
* Does not mix unrelated changes
The only point at which all these conditions are guaranteed to be met
would be on a squash of an approved and passing ci PR. Now I can also
see value in having multiple commits per PR, for example if in the end
you squashed your PR into two commits, i.e: one for the feature and
one for the tests that would make two atomic commits too.

In an ideal world developers would write code right on the first try
but in reality it's a much more organic process. So I would suggest
this simple policy:
* By default squash a PR before merging into master
* IF and only if the contributor specifically asks for their branch to
be merged, merge as is

And abide by a few rules like:
* Always separate refactors from features into two separate PRs. ( Yes
that would probably mean slightly more PRs from core devs, but also
smaller, easier, and faster to review  PRs)
* We could introduce a commit message guideline [0] but this is to be discussed

I think this way we could achieve a more linear, and more importantly
a more human readable history.

Any thoughts on this ? It's still early on but depending on the
outcome of the discussion I will create a QEP similar to QEP 314 but
for commit guidelines.

Cheers,
Valentin

[0] https://wiki.qt.io/Commit_Policy
[1] https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Finally here are a few references from other open source projects I
used to write this mail:  Godot, Qt, and Blender
https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#contribute-one-change-at-a-time
https://wiki.qt.io/Commit_Policy
https://developer.blender.org/docs/handbook/contributing/review_playbook/

From rykovd at gmail.com  Thu Aug 27 17:06:11 2026
From: rykovd at gmail.com (Denis Rykov)
Date: Fri, 28 Aug 2026 02:06:11 +0200
Subject: [QGIS-Developer] Advice on generating QGIS QML styles using AI
Message-ID: <CAJbvKNr2w37HFkmVmKEbF-9c7L_ruzMTzZvwcOYudYOR1GcFdw@mail.gmail.com>

Hi,

I?m currently exploring how to use an LLM/AI to generate valid QGIS .qml
styles from natural-language prompts. One difficulty I?ve encountered is
that, as far as I know, there is no formal or exhaustive schema for the QML
format describing both the XML hierarchy and the semantics of all elements,
attributes, renderers, symbol layers, labeling settings, etc. I?m currently
investigating whether PyQGIS can be used to discover this information
programmatically. I can create QGIS objects, serialize them using QGIS
itself, and recursively inspect the resulting DOM. This provides
information about the actual XML hierarchy, attributes, default values, and
property definitions. Before going further, however, I wanted to ask the
QGIS developers whether there is a more canonical approach.

In particular:

   1. Is there an existing source of truth for the QML structure/schema
   that I may have missed?
   2. Is the QML format intentionally undocumented/non-schema-based, with
   the QGIS C++ serialization code effectively serving as the authoritative
   specification?
   3. Would using PyQGIS to instantiate the different renderers, symbol
   layers, labeling configurations, etc., and then inspecting their
   QDomDocument serialization be a reasonable way to generate a
   machine-readable schema?
   4. Are there particular QGIS APIs or parts of the source tree that you
   would recommend for this purpose?

I?d appreciate any advice on whether this is the right direction, or
whether there is a more appropriate way to obtain or generate such a schema
from QGIS itself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260828/f00af794/attachment.htm>

From nyall.dawson at gmail.com  Thu Aug 27 17:17:06 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 28 Aug 2026 10:17:06 +1000
Subject: [QGIS-Developer] Advice on generating QGIS QML styles using AI
In-Reply-To: <CAJbvKNr2w37HFkmVmKEbF-9c7L_ruzMTzZvwcOYudYOR1GcFdw@mail.gmail.com>
References: <CAJbvKNr2w37HFkmVmKEbF-9c7L_ruzMTzZvwcOYudYOR1GcFdw@mail.gmail.com>
Message-ID: <CAB28AsijVuv=5dxLiLK_m46dM=jOznoVoAe7sJ6vTAOLMWSRyA@mail.gmail.com>

On Fri, 28 Aug 2026 at 10:06, Denis Rykov via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
> Hi,
>
> I?m currently exploring how to use an LLM/AI to generate valid QGIS .qml styles from natural-language prompts. One difficulty I?ve encountered is that, as far as I know, there is no formal or exhaustive schema for the QML format describing both the XML hierarchy and the semantics of all elements, attributes, renderers, symbol layers, labeling settings, etc. I?m currently investigating whether PyQGIS can be used to discover this information programmatically. I can create QGIS objects, serialize them using QGIS itself, and recursively inspect the resulting DOM. This provides information about the actual XML hierarchy, attributes, default values, and property definitions. Before going further, however, I wanted to ask the QGIS developers whether there is a more canonical approach.
>
> In particular:
>
> Is there an existing source of truth for the QML structure/schema that I may have missed?

No -- it's considered an internal private detail only, and changes
many times throughout the release cycle (while maintaining
compatibility with existing QML files!).

> Is the QML format intentionally undocumented/non-schema-based,

Yes

> with the QGIS C++ serialization code effectively serving as the authoritative specification?

Kind of -- but again, it's intentionally NOT a fixed specification at
all, but just a reflection of what QGIS internal classes need to store
for any particular release.

> Would using PyQGIS to instantiate the different renderers, symbol layers, labeling configurations, etc., and then inspecting their QDomDocument serialization be a reasonable way to generate a machine-readable schema?

Possibly, yes, if you're just interested in generating XML that QGIS
will consume. If you're attempting to READ xml that qgis produces then
the recommended approach is always to just use QGIS api directly to
read this, and then extract properties from the resulting symbols
using the stable API.

Nyall

> Are there particular QGIS APIs or parts of the source tree that you would recommend for this purpose?
>
> I?d appreciate any advice on whether this is the right direction, or whether there is a more appropriate way to obtain or generate such a schema from QGIS itself.
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

From nyall.dawson at gmail.com  Thu Aug 27 17:20:12 2026
From: nyall.dawson at gmail.com (Nyall Dawson)
Date: Fri, 28 Aug 2026 10:20:12 +1000
Subject: [QGIS-Developer] The squash, the merge,
 and the commit: What policy ?
In-Reply-To: <CANrSSZmoZFJUNK0hKHDOwyXAzZk15ApFLrJBkcZH-qdvpC4j9Q@mail.gmail.com>
References: <CANrSSZmoZFJUNK0hKHDOwyXAzZk15ApFLrJBkcZH-qdvpC4j9Q@mail.gmail.com>
Message-ID: <CAB28AsgdJVYJQ08ExHHaHQjHAmYCZ8-OuZBJXZwuVAXLxAQjzA@mail.gmail.com>

On Fri, 28 Aug 2026 at 10:03, Valentin Buira via QGIS-Developer
<qgis-developer at lists.osgeo.org> wrote:
>
>
> In an ideal world developers would write code right on the first try
> but in reality it's a much more organic process. So I would suggest
> this simple policy:
> * By default squash a PR before merging into master
> * IF and only if the contributor specifically asks for their branch to
> be merged, merge as is

I'd also add to this that merge commits are prohibited (using rebase instead).

Otherwise +1 to everything you've said.

Nyall

From david at opengis.ch  Fri Aug 28 00:04:59 2026
From: david at opengis.ch (David Signer)
Date: Fri, 28 Aug 2026 09:04:59 +0200
Subject: [QGIS-Developer] The squash, the merge,
 and the commit: What policy ?
In-Reply-To: <CANrSSZmoZFJUNK0hKHDOwyXAzZk15ApFLrJBkcZH-qdvpC4j9Q@mail.gmail.com>
References: <CANrSSZmoZFJUNK0hKHDOwyXAzZk15ApFLrJBkcZH-qdvpC4j9Q@mail.gmail.com>
Message-ID: <CAETFtHn=OyrDrDMMs2EVGGHVqwqurCUbQ6v_w5JQBV629YHtFg@mail.gmail.com>

Thanks Valentin.

Sounds all good to me. As long as there is the exception you mentioned
where a contributor can organize multiple (few) atomic commits in the same
PR and merge them as they are.

Cheers
Dave

On Fri, Aug 28, 2026 at 2:02?AM Valentin Buira via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> Hi devs,
>
> As the subject of my email suggests, I would like to open up a
> discussion on our commit policy. And ultimately, how do we handle the
> end of life of a PR. I think there are instances in our workflow where
> there is a loss of history and information for git blame and other git
> tools, because the commits that matter are buried within less
> important commits.
>
> I think the biggest culprit of noisy history in the git tree is
> commits that should exist only in the span of a branch get merged into
> master.
> For example, imagine you are working on a feature with two commits
> initially, and during review you happen to completely change the
> implementation, then, after one final review you would have a local
> history that looks like this:
>
>   * Merge into master commit
>    |   \
>    |     * commit D fix typos, grammar, address final review
>    |     |
>    |     * commit C completely reworked the PR pls forget about A and B
>    |     |
>    |     * commit B
>    |     |
>    |     * commit A
>    |  /
>    |
>
> On merge, commits A, B, and D get into the tree history and in the
> inline git blame,  yet they don't matter for eyes outside of the local
> branch.
> Today, the PR description is the actual authoritative reference, and I
> believe this is what should get in the history tree instead of
> intermediate work commits.
>
> * Because of this configuration, two things happen at the same time.
> There is a loss of information for the git blame, overridden by the
> latest meaningless commit message e.g "apply suggestion from code
> review" "grammar". And at the same time, commits that are already
> outdated as soon as they leave their working branch get merged into
> the main branch anyway.
>
> * Related to my previous point, git bisect to find regressions is made
> more difficult because of noisy commits in-between the real changes.
>
> * Reverting and cherry-picking a single feature is harder. When
> reverting a PR, we have to revert as many commits as there were in the
> original PR. The same applies to cherry picking.
>
> * Vendor lock-in with Github. This one is adjacent to git but also
> blends with it.
> Currently, my workflow to understand a commit is the following : git
> blame > open commit on github > click on the PR associated with the
> commit to get the full picture of the changes.
> So to effectively understand the history of QGIS we are effectively
> dependent on github.
> And I think github is becoming a liability. The uptime of github is
> noticeably lower than it used to be. We are subject to any policies
> they want regardless of how we feel (e.g their pro AI stance). And
> more broadly github is based in the USA, which also means a lot of
> uncertainty on what the current US administration could do next.
> Unfortunately even switching to another git forge would make it
> difficult to retrieve the history we have today embedded in github.
>
>
> And now for a little anthology of commits we can find in the git tree:
> git log -i -E --grep='fix (\w* )?build' --oneline | wc -l
> 1364 occurrences
> git log -E --grep='auto sipify' --oneline  | wc -l
> 763
> git log -i -E --grep="Apply suggestions? from (code review|@)" --oneline |
> wc -l
> 223
> git log -i -E --grep="add?ress (review )?comments?" --oneline | wc -l
> 65
> git log -i -E --grep="^fix typos?" --oneline | wc -l
> 387
> git log -i -E --grep="make (\w* )?happy" --oneline | wc -l
> 47  // QGIS developers are like that, we like to make people happy
>
>
> So, now that I have presented cases where I think we would benefit
> from a more linear history, how do we reduce the noise to signal ratio
> in our git history? I think we should tend towards atomic commits.
>
> What is an atomic commit? Qt's wiki defines an atomic commit as a
> "commit that should contain exactly one self-contained change." [0]
> A self-contained change is itself not really defined in Qt's wiki, but
> to me a self-contained change should provide at least:
> * Buildable, and working
> * All tests are passing
> * Does not mix unrelated changes
> The only point at which all these conditions are guaranteed to be met
> would be on a squash of an approved and passing ci PR. Now I can also
> see value in having multiple commits per PR, for example if in the end
> you squashed your PR into two commits, i.e: one for the feature and
> one for the tests that would make two atomic commits too.
>
> In an ideal world developers would write code right on the first try
> but in reality it's a much more organic process. So I would suggest
> this simple policy:
> * By default squash a PR before merging into master
> * IF and only if the contributor specifically asks for their branch to
> be merged, merge as is
>
> And abide by a few rules like:
> * Always separate refactors from features into two separate PRs. ( Yes
> that would probably mean slightly more PRs from core devs, but also
> smaller, easier, and faster to review  PRs)
> * We could introduce a commit message guideline [0] but this is to be
> discussed
>
> I think this way we could achieve a more linear, and more importantly
> a more human readable history.
>
> Any thoughts on this ? It's still early on but depending on the
> outcome of the discussion I will create a QEP similar to QEP 314 but
> for commit guidelines.
>
> Cheers,
> Valentin
>
> [0] https://wiki.qt.io/Commit_Policy
> [1] https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
>
> Finally here are a few references from other open source projects I
> used to write this mail:  Godot, Qt, and Blender
>
> https://contributing.godotengine.org/en/latest/pull_requests/pull_request_guidelines.html#contribute-one-change-at-a-time
> https://wiki.qt.io/Commit_Policy
> https://developer.blender.org/docs/handbook/contributing/review_playbook/
> _______________________________________________
> 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/20260828/e5c966a2/attachment-0001.htm>

From yawmensah3310 at gmail.com  Fri Aug 28 00:57:58 2026
From: yawmensah3310 at gmail.com (Yaw Mensah)
Date: Fri, 28 Aug 2026 03:57:58 -0400
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <mailman.28251.1787717774.622.qgis-developer@lists.osgeo.org>
References: <mailman.28251.1787717774.622.qgis-developer@lists.osgeo.org>
Message-ID: <CAENApSCpDFzchtD5vuoOaxqW6ApcqUL-b5iZZ9Nn1EG+rSJ6Sw@mail.gmail.com>

Hi all,
Thanks Tim for raising this with the PSC, and David for finding that clause
in the publisher agreement.

On Greg's redistribution question: I looked at the default Microsoft Store
app license terms, and by default they don't allow users to make copies or
republish the app for others, which would conflict with the GPL. David's
find in section 3(b) suggests publishers can attach their own license terms
instead of the default ones, so that may be a way around it. This
definitely needs a lawyer to confirm before anyone relies on it.

On my end, I'd just like to help with the packaging and testing side of
things to get QGIS distributed through the Microsoft Store,as well as the
submission process.

I'm happy to help with investigating the MSIX/Store packaging requirements,
testing the resulting package, and working through any Windows-specific
issues that may come up.

If the licensing questions are considered sufficiently addressed by the PSC
and the others, I'd be interested to hear what the next steps would be for
evaluating a QGIS Store package.

Thanks,
Yaw.

On Wed, 26 Aug 2026 at 00:16, <qgis-developer-request at lists.osgeo.org>
wrote:

> Send QGIS-Developer mailing list submissions to
>         qgis-developer at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.osgeo.org/mailman/listinfo/qgis-developer
> or, via email, send a message with subject or body 'help' to
>         qgis-developer-request at lists.osgeo.org
>
> You can reach the person managing the list at
>         qgis-developer-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of QGIS-Developer digest..."
> Today's Topics:
>
>    1. Microsoft Store distribution for QGIS (Yaw Mensah)
>    2. Re: Microsoft Store distribution for QGIS (Greg Troxel)
>    3. Re: [Qgis-psc] Next 4.x LTR (Nyall Dawson)
>    4. Re: Microsoft Store distribution for QGIS (Tim Sutton)
>    5. Re: Microsoft Store distribution for QGIS (Greg Troxel)
>    6. Re: Microsoft Store distribution for QGIS (David Strip)
>
>
>
> ---------- Forwarded message ----------
> From: Yaw Mensah <yawmensah3310 at gmail.com>
> To: qgis-developer at lists.osgeo.org
> Cc:
> Bcc:
> Date: Mon, 24 Aug 2026 09:42:12 -0400
> Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
>
> Hi,
>
> I was wondering whether distributing QGIS Desktop through the Microsoft
> Store has been considered before.
>
> I have some experience packaging and publishing Windows applications
> through the Microsoft Store and would be interested in helping investigate
> this as an additional distribution option for QGIS.
>
> Before I start experimenting with a package, I wanted to ask whether there
> are known blockers or project concerns around this, particularly regarding
> dependencies, signing, updates, or maintaining an additional distribution
> channel.
>
> If this is something the project would be open to exploring, I'd be happy
> to investigate the packaging requirements and contribute a proof of concept.
>
> Thanks,
> Yaw
>
>
>
> ---------- Forwarded message ----------
> From: Greg Troxel <gdt at lexort.com>
> To: Yaw Mensah via QGIS-Developer <qgis-developer at lists.osgeo.org>
> Cc:
> Bcc:
> Date: Mon, 24 Aug 2026 13:49:30 -0400
> Subject: Re: [QGIS-Developer] Microsoft Store distribution for QGIS
> Yaw Mensah via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:
>
> > I was wondering whether distributing QGIS Desktop through the Microsoft
> > Store has been considered before.
> >
> > I have some experience packaging and publishing Windows applications
> > through the Microsoft Store and would be interested in helping
> investigate
> > this as an additional distribution option for QGIS.
> >
> > Before I start experimenting with a package, I wanted to ask whether
> there
> > are known blockers or project concerns around this, particularly
> regarding
> > dependencies, signing, updates, or maintaining an additional distribution
> > channel.
>
> Can you explain how the IP terms work?  When people get binaries
> through the store, are they able to redisribute them to other people?
>   - Do they have the technical ability to copy?
>   - Is there anything in the MS Store terms that prohibit such copying?
>
> I have no idea what the answers are here, but I think it's always an
> important question when considering distribution methods.
>
> (That's all assuming that qgis continues to be licensed under GPL2!)
>
>
>
>
> ---------- Forwarded message ----------
> From: Nyall Dawson <nyall.dawson at gmail.com>
> To: "J?rgen E. Fischer" <jef at norbit.de>, qgis-developer at lists.osgeo.org,
> QGIS PSC <qgis-psc at lists.osgeo.org>
> Cc:
> Bcc:
> Date: Tue, 25 Aug 2026 10:26:09 +1000
> Subject: Re: [QGIS-Developer] [Qgis-psc] Next 4.x LTR
> On Mon, 24 Aug 2026 at 23:15, J?rgen E. Fischer via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
> >
> > Hi Nyall,
> >
> > On Fri, 21. Aug 2026 at 11:54:28 +1000, Nyall Dawson via QGIS-Developer
> wrote:
> > > I don't think we're there yet for 4.2. 3.44 is a VERY solid release,
> > > and I think we'd be doing our enterprise users a disservice by
> > > officially promoting the idea that 4.4 is just as stable.
> >
> > So your suggestion is to removed the ltr-4_2 tag and continue 3.44 as
> LTR for
> > the forseeable future until there is a 4.x release that is close to the
> > stability of 3.44?
>
> That's my feeling.
>
> (I mean -- try opening a layout, selecting two items, and group ...
> *CRASH*. This is the kind of fundamental issue I'm referring to when I
> say 4.2 isn't a match for 3.44 for stability).
>
> Nyall
>
>
> >
> >
> > J?rgen
> >
> > --
> > J?rgen E. Fischer           norBIT GmbH             Tel.
> +49-4931-918175-31
> > Dipl.-Inf. (FH)             Rheinstra?e 13          Fax.
> +49-4931-918175-50
> > Software Engineer           D-26506 Norden
> https://www.norbit.de
> > QGIS release manager (PSC)  Germany                  Matrix: @jef:
> osgeo.org
> > _______________________________________________
> > QGIS-Developer mailing list
> > QGIS-Developer at lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
>
> ---------- Forwarded message ----------
> From: Tim Sutton <tim at kartoza.com>
> To: Greg Troxel <gdt at lexort.com>
> Cc: Yaw Mensah via QGIS-Developer <qgis-developer at lists.osgeo.org>
> Bcc:
> Date: Tue, 25 Aug 2026 22:15:19 +0100
> Subject: Re: [QGIS-Developer] Microsoft Store distribution for QGIS
> Hi Yaw
>
> Yes this is something we discuss occassionally - I think GIMP and / or
> Inkscape are in the MS store too if I am not mistaken? I am going to add it
> to the PSC meeting agenda again for next weeks call where we can discuss it
> further and get back to you.
>
> Regards
>
> Tim
>
>
>
> On Mon, Aug 24, 2026 at 6:49?PM Greg Troxel via QGIS-Developer <
> qgis-developer at lists.osgeo.org> wrote:
>
>> Yaw Mensah via QGIS-Developer <qgis-developer at lists.osgeo.org> writes:
>>
>> > I was wondering whether distributing QGIS Desktop through the Microsoft
>> > Store has been considered before.
>> >
>> > I have some experience packaging and publishing Windows applications
>> > through the Microsoft Store and would be interested in helping
>> investigate
>> > this as an additional distribution option for QGIS.
>> >
>> > Before I start experimenting with a package, I wanted to ask whether
>> there
>> > are known blockers or project concerns around this, particularly
>> regarding
>> > dependencies, signing, updates, or maintaining an additional
>> distribution
>> > channel.
>>
>> Can you explain how the IP terms work?  When people get binaries
>> through the store, are they able to redisribute them to other people?
>>   - Do they have the technical ability to copy?
>>   - Is there anything in the MS Store terms that prohibit such copying?
>>
>> I have no idea what the answers are here, but I think it's always an
>> important question when considering distribution methods.
>>
>> (That's all assuming that qgis continues to be licensed under GPL2!)
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> --
>
> Tim Sutton
>
> *Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee
>
> *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.*
>
>
>
> ---------- Forwarded message ----------
> From: Greg Troxel <gdt at lexort.com>
> To: David Strip <qgis-user at stripfamily.net>
> Cc: Tim Sutton <tim at kartoza.com>, Yaw Mensah via QGIS-Developer <
> qgis-developer at lists.osgeo.org>
> Bcc:
> Date: Tue, 25 Aug 2026 18:54:46 -0400
> Subject: Re: [QGIS-Developer] Microsoft Store distribution for QGIS
> David Strip <qgis-user at stripfamily.net> writes:
>
> > On 8/25/2026 3:15 PM, Tim Sutton via QGIS-Developer wrote:
> >
> >  Hi Yaw
> >
> >  Yes this is something we discuss occassionally - I think GIMP and / or
> Inkscape are in the MS store too if I am not
> >  mistaken? I am going to add it to the PSC meeting agenda again for next
> weeks call where we can discuss it further
> >  and get back to you.
> >
> > I checked - yes, GIMP and Inkscape are in the store. QField is there too
> and lists the license as GPLv2 or later.
>
> Great, the next thing to check is if the terms are actually compatible.
> Enough people are fuzzy on licensing and willing to break the rules
> because they think app stores are important, that one can't conclude
> it's ok.
>
> For example, QField is in the apple app store, and that prohibits
> distirbuting the app you receive.  That's outright incompatible with the
> GPL, and QGIS does not have an apple exception.  I've raised this issue,
> but I haven't seen any substantive comments addresssing it.  (I think
> it's good there is no apple exception; the Free Software community
> shouldn't have to break their own rules to accomodate Apple's choices to
> be difficult about Free Software.)
>
>
>
>
> ---------- Forwarded message ----------
> From: David Strip <qgis-dev at stripfamily.net>
> To: Greg Troxel <gdt at lexort.com>
> Cc: Tim Sutton <tim at kartoza.com>, Yaw Mensah via QGIS-Developer <
> qgis-developer at lists.osgeo.org>
> Bcc:
> Date: Tue, 25 Aug 2026 22:10:54 -0600
> Subject: Re: [QGIS-Developer] Microsoft Store distribution for QGIS
> On 8/25/2026 4:54 PM, Greg Troxel wrote:
>
> Great, the next thing to check is if the terms are actually compatible.
> Enough people are fuzzy on licensing and willing to break the rules
> because they think app stores are important, that one can't conclude
> it's ok.
>
>
> Usual caveat - I am not a lawyer.
> The publisher agreement is here
> <https://learn.microsoft.com/en-us/legal/marketplace/msft-publisher-agreement>
> .
>
> The relevant section appears to be 3b -
>
> *(b)*   *Third-Party Rights/Open-Source Licenses*.  Your Offer and Offer
> Assets must not infringe or misappropriate any intellectual property or
> personal right of any third party. If you license any portion of your Offer
> from a third party or under any open-source license, you are solely
> responsible for compliance with such terms and for ensuring that Microsoft,
> in its capacity as your agent or commissionaire, has the necessary rights
> to perform its obligations to you under this Agreement. You are, at your
> sole cost and expense, responsible for securing, reporting, and maintaining
> all necessary rights, clearances, and consents and paying all licensing
> fees (including applicable public performance license fees or other
> consideration associated with providing music or video (and all content
> embodied therein) in and through your Offer), and for undertaking all
> related reporting obligations.
>
> For open source licenses, MS appears to have removed itself from the
> licensing pathway between the person/organization submitting the product
> and the customer. It is thus incumbent on the submitter to provide the
> means for meeting the license requirements, such as providing links to the
> license and source code. Perhaps these links could be in the listing in the
> MS Store, or in the about screen of the app. This is already the case for
> the license in QGIS.
>
> Obviously an actual lawyer would need to verify this interpretation.
>
> _______________________________________________
> 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/20260828/0a5b7b12/attachment-0001.htm>

From jef at norbit.de  Fri Aug 28 01:45:36 2026
From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer)
Date: Fri, 28 Aug 2026 10:45:36 +0200
Subject: [QGIS-Developer] Microsoft Store distribution for QGIS
In-Reply-To: <CAENApSCpDFzchtD5vuoOaxqW6ApcqUL-b5iZZ9Nn1EG+rSJ6Sw@mail.gmail.com>
References: <mailman.28251.1787717774.622.qgis-developer@lists.osgeo.org>
 <CAENApSCpDFzchtD5vuoOaxqW6ApcqUL-b5iZZ9Nn1EG+rSJ6Sw@mail.gmail.com>
Message-ID: <20260828084535.zwjskuzr5o5oaubp@norbit.de>

Hi Yaw,

On Fri, 28. Aug 2026 at 03:57:58 -0400, Yaw Mensah wrote:
> I'm happy to help with investigating the MSIX/Store packaging requirements,
> testing the resulting package, and working through any Windows-specific
> issues that may come up.

The msis are made from osgeo4w packages.

https://github.com/jef-n/OSGeo4W/blob/master/scripts/createmsi.pl


J?rgen

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

From gdt at lexort.com  Fri Aug 28 06:00:58 2026
From: gdt at lexort.com (Greg Troxel)
Date: Fri, 28 Aug 2026 09:00:58 -0400
Subject: [QGIS-Developer] The squash, the merge,
 and the commit: What policy ?
In-Reply-To: <CANrSSZmoZFJUNK0hKHDOwyXAzZk15ApFLrJBkcZH-qdvpC4j9Q@mail.gmail.com>
 (Valentin Buira via's message of "Fri, 28 Aug 2026 02:02:11 +0200")
References: <CANrSSZmoZFJUNK0hKHDOwyXAzZk15ApFLrJBkcZH-qdvpC4j9Q@mail.gmail.com>
Message-ID: <rmifqzyo0vp.fsf@s1.lexort.com>

Valentin Buira via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> So, now that I have presented cases where I think we would benefit
> from a more linear history, how do we reduce the noise to signal ratio
> in our git history? I think we should tend towards atomic commits.

I agree, but linear and atomic are separable concerns.

Long ago I ran a (non-open-source, at work) project and what we evolved
was:

  - branch must be a logical feature
  - each commit must be self contained (your "logical change")
  - when changes are needed to any of the commits, we use --fixup= to
    mark them and then rebase -i

So of course it's messy on the branch, and then with the rebase we
construct the branch as if the final state was intended and produced
from the beginning.

Then, we use a merge commit to bring these in, with the first parent the
previous commit on master, and the 2nd parent the commits on the branch.
The branch commits' first parent chain will also go back to that
previous commit on master.

So it's not really linear, but it's close.  The point of the merge
commit is that the commits (which might be one) on the branch are
attributed to the authors who created them, and the merge commit is
attributed to the person who authorized the branch to be merged.  That
merge commit also has "Fixes #123." as appropriate.

Part of our practice, different from most open source projects, was that
before the final merge we expected the rebase cleanup and a fresh test
run (thus tests passing on this minute's master plus the branch).  A
branch off master from a month ago might still have no merge conflicts,
but the test result is not valid.  This kind of non-linear history is
not only confusing but actually problematic.

Having used this workflow, I really like it.  I find that in open
source, asking contributors to clean up their branches doesn't go so
well.

This is a somewhat long way of strongly agreeing with your core point of
not having messy branches, but pointing out that strict linear (not
having merges at all) and squashing are not necessary for clarity.

From tim at kartoza.com  Fri Aug 28 14:36:51 2026
From: tim at kartoza.com (Tim Sutton)
Date: Fri, 28 Aug 2026 22:36:51 +0100
Subject: [QGIS-Developer] Advice on generating QGIS QML styles using AI
In-Reply-To: <CAB28AsijVuv=5dxLiLK_m46dM=jOznoVoAe7sJ6vTAOLMWSRyA@mail.gmail.com>
References: <CAJbvKNr2w37HFkmVmKEbF-9c7L_ruzMTzZvwcOYudYOR1GcFdw@mail.gmail.com>
 <CAB28AsijVuv=5dxLiLK_m46dM=jOznoVoAe7sJ6vTAOLMWSRyA@mail.gmail.com>
Message-ID: <CAES-DZRyCkk1Gg6vaKL++OHem961_uvo8fFSREgPYCeoBFHh_w@mail.gmail.com>

Hi Denis

You may also want to take a peek at the GeoStyler (https://geostyler.org/)
project which attempts to be a babel fish for different style formats,
including QGIS QML. I am guessing they have some kind of conceptual
mapping, at least between the shared concepts within the various formats
they support.

Regards,

Tim

On Fri, Aug 28, 2026 at 1:17?AM Nyall Dawson via QGIS-Developer <
qgis-developer at lists.osgeo.org> wrote:

> On Fri, 28 Aug 2026 at 10:06, Denis Rykov via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
> >
> > Hi,
> >
> > I?m currently exploring how to use an LLM/AI to generate valid QGIS .qml
> styles from natural-language prompts. One difficulty I?ve encountered is
> that, as far as I know, there is no formal or exhaustive schema for the QML
> format describing both the XML hierarchy and the semantics of all elements,
> attributes, renderers, symbol layers, labeling settings, etc. I?m currently
> investigating whether PyQGIS can be used to discover this information
> programmatically. I can create QGIS objects, serialize them using QGIS
> itself, and recursively inspect the resulting DOM. This provides
> information about the actual XML hierarchy, attributes, default values, and
> property definitions. Before going further, however, I wanted to ask the
> QGIS developers whether there is a more canonical approach.
> >
> > In particular:
> >
> > Is there an existing source of truth for the QML structure/schema that I
> may have missed?
>
> No -- it's considered an internal private detail only, and changes
> many times throughout the release cycle (while maintaining
> compatibility with existing QML files!).
>
> > Is the QML format intentionally undocumented/non-schema-based,
>
> Yes
>
> > with the QGIS C++ serialization code effectively serving as the
> authoritative specification?
>
> Kind of -- but again, it's intentionally NOT a fixed specification at
> all, but just a reflection of what QGIS internal classes need to store
> for any particular release.
>
> > Would using PyQGIS to instantiate the different renderers, symbol
> layers, labeling configurations, etc., and then inspecting their
> QDomDocument serialization be a reasonable way to generate a
> machine-readable schema?
>
> Possibly, yes, if you're just interested in generating XML that QGIS
> will consume. If you're attempting to READ xml that qgis produces then
> the recommended approach is always to just use QGIS api directly to
> read this, and then extract properties from the resulting symbols
> using the stable API.
>
> Nyall
>
> > Are there particular QGIS APIs or parts of the source tree that you
> would recommend for this purpose?
> >
> > I?d appreciate any advice on whether this is the right direction, or
> whether there is a more appropriate way to obtain or generate such a schema
> from QGIS itself.
> > _______________________________________________
> > 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
>


-- 

Tim Sutton

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

*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/20260828/1607fd4f/attachment.htm>