From nyall.dawson at gmail.com Sun Feb 1 14:13:57 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Mon, 2 Feb 2026 08:13:57 +1000 Subject: [QGIS-Developer] bugprone-branch-clone false positives Message-ID: Hi list, Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? Is there ANY value in this particular check? Or should we just disable it? It seems completely broken to me[1]. Nyall [1] I searched upstream for bug reports and can't find anyone else having this issue. The closest I can find is possibly https://github.com/llvm/llvm-project/issues/67662 -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Mon Feb 2 01:02:56 2026 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Mon, 02 Feb 2026 10:02:56 +0100 Subject: [QGIS-Developer] bugprone-branch-clone false positives In-Reply-To: (Nyall Dawson via's message of "Mon, 2 Feb 2026 08:13:57 +1000") References: Message-ID: <87ecn3a56n.fsf@julienlaptop.home> Hi, > Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? Yes, I was close to disable it recently. I searched a little bit to better understand what was going on and my conclusion is that there are several issues since clang 19 (missing includes are one, but it doesn't behave well with some Qt type, like if we replace a QVector with a std::vector, the issue suddenly disappear). So, I'm in favor of removing it. Regards, Julien > Hi list, > > Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? > > Is there ANY value in this particular check? Or should we just disable it? It seems completely broken to me[1]. > > Nyall > > [1] I searched upstream for bug reports and can't find anyone else having this issue. The closest I can find is possibly > https://github.com/llvm/llvm-project/issues/67662 > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From julien.cabieces at oslandia.com Mon Feb 2 02:21:58 2026 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Mon, 02 Feb 2026 11:21:58 +0100 Subject: [QGIS-Developer] bugprone-branch-clone false positives In-Reply-To: <87ecn3a56n.fsf@julienlaptop.home> (Julien Cabieces via's message of "Mon, 02 Feb 2026 10:02:56 +0100") References: <87ecn3a56n.fsf@julienlaptop.home> Message-ID: <875x8fa1ix.fsf@julienlaptop.home> Just a precision, I think there are way more issues after clang 19, since clang 20. I'm using clang 19 on my machine and I don't get any of the false positives that I get in the CI. Anyway, it doesn't change the conclusion. > Hi, > >> Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? > > Yes, I was close to disable it recently. > > I searched a little bit to better understand what was going on and my > conclusion is that there are several issues since clang 19 (missing > includes are one, but it doesn't behave well with some Qt type, like if > we replace a QVector with a std::vector, the issue suddenly disappear). > > So, I'm in favor of removing it. > > Regards, > Julien > >> Hi list, >> >> Is anyone else annoyed by the number of (very clearly wrong) false positives that the bugprone-branch-clone lint check is giving on CI? >> >> Is there ANY value in this particular check? Or should we just disable it? It seems completely broken to me[1]. >> >> Nyall >> >> [1] I searched upstream for bug reports and can't find anyone else having this issue. The closest I can find is possibly >> https://github.com/llvm/llvm-project/issues/67662 >> >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From apasotti at gmail.com Mon Feb 2 05:29:42 2026 From: apasotti at gmail.com (Alessandro Pasotti) Date: Mon, 2 Feb 2026 14:29:42 +0100 Subject: [QGIS-Developer] Gentle reminder: assign tickets to yourself when working on them Message-ID: Dear fellow developers, In order to avoid duplication of efforts and waste of your precious time, please remember to assign the tickets to yourself when working on them. Happy bugfixing! -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it From wonder.sk at gmail.com Wed Feb 4 13:17:20 2026 From: wonder.sk at gmail.com (Martin Dobias) Date: Wed, 4 Feb 2026 22:17:20 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? Message-ID: Hi all As you know, 3D map views in QGIS are based on the Qt 3D module. Since Qt 6.8 (released in Oct 2024) the Qt 3D module is marked as deprecated [1]. This does not mean that it will be removed anytime soon, but there's no development planned by the Qt company. There has been very little development in Qt 3D in recent years and little adoption within wider Qt community. A question naturally comes up - what should we do within the QGIS project? Stay with Qt 3D or start moving towards something else? At Lutra, we have started some internal discussions about this. Qt 3D does its job, but we find it often over-complicated (e.g. framegraph, entity-component-system scene representation) and under-documented. And with the lack of direct access to graphics APIs we have accumulated various workarounds and bugs that are difficult to fix. If we wanted to switch to something else, there are lots of options: from the very low-level wrappers around graphics APIs all the way to full blown 3D rendering engines for games. At this point, QRhi [2] looks like an interesting option. QRhi is a part of Qt GUI module and it is a relatively low-level abstraction on top of modern graphics APIs (Metal, Vulkan, Direct3D). It is already being used under the hood by Qt Quick and Qt Quick 3D (and optionally also by Qt 3D). It is kind of semi-private API of Qt GUI module, but it is well documented and the API has been quite stable despite the lack of source/binary compatibility guarantees. With a low-level approach like QRhi we would get a lot of control, at the expense of having to roll out our own abstractions that Qt 3D provides (e.g. camera, geometry, material, scene graph). I would love to hear some thoughts from other QGIS devs about the possible migration away from Qt 3D. If there will be consensus, we can then start working on a QEP and prepare a more detailed plan. Regards Martin [1] https://doc.qt.io/qt-6/whatsnew68.html [2] https://doc.qt.io/qt-6/qrhi.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet.duman at tubitak.gov.tr Wed Feb 4 13:15:29 2026 From: mehmet.duman at tubitak.gov.tr (Mehmet DUMAN (UZAY)) Date: Thu, 5 Feb 2026 00:15:29 +0300 (TRT) Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W Message-ID: <1880612133.1704649.1770239729803.JavaMail.zimbra@tubitak.gov.tr> Hello QGIS developers, ? I am building QGIS 3.40 (ltr) from source on Windows using the OSGeo4W development environment and Visual Studio 2022, and I am encountering a build failure in the "synccrsdb" target. ? Environment ? - QGIS: 3.40 (source build) - OS: Windows x64 - Compiler: Visual Studio 2022 - Build system: CMake (MSVC generator) ? OSGeo4W packages installed ? Main development meta-package: ? qgis-ltr-deps ? Relevant dependency versions: ? proj-runtime: 9.7.1 proj-data: 1.24 ? Error ? The build fails while running "crssync.exe": ? Operation needs translation in QgsCoordinateReferenceSystemUtils::translateProjection: spilhaus aborted ? Visual Studio reports: ? synccrsdb.vcxproj custom build exited with code -1073740791 ? Question ? Is QGIS 3.40 expected to build correctly with PROJ 9.7.x, or is there a recommended PROJ version range for this release when using OSGeo4W? ? Should the qgis-ltr-deps package alone be sufficient to build the QGIS LTR source on Windows? If not, what is the recommended dependency set or workflow for building the LTR branch with OSGeo4W? ? ? ? Best regards, Mehmet Duman R&D Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Wed Feb 4 14:04:29 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 04 Feb 2026 17:04:29 -0500 Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W In-Reply-To: <1880612133.1704649.1770239729803.JavaMail.zimbra@tubitak.gov.tr> (Mehmet DUMAN via's message of "Thu, 5 Feb 2026 00:15:29 +0300 (TRT)") References: <1880612133.1704649.1770239729803.JavaMail.zimbra@tubitak.gov.tr> Message-ID: "Mehmet DUMAN (UZAY) via QGIS-Developer" writes: > The build fails while running "crssync.exe": > ? > Operation needs translation in QgsCoordinateReferenceSystemUtils::translateProjection: spilhaus I ran into this a year ago. The problem is that qgis needs a table of all projections. This message should be a big hint. Realize that it's a diff for a packaging system and thus there is the confusing presentation of adding a patch that changes qgis, with nested patch quoting! https://mail-index.netbsd.org/pkgsrc-changes/2025/05/02/msg322783.html But the real issue is that you are building 3.40, and not 3.44, which has the fix for spilhaus. As I understand it, 3.44 will be LTR soon, Are you sure you are using the 3.40 from git, or the latest point release? From andreaerdna at libero.it Thu Feb 5 00:42:33 2026 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Thu, 5 Feb 2026 09:42:33 +0100 Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W Message-ID: Il 04/02/2026 23:04, Greg Troxel via QGIS-Developer ha scritto: > But the real issue is that you are building 3.40, and not 3.44, which > has the fix for spilhaus. As I understand it, 3.44 will be LTR soon, Hi Greg and Mehmet, actually also 3.40 code has the "fix" for spilhaus projection from about 1 year. See: - https://github.com/qgis/QGIS/blame/release-3_40/src/core/proj/qgscoordinatereferencesystemutils.cpp#L428-L429 - https://github.com/qgis/QGIS/pull/60685 Perhaps Mehmet is using a very 3.40 code? Regards. Andrea From andreaerdna at libero.it Thu Feb 5 02:19:00 2026 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Thu, 5 Feb 2026 11:19:00 +0100 Subject: [QGIS-Developer] QGIS 3.40 build failure in crssync with PROJ 9.7.1 on OSGeo4W Message-ID: <01ba5144-7c8b-411b-a086-76851a901049@libero.it> Il 05/02/2026 09:42, Andrea Giudiceandrea ha scritto: > Perhaps Mehmet is using a very 3.40 code? ...a very old 3.40 code... From jean.felder at oslandia.com Thu Feb 5 05:58:56 2026 From: jean.felder at oslandia.com (Jean Felder) Date: Thu, 5 Feb 2026 14:58:56 +0100 Subject: [QGIS-Developer] QEP 322: Point layer edition from the profile tool In-Reply-To: <4947d9ed-b730-45d4-b6dd-236e1ef62f8e@oslandia.com> References: <4947d9ed-b730-45d4-b6dd-236e1ef62f8e@oslandia.com> Message-ID: Hi everyone, Just a friendly reminder: voting is still open for the 'Point layer edition from the profile tool' QEP https://github.com/qgis/QGIS-Enhancement-Proposals/pull/328 Regards, Jean Le 13/01/2026 ? 10:12, Jean Felder via QGIS-Developer a ?crit?: > Hi, > > Thank you for all your feedback; it has been taken into account in the > QEP. > It is now opened to vote: > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/328 > > > Regards, > Jean > > > _______________________________________________ > 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 -- Jean Felder D?veloppeur SIG Oslandia -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x12722DC64D3F429E.asc Type: application/pgp-keys Size: 2444 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From voting at qgis.org Thu Feb 5 18:33:00 2026 From: voting at qgis.org (Voting Officer) Date: Fri, 6 Feb 2026 10:33:00 +0800 Subject: [QGIS-Developer] Community Voting Members Election 2026: Ballot In-Reply-To: References: Message-ID: Hi all, just a friendly reminder that voting closes in 4 days on 10 February. Cheers John On Wed, Jan 28, 2026 at 9:51?AM Voting Officer wrote: > Dear QGIS Community, > > Thanks to the QGIS Committers for answering the Call for Nominations! The > call has now closed, with nominations for the following QGIS community > members: > > - > > Jean-Marie Arsac > - > > Lo?c Bartoletti > - > > Lova Andriarimalala > > We have one opening for the position of Community Voting Member. Eligible > voters are now invited to cast their ballot. > > Only QGIS Committers (?any person who has been granted commit access in > any of the official QGIS repositories?) are eligible to cast a ballot. This > includes committers to any QGIS Git repository or Transifex project. > > The voting will remain open until **23:59 UTC on 10 February 2026**. You > can cast your ballot here: > > https://forms.gle/1tAMLkatg7gfKS6V6 > > For further details, visit the QGIS community organisation page > . If you have any questions > about the process, please don?t hesitate to contact me. > > Thank you for your continued engagement! > John Bryant > QGIS Voting Officer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Fri Feb 6 08:36:26 2026 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 6 Feb 2026 19:36:26 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from January 26th to February 6th, 2026 Message-ID: Hello everyone, Please find some highlights regarding the development and maintenance of the QGIS Websites for the last two weeks, from January 26th to February 6th, 2026. *QGIS.org:* - Fix duplicate Ubuntu/ Debian packages [Deployed] - Individual Contributors Map [Deployed] - Add new supporting contributors from Dec 2025 [Deployed] - Add a contributor badge for commercial support [Deployed] - Add contributor filter and search functionality with UI updates [New PR] *QGIS plugins:* - Upgrade Metabase to a recent version [Deployed] - Improve Qt6 support for RPC and metadata value [Deployed] - Fix auto approval logic for version create view [Deployed] - Add support for screenshots on plugins [New PR] - Improve documentation clarity in plugin publishing guidelines [New PR] - Disable pointer events for right ribbon overlay [New PR] - Improve API response handling for token based upload [New PR] - Fix code formatting in security scan result [New PR] *QGIS hub:* - Show animated GIFs in details and review page [New PR] - Show download button for reviewer in review details page [New PR] - Upgrade metabase docker image [Deployed] *QGIS planet:* - Add Hfc QGIS to subscribers [New PR] *QGIS feed:* - Upgrade metabase docker image [Deployed] - Enhance image preview functionality by adding cropping and scaling [Deployed] *QGIS Infrastructure Maintenance:* - QGIS Release Timeline Improvement Have a nice weekend, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.ml at oslandia.com Fri Feb 6 09:01:16 2026 From: vincent.ml at oslandia.com (Vincent Picavet) Date: Fri, 6 Feb 2026 18:01:16 +0100 Subject: [QGIS-Developer] "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: References: Message-ID: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> Hi, I would double-down on Greg Troxel's advice concerning copyright issues, especially concerning the introduction of LLM-generated code into QGIS codebase. Opensource's success is based on these main characteristics : quality, security, trust. AI contributions pose a threat to quality, security and trust alike. A human-in-the-loop policy for contributions written with AI may help for quality and security issues, but will still leaves a huge problem for trust. Among the various aspects of trust, what worries me most right now is the copyright issue. OpenSource software is based on intellectual property laws, and especially on copyright, to be able to derive copyleft and grant more rights to end-users. End-user trust opensource software from a legal point of view because : - they are backed by well-established copyright laws - they have clear and well established end-users contracts ( opensource licences ) - they have a full record of modifications of the source code, hence a full lineage and certification of IP rights for the code - also, foundations like OSGeo additionnaly put a stamp on the software to guarantee that process and initial IP can be trusted enough to have a legal insurance concerning the software Introducing IA black boxes into the development process breaks the ability to control the lineage of the code and guarantee that it is a genuine invention, and therefore allowed to be licenced under the GPL. For quality and security, a developer can always intrinsically assess that the generated code has the required level of quality, and that it does not include any security flaw. But **there is no way for a developer to evaluate the IP rights on a code generated by a LLM**. How would one do it, since the code has been generated through a total opaque black box ingesting non-identified enormous volumes of data ? Today, we definitely know that LLMs ( ChatGPT, Claude and others ) have been trained on illegal copyrighted material. It is proven that they trained LLMs on pirated books. Furthermore, every time someone complaints about IP violation by LLM, big corps settle a financial arrangement with the copyright owners and move on. There is therefore no doubt that they have also trained LLMs on proprietary code. And also on opensource code not compliant with GPLv2+. Big corp. currently hide behind a "fair use" argument, but this is clearly rubbish, otherwise why would they bother to settle large financial deals with copyright owners ? So, LLM-generated code contributed to QGIS will at some point be plagiarized from random code available on the internet, and neither QGIS.org nor the contributor will be able to know. If we start accepting such code without being able to check provenance or copyright issues, it will end up buried deep inside QGIS, and the day we will discover that it infringes copyright, it will be a nightmare to solve : in this case we will want to revert all incriminated code, and also all code depending on the plagiarized code **and have it rewritten from scratch by someone who has never read the plagiarized code** ( ref : SCO/UNIX for example ). This is almost impossible. This would be a nightmare, just for one identified contribution. Even more, if/when the fair-use principle of LLMs falls down, then all LLM-generated code should be removed from QGIS, and all code depending on it. This is a really high risk with high impact. You may say : "ok but everyone does it, the chances of being caught are low, why not benefit from the opportunity ?" Then what about "everyone copies GPL code into proprietary code, the chances of being caught are low, why not benefit from the opportunity ?" Copyright is at the foundation of OpenSource software, and especially GPL-based software. If we choose to deny it, then we loose our core principle. In the text Even propose, there is a copyright section, pushing the responsibility of IP compliance control back to the contributor. It may protect QGIS.org or other developers from being sued whenever there is a problem, or they could sue back the faulty contributor, but this is not enough : - the faulty contributor has no way to ensure his generated code has no IP issue ( other than NOT using LLMs ) : responsibility without any mean of action is not fair and sustainable - even if the QGIS projet can avoid being convicted by transferring responsibility, then the situation would still be open and be a nightmare : removing plagiarized code entangled down the core of the software and all its dependency code, and rewrite it without IP issue is really hard Therefore, I do not think this mention is enough for IP protection. This rationale concerns the generated code itself, contributed to QGIS or other software in the ecosystem. LLMs may be useful and without IP risks to help find bugs, write parts of documentations where there is no risk of plagiarism, or other use cases. But I would definitely **forbid any generated code to be introduced into the main source code because of IP risk**. Also, the least we can do for any contribution, is not only to have a human in the loop, but also to have a mandatory mention and description of LLM usage for each contribution. This would at least give traceability. It does not solve anything, but in case of a problem, we could at least start to investigate. A am glad this conversation takes place, and willing to pursue the discussion, sorry for having been long. Have a nice weekend, Vincent On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: > I would suggest a much stronger policy: > > no LLM-generated code or discussion may be submitted to any QGIS forum > > > The idea that LLM-generated code has been "reviewed" intends to be that > it is of high enough quality that it is reasonable for *humans* to spend > time reviewing it. But I don't believe that asking that it be reviewed > will achieve that in practice. > > I've already had the experience (in a different project) of seeing a > posted PR(ish, patch on list), taking the time to comment, and getting > LLM-generated (vacuous) replies to my comments. > > Besides the ethical problems with asking humans to review, improve, > judge or in any other way pay attention to LLM output, there's the > problem of copyright. While machine-generated text isn't copyrightable > as is, LLM output is a derived work of stolen human work, scraped > and used without permission, often as DDOS. > > On the basis of each reason, I believe the policy about LLM should just > be "no". > _______________________________________________ > 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 bertrand.parpoil at oslandia.com Fri Feb 6 09:19:17 2026 From: bertrand.parpoil at oslandia.com (Bertrand Parpoil) Date: Fri, 6 Feb 2026 18:19:17 +0100 Subject: [QGIS-Developer] RFI: Code review contracts by Oslandia Message-ID: <56516fc1-1f61-4cca-bb1a-d6de61770001@oslandia.com> Hello, Oslandia contributes to QGIS through several projects carried out on behalf of our clients and through improvements made in-house. We actively and regularly review contributions to QGIS, and our own contributions are reviewed by members of the community. Oslandia therefore already finances many contributions to the QGIS project and its community operations, in particular the review of code written by the entire community, by making its employees' time available. Beyond our own code reviews by Oslandia employees who contribute to QGIS, we would like to set up direct code review contracts for developers in the community. The aim of this is to: - respond to the high level of activity in terms of Pull Requests (by Oslandia employees and others) and therefore the need for review - encourage review efforts in general - promote the growth of the number of reviewers, and ultimately core committers Oslandia therefore offers paid contracts for developers, which are aimed at: - active members of the QGIS community who are likely to be involved in a number of Pull Requests - or C++ and Qt developers who are likely to be involved in C++, Qt, 3D, and other issues. Please note that this is not a community initiative led by QGIS.org but a specific initiative of the company Oslandia. Oslandia is the contractor and remains the decision-maker on the work to be prioritized under these contracts. The work carried out by the service providers must comply with all the written rules of operation of the QGIS project. In the case of an expert from outside the QGIS community, we are committed to making the necessary efforts to integrate them into the QGIS community. Contracts will be based on a negotiated hourly rate and a maximum number of hours ordered per contractor. We require a commitment to responsiveness in exchanges within the PRs and an initial agreement to review the various PRs with a schedule for intervention. The contractual conditions also include: - compliance with the QGIS code of conduct - a constructive approach to all interactions - actively benevolent behavior - justification of proposed changes - compliance with all explicit QGIS rules We are offering 10-hour contracts to start with, which can be extended or adapted according to individual needs and capabilities. The process is as follows: - Call for expressions of interest (this message today) - Receipt of applications: before February 14 - Selection of candidates by Oslandia: before February 21 - Contractualization Would you like to apply? Fill out the following form: https://oslandia.com/en/call-for-interest-qgis-qt-reviews-contracts/ Any question? Contact us and let's talk: qgis+review at oslandia.com Thank you for your proposals, and have a nice and shiny day ! -- Bertrand Parpoil Directeur Oslandia +33 188 320 680 Notre livre blanc d?di? ? la migration SIG opensource est disponible ! https://oslandia.com/livre-blanc-migration-sig-opensource/ *** https://www.linkedin.com/company/oslandia/ fingerprint=F06E 6518 C3B5 868D 6E57 BC13 E270 51C0 BE24 8B8F From lnicola at dend.ro Fri Feb 6 09:41:01 2026 From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=) Date: Fri, 06 Feb 2026 19:41:01 +0200 Subject: [QGIS-Developer] "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> References: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> Message-ID: <3387b4a1-2c9a-4922-bc7b-f304f27218ca@betaapp.fastmail.com> Hi, At least in the US (and in my personal opinion, too), training an LLM is now thought to be transformative, thus fair use [1]. It's also not obvious that an LLM will reproduce ad-literam material from its training set [2]. > Transformativeness is a characteristic of such derivative works that makes them transcend, or place in a new light, the underlying works on which they are based. [3] More so, it's becoming pretty clear that LLMs are more than -- to use a well-loved phrase -- "stochastic parrots". As a recent example, one built a C compiler [3] in Rust. I believe there used to be ~3 compilers that could build Linux, none of them written in Rust, and none of them translatable to Rust due to the particularities of the language. So while it might have had GCC in its training set, it couldn't have reproduced it. And it's not like humans are perfect at avoiding copyrighted code. Try to write a binary search, or quick sort, or a Web Mercator conversion function that's not identical in spirit (at least) to a published version. Or look at how people used to copy-paste snippets from Stack Overflow before LLMs got popular. The AI cat is out of the bag, and no policy trying to ban LLMs will put it back in. That's not to say that LLM-written contributions are always of high quality, quite the opposite. But LLMs have been getting better (writing even a toy compiler would have been a pipe dream just one year ago), so their quality is going to improve in the long run. And, as I mentioned before, putting LLM-based completions [5] in the same basket as the AI writing a whole new feature from scratch feels absurd. Laurentiu [1]: https://www.nortonrosefulbright.com/en/knowledge/publications/afb0e10b/two-us-decisions-find-that-reproducing-works-to-train-large-language-models-is-fair-use [2]: as opposed to feeding it nearby text from the original and asking for a completion like in https://arxiv.org/pdf/2505.12546 [3]: https://en.wikipedia.org/wiki/Transformative_use [4]: https://www.anthropic.com/engineering/building-c-compiler [5]: not a great example, but https://youtu.be/hSFeDdZWHt0?t=179 From pigrecoinfinito at gmail.com Fri Feb 6 10:06:45 2026 From: pigrecoinfinito at gmail.com (=?UTF-8?Q?Tot=C3=B2_Fiandaca?=) Date: Fri, 6 Feb 2026 19:06:45 +0100 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from January 26th to February 6th, 2026 In-Reply-To: References: Message-ID: Grazie mille! Il giorno ven 6 feb 2026 alle ore 17:37 Lova Andriarimalala via QGIS-Developer ha scritto: > Hello everyone, > > Please find some highlights regarding the development and maintenance of > the QGIS Websites for the last two weeks, from January 26th to February > 6th, 2026. > > *QGIS.org:* > > - Fix duplicate Ubuntu/ Debian packages > [Deployed] > - Individual Contributors Map > [Deployed] > - Add new supporting contributors from Dec 2025 > [Deployed] > - Add a contributor badge for commercial support > [Deployed] > - Add contributor filter and search functionality with UI updates > [New PR] > > *QGIS plugins:* > > - Upgrade Metabase to a recent version > [Deployed] > - Improve Qt6 support for RPC and metadata value > [Deployed] > - Fix auto approval logic for version create view > [Deployed] > - Add support for screenshots on plugins > [New PR] > - Improve documentation clarity in plugin publishing guidelines > [New PR] > - Disable pointer events for right ribbon overlay > [New PR] > - Improve API response handling for token based upload > [New PR] > - Fix code formatting in security scan result > [New PR] > > *QGIS hub:* > > - Show animated GIFs in details and review page > [New PR] > - Show download button for reviewer in review details page > [New PR] > - Upgrade metabase docker image > [Deployed] > > *QGIS planet:* > > - Add Hfc QGIS to subscribers > [New PR] > > *QGIS feed:* > > - Upgrade metabase docker image > [Deployed] > - Enhance image preview functionality by adding cropping and scaling > [Deployed] > > *QGIS Infrastructure Maintenance:* > > - QGIS Release Timeline Improvement > > > Have a nice weekend, > > Lova Andriarimalala > > > *QGIS Full Stack Developer * > *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : > kartoza.com > > > > *This email and any attachments are confidential and intended solely for > the use of the individual or entity to whom they are addressed. If you * > *have received this email in error, please notify the sender immediately > and delete it from your system. Unauthorised use, disclosure, or copying* > *of the contents is prohibited.* > _______________________________________________ > 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 > > > -- > *Salvatore Fiandaca* > > Questo documento, allegati inclusi, contiene informazioni di propriet? di > FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario > in relazione alle finalit? per le quali ? stato ricevuto. E' vietata > qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso > di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega > di informare tempestivamente il mittente e distruggere la copia in proprio > possesso. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Feb 6 15:30:59 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 7 Feb 2026 00:30:59 +0100 Subject: [QGIS-Developer] [Poll created] Re: "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> References: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> Message-ID: <2a83f100-2eca-4008-ae62-83f90bc8607c@spatialys.com> Vincent, Thanks for your feedback. Yes copyright / IP issues are a tricky problem to deal with and you make good points on how things could go wrong. That said, in practice I believe most generated code would be mostly derived from QGIS itself, QT code or doc or be non-copyrightable material. I can imagine though that contributions including non-trivial algorithms could possibly be infringing copyright. In that situation, the reviewers could ask the submitter to bring more light on the provenance of such code (the contributor may ask the LLM to dig for references for the provenance and check they are OK with GPL2 inclusion, being aware that the LLM could hallucinate them...), and if no satisfactory answer is given, reject the contribution. But that can be admitedly hard to spot for reviewers. I'd be happy to amend the QEP with that if someone can propose an adequate formulation. I've doubts a "no AI" policy is achievable in practice, or people will lie.? As you mention, we can require people to mention the tool they have used, possibly the prompt(s) they use, which manual modifications they applied on top of that.? Doesn't the paragraph starting at line 35 (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/changes#diff-4f4102e51f04fdfc82e843c6942abe9965c03ac85a92e9becf21bcca8b5571adR35) cover enough your point about "have a mandatory mention and description of LLM usage for each contribution" ? The main driver for this QEP was to give us a tool to be able to quickly reject sloppy contributions with a solid reference to back our decisions, but we must indeed decide whether we go further than this. For that purpose, I've created a quick poll at https://docs.google.com/forms/d/e/1FAIpQLSdnVWoD5DrwCbNXqPqHsLw2jfbLkPMKBkvfyQfTQOPZkj_EaQ/viewform so we can gather opinions on the general direction we want on that subject. All, please fill! Even Le 06/02/2026 ? 18:01, Vincent Picavet via QGIS-Developer a ?crit?: > Hi, > > I would double-down on Greg Troxel's advice concerning copyright > issues, especially concerning the introduction of LLM-generated code > into QGIS codebase. > > Opensource's success is based on these main characteristics : quality, > security, trust. > > AI contributions pose a threat to quality, security and trust alike. > > A human-in-the-loop policy for contributions written with AI may help > for quality and security issues, but will still leaves a huge problem > for trust. > > Among the various aspects of trust, what worries me most right now is > the copyright issue. OpenSource software is based on intellectual > property laws, and especially on copyright, to be able to derive > copyleft and grant more rights to end-users. > > End-user trust opensource software from a legal point of view because : > > - they are backed by well-established copyright laws > > - they have clear and well established end-users contracts ( > opensource licences ) > > - they have a full record of modifications of the source code, hence a > full lineage and certification of IP rights for the code > > - also, foundations like OSGeo additionnaly put a stamp on the > software to guarantee that process and initial IP can be trusted > enough to have a legal insurance concerning the software > > Introducing IA black boxes into the development process breaks the > ability to control the lineage of the code and guarantee that it is a > genuine invention, and therefore allowed to be licenced under the GPL. > > For quality and security, a developer can always intrinsically assess > that the generated code has the required level of quality, and that it > does not include any security flaw. > > But **there is no way for a developer to evaluate the IP rights on a > code generated by a LLM**. How would one do it, since the code has > been generated through a total opaque black box ingesting > non-identified enormous volumes of data ? > > Today, we definitely know that LLMs ( ChatGPT, Claude and others ) > have been trained on illegal copyrighted material. It is proven that > they trained LLMs on pirated books. Furthermore, every time someone > complaints about IP violation by LLM, big corps settle a financial > arrangement with the copyright owners and move on. > > There is therefore no doubt that they have also trained LLMs on > proprietary code. And also on opensource code not compliant with GPLv2+. > > Big corp. currently hide behind a "fair use" argument, but this is > clearly rubbish, otherwise why would they bother to settle large > financial deals with copyright owners ? > > So, LLM-generated code contributed to QGIS will at some point be > plagiarized from random code available on the internet, and neither > QGIS.org nor the contributor will be able to know. > > If we start accepting such code without being able to check provenance > or copyright issues, it will end up buried deep inside QGIS, and the > day we will discover that it infringes copyright, it will be a > nightmare to solve : in this case we will want to revert all > incriminated code, and also all code depending on the plagiarized code > **and have it rewritten from scratch by someone who has never read the > plagiarized code** ( ref : SCO/UNIX for example ). This is almost > impossible. > > This would be a nightmare, just for one identified contribution. > > Even more, if/when the fair-use principle of LLMs falls down, then all > LLM-generated code should be removed from QGIS, and all code depending > on it. This is a really high risk with high impact. > > You may say : "ok but everyone does it, the chances of being caught > are low, why not benefit from the opportunity ?" > > Then what about "everyone copies GPL code into proprietary code, the > chances of being caught are low, why not benefit from the opportunity ?" > > Copyright is at the foundation of OpenSource software, and especially > GPL-based software. If we choose to deny it, then we loose our core > principle. > > In the text Even propose, there is a copyright section, pushing the > responsibility of IP compliance control back to the contributor. It > may protect QGIS.org or other developers from being sued whenever > there is a problem, or they could sue back the faulty contributor, but > this is not enough : > > - the faulty contributor has no way to ensure his generated code has > no IP issue ( other than NOT using LLMs ) : responsibility without any > mean of action is not fair and sustainable > > - even if the QGIS projet can avoid being convicted by transferring > responsibility, then the situation would still be open and be a > nightmare : removing plagiarized code entangled down the core of the > software and all its dependency code, and rewrite it without IP issue > is really hard > > Therefore, I do not think this mention is enough for IP protection. > > This rationale concerns the generated code itself, contributed to QGIS > or other software in the ecosystem. LLMs may be useful and without IP > risks to help find bugs, write parts of documentations where there is > no risk of plagiarism, or other use cases. > > But I would definitely **forbid any generated code to be introduced > into the main source code because of IP risk**. > > Also, the least we can do for any contribution, is not only to have a > human in the loop, but also to have a mandatory mention and > description of LLM usage for each contribution. This would at least > give traceability. It does not solve anything, but in case of a > problem, we could at least start to investigate. > > A am glad this conversation takes place, and willing to pursue the > discussion, sorry for having been long. > > Have a nice weekend, > > Vincent > > > > > > On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: >> I would suggest a much stronger policy: >> >> ?? no LLM-generated code or discussion may be submitted to any QGIS >> forum >> >> >> The idea that LLM-generated code has been "reviewed" intends to be that >> it is of high enough quality that it is reasonable for *humans* to spend >> time reviewing it.? But I don't believe that asking that it be reviewed >> will achieve that in practice. >> >> I've already had the experience (in a different project) of seeing a >> posted PR(ish, patch on list), taking the time to comment, and getting >> LLM-generated (vacuous) replies to my comments. >> >> Besides the ethical problems with asking humans to review, improve, >> judge or in any other way pay attention to LLM output, there's the >> problem of copyright.? While machine-generated text isn't copyrightable >> as is, LLM output is a derived work of stolen human work, scraped >> and used without permission, often as DDOS. >> >> On the basis of each reason, I believe the policy about LLM should just >> be "no". >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://www.spatialys.com My software is free, but my time generally not. From addloe at gmail.com Mon Feb 9 05:36:57 2026 From: addloe at gmail.com (Admire Nyakudya) Date: Mon, 9 Feb 2026 15:36:57 +0200 Subject: [QGIS-Developer] QGIS Plugins and AI Generation Message-ID: <0e90eaf4-1149-4b12-bea4-1ed99db42aa3@gmail.com> Dear All The rapid proliferation of AI tools has led to a noticeable increase in QGIS plugins being created and uploaded to the registry. The bonus points for these new plugin are: * functionality gaps are being filled faster * workflows are consolidated * innovation is happening at pace. However, it also introduces new challenges for the QGIS plugin ecosystem, particularly around trust, review, and governance. While responsibility ultimately lies with end users to decide which plugins they trust, the growing use of AI-assisted or AI-generated code raises additional concerns beyond those already discussed in recent QGIS pull requests/code base related to AI usage. The plugin approval process relies heavily on volunteer effort and with the many plugins being uploaded we have to rely heavily on authors to submit high-quality, secure, and maintainable code. The plugin review process is not focused on code review but does so in limited circumstances. End users rely on author reputation, plugin ratings? as indicators to trust the plugin quality and usefulness. To improve transparency and support informed decision-making, it may be worth introducing an optional metadata flag in *metadata.txt*, for example: *ai_derivative = yes* All existing plugins could default to no, with the flag applied to new or updated plugins going forward. This would not act as a quality judgement, but rather as a disclosure mechanism, allowing users to filter plugins and assess trust based on their own criteria, alongside authorship and plugin rating. Regards Admire (Active plugin reviewer) -- Email Signature GIS Engineer Location: Geolocate me here Phone: +27639664031 Email: addloe at gmail.com Social Media: * LinkedIn * GitHub -------------- next part -------------- An HTML attachment was scrubbed... URL: From delazj at gmail.com Mon Feb 9 06:27:55 2026 From: delazj at gmail.com (DelazJ) Date: Mon, 9 Feb 2026 15:27:55 +0100 Subject: [QGIS-Developer] QGIS Plugins and AI Generation In-Reply-To: <0e90eaf4-1149-4b12-bea4-1ed99db42aa3@gmail.com> References: <0e90eaf4-1149-4b12-bea4-1ed99db42aa3@gmail.com> Message-ID: Hi Admire, Thanks for raising this issue. On a wider perspective, in order to better categorize available plugins, Even Rouault raised this discussion end 2024 [0]. He then opened pull requests at [1] and [2] but these finally led nowhere... Something to revive? [0] https://lists.osgeo.org/pipermail/qgis-developer/2024-November/067141.html [1] https://github.com/qgis/QGIS-Documentation/pull/9374 [2] https://github.com/qgis/QGIS-Django/pull/484 Regards, Harrissou Le lun. 9 f?vr. 2026 ? 14:37, Admire Nyakudya via QGIS-Developer < qgis-developer at lists.osgeo.org> a ?crit : > Dear All > > The rapid proliferation of AI tools has led to a noticeable increase in > QGIS plugins being created and uploaded to the registry. > > The bonus points for these new plugin are: > > - functionality gaps are being filled faster > - workflows are consolidated > - innovation is happening at pace. > > > However, it also introduces new challenges for the QGIS plugin ecosystem, > particularly around trust, review, and governance. > > While responsibility ultimately lies with end users to decide which > plugins they trust, the growing use of AI-assisted or AI-generated code > raises additional concerns beyond those already discussed in recent QGIS > pull requests/code base related to AI usage. > > The plugin approval process relies heavily on volunteer effort and with > the many plugins being uploaded we have to rely heavily on authors to > submit high-quality, secure, and maintainable code. > > The plugin review process is not focused on code review but does so in > limited circumstances. End users rely on author reputation, plugin ratings? > as indicators to trust the plugin quality and usefulness. > > To improve transparency and support informed decision-making, it may be > worth introducing an optional metadata flag in *metadata.txt*, for > example: > > *ai_derivative = yes* > > All existing plugins could default to no, with the flag applied to new or > updated plugins going forward. This would not act as a quality judgement, > but rather as a disclosure mechanism, allowing users to filter plugins and > assess trust based on their own criteria, alongside authorship and plugin > rating. > > Regards > > Admire (Active plugin reviewer) > > -- > > GIS Engineer > > Location: Geolocate me here > > Phone: +27639664031 > > Email: addloe at gmail.com > > Social Media: > > - LinkedIn > - GitHub > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From regis.haubourg at gmail.com Mon Feb 9 09:48:31 2026 From: regis.haubourg at gmail.com (=?UTF-8?Q?R=C3=A9gis_Haubourg?=) Date: Mon, 9 Feb 2026 18:48:31 +0100 Subject: [QGIS-Developer] QGIS Plugins and AI Generation In-Reply-To: <0e90eaf4-1149-4b12-bea4-1ed99db42aa3@gmail.com> References: <0e90eaf4-1149-4b12-bea4-1ed99db42aa3@gmail.com> Message-ID: <454cb210-e214-47e6-89c9-4a424cafce66@gmail.com> Hi, I agree AI is making the plugin's ecosystem being boosted, with all the good and bad sides you mentioned. I like the idea of a field in metadata.txt for a spontaneous disclosure. From what we see on PR's or security disclosures is that some AI users are reluctant to reveal they worked with AI. And probably, many dev's will use a bit of AI autocompletion most of the time. It takes some rounds of discussions to spot that they don't fully understand the code they produced, which is the famous AI slop. So in my opinion, we should be able to use a `ai_possible_derivative` flag as moderators, from the plugin's catalog. Maybe it is time to set up a full community discussion and voting system, just as internet browsers do for plugins. ?One should be able to signal a malicious, or badly coded plugin triggering crashes. And moderators should be able to ban / alert / flag plugins beyond the volontary metadata.txt tooling. And maybe we would have to add automated scanners for security security, code smells, and now AI smells.. Maybe Lova could tell us about ho this is doable, and if we have the resources to do this this year. Cheers R?gis On 2/9/26 14:36, Admire Nyakudya via QGIS-Developer wrote: > > Dear All > > The rapid proliferation of AI tools has led to a noticeable increase > in QGIS plugins being created and uploaded to the registry. > > The bonus points for these new plugin are: > > * functionality gaps are being filled faster > * workflows are consolidated > * innovation is happening at pace. > > > However, it also introduces new challenges for the QGIS plugin > ecosystem, particularly around trust, review, and governance. > > While responsibility ultimately lies with end users to decide which > plugins they trust, the growing use of AI-assisted or AI-generated > code raises additional concerns beyond those already discussed in > recent QGIS pull requests/code base related to AI usage. > > The plugin approval process relies heavily on volunteer effort and > with the many plugins being uploaded we have to rely heavily on > authors to submit high-quality, secure, and maintainable code. > > The plugin review process is not focused on code review but does so in > limited circumstances. End users rely on author reputation, plugin > ratings? as indicators to trust the plugin quality and usefulness. > > To improve transparency and support informed decision-making, it may > be worth introducing an optional metadata flag in *metadata.txt*, for > example: > > *ai_derivative = yes* > > All existing plugins could default to no, with the flag applied to new > or updated plugins going forward. This would not act as a quality > judgement, but rather as a disclosure mechanism, allowing users to > filter plugins and assess trust based on their own criteria, alongside > authorship and plugin rating. > > Regards > > Admire (Active plugin reviewer) > > -- > Email Signature > > GIS Engineer > > Location: Geolocate me here > > Phone: +27639664031 > > Email: addloe at gmail.com > > Social Media: > > * LinkedIn > * GitHub > > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.rouzaud at gmail.com Tue Feb 10 00:29:42 2026 From: denis.rouzaud at gmail.com (Denis Rouzaud) Date: Tue, 10 Feb 2026 09:29:42 +0100 Subject: [QGIS-Developer] QGIS Plugins and AI Generation In-Reply-To: <454cb210-e214-47e6-89c9-4a424cafce66@gmail.com> References: <0e90eaf4-1149-4b12-bea4-1ed99db42aa3@gmail.com> <454cb210-e214-47e6-89c9-4a424cafce66@gmail.com> Message-ID: Hi all, I must say I'm not very enthusiastic about adding such a flag. If there is a malicious intention, this flag will obviously not be enabled. If we're talking about code quality and risks, I would consider that having AI in the loop is not a sign of lower quality or higher risks to me. Then, if this flag has a default value, the level of confidence will be very low. So I personally don't see an added value for this. I personally would rather try to use AI to actually do the reviews of the plugins, remove the human in the loop (at least at the first round), where a human is actually not good at. But I think this is already under discussion, and probably not the original topic, but somehow related. Cheers, Denis Le lun. 9 f?vr. 2026 ? 18:48, R?gis Haubourg via QGIS-Developer < qgis-developer at lists.osgeo.org> a ?crit : > Hi, I agree AI is making the plugin's ecosystem being boosted, with all > the good and bad sides you mentioned. > > I like the idea of a field in metadata.txt for a spontaneous disclosure. > From what we see on PR's or security disclosures is that some AI users are > reluctant to reveal they worked with AI. And probably, many dev's will use > a bit of AI autocompletion most of the time. > It takes some rounds of discussions to spot that they don't fully > understand the code they produced, which is the famous AI slop. > So in my opinion, we should be able to use a `ai_possible_derivative` flag > as moderators, from the plugin's catalog. Maybe it is time to set up a full > community discussion and voting system, just as internet browsers do for > plugins. > One should be able to signal a malicious, or badly coded plugin > triggering crashes. And moderators should be able to ban / alert / flag > plugins beyond the volontary metadata.txt tooling. And maybe we would have > to add automated scanners for security security, code smells, and now AI > smells.. > > Maybe Lova could tell us about ho this is doable, and if we have the > resources to do this this year. > > Cheers > R?gis > > > On 2/9/26 14:36, Admire Nyakudya via QGIS-Developer wrote: > > Dear All > > The rapid proliferation of AI tools has led to a noticeable increase in > QGIS plugins being created and uploaded to the registry. > > The bonus points for these new plugin are: > > - functionality gaps are being filled faster > - workflows are consolidated > - innovation is happening at pace. > > > However, it also introduces new challenges for the QGIS plugin ecosystem, > particularly around trust, review, and governance. > > While responsibility ultimately lies with end users to decide which > plugins they trust, the growing use of AI-assisted or AI-generated code > raises additional concerns beyond those already discussed in recent QGIS > pull requests/code base related to AI usage. > > The plugin approval process relies heavily on volunteer effort and with > the many plugins being uploaded we have to rely heavily on authors to > submit high-quality, secure, and maintainable code. > > The plugin review process is not focused on code review but does so in > limited circumstances. End users rely on author reputation, plugin ratings? > as indicators to trust the plugin quality and usefulness. > > To improve transparency and support informed decision-making, it may be > worth introducing an optional metadata flag in *metadata.txt*, for > example: > > *ai_derivative = yes* > > All existing plugins could default to no, with the flag applied to new or > updated plugins going forward. This would not act as a quality judgement, > but rather as a disclosure mechanism, allowing users to filter plugins and > assess trust based on their own criteria, alongside authorship and plugin > rating. > > Regards > > Admire (Active plugin reviewer) > > -- > > GIS Engineer > > Location: Geolocate me here > > Phone: +27639664031 > > Email: addloe at gmail.com > > Social Media: > > - LinkedIn > - GitHub > > > _______________________________________________ > 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: From johannes.kroeger at wheregroup.com Tue Feb 10 02:42:52 2026 From: johannes.kroeger at wheregroup.com (=?UTF-8?Q?Johannes_Kr=C3=B6ger_=28WhereGroup=29?=) Date: Tue, 10 Feb 2026 11:42:52 +0100 Subject: [QGIS-Developer] Info about a 3D view's renderer, version, extensions via PyQt/PyQGIS? Message-ID: <60343b8a-9744-4611-9355-1feb2d3a8982@wheregroup.com> Hi list, I am trying to get info on a client's machine 3D capabilities, where the 3D views are showing nothing, via Python in QGIS. I'd like to find their GL_RENDERER,?GL_VERSION etc. Basically debugging https://github.com/qgis/QGIS/issues/40324 but without the possibility to use third-party tools on the system. It looks like?QGIS uses a shared OpenGL context: https://github.com/qgis/QGIS/blob/e8b8108f3f013d96014bbde50e6935bf1dc4414a/src/app/main.cpp#L961 Checking it out on my system yields: >>> QCoreApplication.testAttribute(Qt.ApplicationAttribute.AA_ShareOpenGLContexts) True but there are no extensions for example: >>> QOpenGLContext.globalShareContext().extensions() set() While that set is empty, if I enable the "GL info" debug overlay in a 3D view, it does show a list of many supported extensions. Maybe I am using it wrong? Does the 3D view actually use a different OpenGL context? Is there a way to access info about that context from PyQGIS? Cheers, Hannes Johannes Kr?ger GIS-Consulting/-Entwicklung WhereGroup Logo WhereGroup GmbH Lange Reihe 29 20099 Hamburg Germany +49 228 90 90 38 36 johannes.kroeger at wheregroup.com www.wheregroup.com Gesch?ftsf?hrer: Olaf Knopp, Peter Stamm Amtsgericht Bonn, HRB 9885 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: KsMMzXXyFaFbXYxP.png Type: image/png Size: 5856 bytes Desc: not available URL: From vincent.ml at oslandia.com Tue Feb 10 09:05:41 2026 From: vincent.ml at oslandia.com (Vincent Picavet) Date: Tue, 10 Feb 2026 18:05:41 +0100 Subject: [QGIS-Developer] [Poll created] Re: "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: <2a83f100-2eca-4008-ae62-83f90bc8607c@spatialys.com> References: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> <2a83f100-2eca-4008-ae62-83f90bc8607c@spatialys.com> Message-ID: <77d5ef0b-16d6-4703-8b28-d2cdbdf1104f@oslandia.com> Hello, On 07/02/2026 00:30, Even Rouault wrote: > Thanks for your feedback. Yes copyright / IP issues are a tricky problem to deal with and you make good points on how things could go wrong. That said, in practice I believe most generated code would be mostly derived from QGIS itself, QT code or doc or be non-copyrightable material. I can I seriously doubt that, given the amount of copyrighted material that has already been used to train LLMs. And most important, we have no way to know that, except if the LLM companies get subpoenaed and disclose hidden practices when asked in court. Believing is not enough when talking about legal stuff. > imagine though that contributions including non-trivial algorithms could possibly be infringing copyright. In that situation, the reviewers could ask the Even simpler code can be plagiarized, not only non-trivial algorithms. > submitter to bring more light on the provenance of such code (the contributor may ask the LLM to dig for references for the provenance and check they are OK with GPL2 inclusion, being aware that the LLM could hallucinate them...), and if no satisfactory answer is given, reject the contribution. But that can be admitedly hard to spot for reviewers. I'd be happy to amend the QEP with that if someone can propose an adequate formulation. Again, a reviewer has no way to know or imagine that a code has been plagiarized : you would have to be aware of the full training dataset of the LLM, and this is 1. behind closed fences 2. not humanly possible. > I've doubts a "no AI" policy is achievable in practice, or people will lie.? As you mention, we can require people to mention the tool they have used, possibly the prompt(s) they use, which manual modifications they applied on top of that.? Doesn't the paragraph starting at line 35 (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/changes#diff-4f4102e51f04fdfc82e843c6942abe9965c03ac85a92e9becf21bcca8b5571adR35) cover enough your point about "have a mandatory mention and description of LLM usage for each contribution" ? Lying about not using AI is just like lying about being sure one has the right to contribute the code ( see contributor's agreement ) : if this is a rule, we ask people and they lie, then we should also have sanctions and be strict about it. For me, full transparency about usage of a blackbox **for code generation** is not enough as a protection against legal matters. For anything else that can be AI-aided, this is more about resiliency, transparency and trust, and we should make it clear that explaining exactly how AI has been used is mandatory and should be given along every contribution. > The main driver for this QEP was to give us a tool to be able to quickly reject sloppy contributions with a solid reference to back our decisions, but we must indeed decide whether we go further than this. I guess there is matter to debate and a lot of uncertainty. Hence the conservative approach, to avoid the worst and maybe open it later on whenever we see the situation clearer. > For that purpose, I've created a quick poll at https://docs.google.com/forms/d/e/1FAIpQLSdnVWoD5DrwCbNXqPqHsLw2jfbLkPMKBkvfyQfTQOPZkj_EaQ/viewform so we can gather opinions on the general direction we want on that subject. All, please fill! Ok to gather more advice, thanks for running the poll, Vincent > > Even > > Le 06/02/2026 ? 18:01, Vincent Picavet via QGIS-Developer a ?crit?: >> Hi, >> >> I would double-down on Greg Troxel's advice concerning copyright issues, especially concerning the introduction of LLM-generated code into QGIS codebase. >> >> Opensource's success is based on these main characteristics : quality, security, trust. >> >> AI contributions pose a threat to quality, security and trust alike. >> >> A human-in-the-loop policy for contributions written with AI may help for quality and security issues, but will still leaves a huge problem for trust. >> >> Among the various aspects of trust, what worries me most right now is the copyright issue. OpenSource software is based on intellectual property laws, and especially on copyright, to be able to derive copyleft and grant more rights to end-users. >> >> End-user trust opensource software from a legal point of view because : >> >> - they are backed by well-established copyright laws >> >> - they have clear and well established end-users contracts ( opensource licences ) >> >> - they have a full record of modifications of the source code, hence a full lineage and certification of IP rights for the code >> >> - also, foundations like OSGeo additionnaly put a stamp on the software to guarantee that process and initial IP can be trusted enough to have a legal insurance concerning the software >> >> Introducing IA black boxes into the development process breaks the ability to control the lineage of the code and guarantee that it is a genuine invention, and therefore allowed to be licenced under the GPL. >> >> For quality and security, a developer can always intrinsically assess that the generated code has the required level of quality, and that it does not include any security flaw. >> >> But **there is no way for a developer to evaluate the IP rights on a code generated by a LLM**. How would one do it, since the code has been generated through a total opaque black box ingesting non-identified enormous volumes of data ? >> >> Today, we definitely know that LLMs ( ChatGPT, Claude and others ) have been trained on illegal copyrighted material. It is proven that they trained LLMs on pirated books. Furthermore, every time someone complaints about IP violation by LLM, big corps settle a financial arrangement with the copyright owners and move on. >> >> There is therefore no doubt that they have also trained LLMs on proprietary code. And also on opensource code not compliant with GPLv2+. >> >> Big corp. currently hide behind a "fair use" argument, but this is clearly rubbish, otherwise why would they bother to settle large financial deals with copyright owners ? >> >> So, LLM-generated code contributed to QGIS will at some point be plagiarized from random code available on the internet, and neither QGIS.org nor the contributor will be able to know. >> >> If we start accepting such code without being able to check provenance or copyright issues, it will end up buried deep inside QGIS, and the day we will discover that it infringes copyright, it will be a nightmare to solve : in this case we will want to revert all incriminated code, and also all code depending on the plagiarized code **and have it rewritten from scratch by someone who has never read the plagiarized code** ( ref : SCO/UNIX for example ). This is almost impossible. >> >> This would be a nightmare, just for one identified contribution. >> >> Even more, if/when the fair-use principle of LLMs falls down, then all LLM-generated code should be removed from QGIS, and all code depending on it. This is a really high risk with high impact. >> >> You may say : "ok but everyone does it, the chances of being caught are low, why not benefit from the opportunity ?" >> >> Then what about "everyone copies GPL code into proprietary code, the chances of being caught are low, why not benefit from the opportunity ?" >> >> Copyright is at the foundation of OpenSource software, and especially GPL-based software. If we choose to deny it, then we loose our core principle. >> >> In the text Even propose, there is a copyright section, pushing the responsibility of IP compliance control back to the contributor. It may protect QGIS.org or other developers from being sued whenever there is a problem, or they could sue back the faulty contributor, but this is not enough : >> >> - the faulty contributor has no way to ensure his generated code has no IP issue ( other than NOT using LLMs ) : responsibility without any mean of action is not fair and sustainable >> >> - even if the QGIS projet can avoid being convicted by transferring responsibility, then the situation would still be open and be a nightmare : removing plagiarized code entangled down the core of the software and all its dependency code, and rewrite it without IP issue is really hard >> >> Therefore, I do not think this mention is enough for IP protection. >> >> This rationale concerns the generated code itself, contributed to QGIS or other software in the ecosystem. LLMs may be useful and without IP risks to help find bugs, write parts of documentations where there is no risk of plagiarism, or other use cases. >> >> But I would definitely **forbid any generated code to be introduced into the main source code because of IP risk**. >> >> Also, the least we can do for any contribution, is not only to have a human in the loop, but also to have a mandatory mention and description of LLM usage for each contribution. This would at least give traceability. It does not solve anything, but in case of a problem, we could at least start to investigate. >> >> A am glad this conversation takes place, and willing to pursue the discussion, sorry for having been long. >> >> Have a nice weekend, >> >> Vincent >> >> >> >> >> >> On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: >>> I would suggest a much stronger policy: >>> >>> ?? no LLM-generated code or discussion may be submitted to any QGIS forum >>> >>> >>> The idea that LLM-generated code has been "reviewed" intends to be that >>> it is of high enough quality that it is reasonable for *humans* to spend >>> time reviewing it.? But I don't believe that asking that it be reviewed >>> will achieve that in practice. >>> >>> I've already had the experience (in a different project) of seeing a >>> posted PR(ish, patch on list), taking the time to comment, and getting >>> LLM-generated (vacuous) replies to my comments. >>> >>> Besides the ethical problems with asking humans to review, improve, >>> judge or in any other way pay attention to LLM output, there's the >>> problem of copyright.? While machine-generated text isn't copyrightable >>> as is, LLM output is a derived work of stolen human work, scraped >>> and used without permission, often as DDOS. >>> >>> On the basis of each reason, I believe the policy about LLM should just >>> be "no". >>> _______________________________________________ >>> 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 r.aguilar at utwente.nl Wed Feb 11 01:07:07 2026 From: r.aguilar at utwente.nl (Aguilar Bolivar, Rosa (UT-ITC)) Date: Wed, 11 Feb 2026 09:07:07 +0000 Subject: [QGIS-Developer] Looking for consortium - Call 03 - single stage (2026) (HORIZON-CL6-2026-03) In-Reply-To: References: Message-ID: Dear all, I am interested in joining a potential consortium targeting the Horizon call HORIZON-CL6-2026-03-GOVERNANCE-06 - A services and business incubator for geospatial open-source developments https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/opportunities/topic-details/HORIZON-CL6-2026-03-GOVERNANCE-06 While I am not aiming at leading the project, I could contribute either as work package leader or individual expert. Please reach out if you are considering applying and could imagine working together ?. Best regards, Rosa Dr. Rosa Aguilar | Assistant Professor | University of Twente | Faculty of Geo-Information Science and Earth Observation| Campus University of Twente, Building Langezijds, room 1322, P.O. Box 217, 7500 AE Enschede, The Netherlands | T: +31 (0)53 487 4567 | r.aguilar at utwente.nl | https://www.itc.nl/ | Connect with me on LinkedIn https://rosaguilar.github.io| The essential is invisible to the eye. Saint-Exup?ry [https://www.itc.nl/.uc/fa375379b01021d625f0083ea0d0312ee46ec8ddd8df800/UT%20ITC%20logo%20RGB.jpg] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 318796 bytes Desc: image001.jpg URL: From wonder.sk at gmail.com Wed Feb 11 07:03:56 2026 From: wonder.sk at gmail.com (Martin Dobias) Date: Wed, 11 Feb 2026 16:03:56 +0100 Subject: [QGIS-Developer] [Poll created] Re: "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: <77d5ef0b-16d6-4703-8b28-d2cdbdf1104f@oslandia.com> References: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> <2a83f100-2eca-4008-ae62-83f90bc8607c@spatialys.com> <77d5ef0b-16d6-4703-8b28-d2cdbdf1104f@oslandia.com> Message-ID: Hi all My perspective on AI tools is that it's just another tool in a developer's toolbox, just like a debugger or a code analyzer. There are lots of unknowns about the training data, I agree. But being conservative and adopting a strict no AI tools policy seems like restricting ourselves from using the best tools for the job. In the end, it is still the responsibility of the developer to ensure their contribution is correct, and not violating copyright, whether they use AI tools or not. It is also hard to draw a line for a conservative "no AI" policy: - is it acceptable to brainstorm design with AI? - is it acceptable to get a prototype built with AI, for inspiration? - is it acceptable to get AI to check code for bugs? - is it acceptable to ask AI to improve tone of my reviews? With strict no AI policy, I guess we would also need to make sure that all of the 50+ dependencies also have strict no AI policy, otherwise QGIS builds could still in theory contain AI-generated copyrighted code? I am not sure that is realistic... Let's be pragmatic: AI tools are here to stay, we can either ignore them, or we can learn to use them responsibly to deliver even more QGIS goodness :-) And we can expect that with the increased risk of copyright issues, there will be automated tools to scan the code for possible copyright problems, integrated in CI, which will flag any risky contributions. Cheers Martin On Tue, Feb 10, 2026 at 6:06?PM Vincent Picavet via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hello, > > On 07/02/2026 00:30, Even Rouault wrote: > > Thanks for your feedback. Yes copyright / IP issues are a tricky problem > to deal with and you make good points on how things could go wrong. That > said, in practice I believe most generated code would be mostly derived > from QGIS itself, QT code or doc or be non-copyrightable material. I can > > I seriously doubt that, given the amount of copyrighted material that has > already been used to train LLMs. And most important, we have no way to know > that, except if the LLM companies get subpoenaed and disclose hidden > practices when asked in court. > > Believing is not enough when talking about legal stuff. > > > imagine though that contributions including non-trivial algorithms could > possibly be infringing copyright. In that situation, the reviewers could > ask the > Even simpler code can be plagiarized, not only non-trivial algorithms. > > submitter to bring more light on the provenance of such code (the > contributor may ask the LLM to dig for references for the provenance and > check they are OK with GPL2 inclusion, being aware that the LLM could > hallucinate them...), and if no satisfactory answer is given, reject the > contribution. But that can be admitedly hard to spot for reviewers. I'd be > happy to amend the QEP with that if someone can propose an adequate > formulation. > Again, a reviewer has no way to know or imagine that a code has been > plagiarized : you would have to be aware of the full training dataset of > the LLM, and this is 1. behind closed fences 2. not humanly possible. > > I've doubts a "no AI" policy is achievable in practice, or people will > lie. As you mention, we can require people to mention the tool they have > used, possibly the prompt(s) they use, which manual modifications they > applied on top of that. Doesn't the paragraph starting at line 35 ( > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/changes#diff-4f4102e51f04fdfc82e843c6942abe9965c03ac85a92e9becf21bcca8b5571adR35) > cover enough your point about "have a mandatory mention and description of > LLM usage for each contribution" ? > > Lying about not using AI is just like lying about being sure one has the > right to contribute the code ( see contributor's agreement ) : if this is a > rule, we ask people and they lie, then we should also have sanctions and be > strict about it. > > For me, full transparency about usage of a blackbox **for code > generation** is not enough as a protection against legal matters. For > anything else that can be AI-aided, this is more about resiliency, > transparency and trust, and we should make it clear that explaining exactly > how AI has been used is mandatory and should be given along every > contribution. > > > The main driver for this QEP was to give us a tool to be able to quickly > reject sloppy contributions with a solid reference to back our decisions, > but we must indeed decide whether we go further than this. > > I guess there is matter to debate and a lot of uncertainty. Hence the > conservative approach, to avoid the worst and maybe open it later on > whenever we see the situation clearer. > > > For that purpose, I've created a quick poll at > https://docs.google.com/forms/d/e/1FAIpQLSdnVWoD5DrwCbNXqPqHsLw2jfbLkPMKBkvfyQfTQOPZkj_EaQ/viewform > so we can gather opinions on the general direction we want on that subject. > All, please fill! > > Ok to gather more advice, thanks for running the poll, > > > Vincent > > > > > Even > > > > Le 06/02/2026 ? 18:01, Vincent Picavet via QGIS-Developer a ?crit : > >> Hi, > >> > >> I would double-down on Greg Troxel's advice concerning copyright > issues, especially concerning the introduction of LLM-generated code into > QGIS codebase. > >> > >> Opensource's success is based on these main characteristics : quality, > security, trust. > >> > >> AI contributions pose a threat to quality, security and trust alike. > >> > >> A human-in-the-loop policy for contributions written with AI may help > for quality and security issues, but will still leaves a huge problem for > trust. > >> > >> Among the various aspects of trust, what worries me most right now is > the copyright issue. OpenSource software is based on intellectual property > laws, and especially on copyright, to be able to derive copyleft and grant > more rights to end-users. > >> > >> End-user trust opensource software from a legal point of view because : > >> > >> - they are backed by well-established copyright laws > >> > >> - they have clear and well established end-users contracts ( opensource > licences ) > >> > >> - they have a full record of modifications of the source code, hence a > full lineage and certification of IP rights for the code > >> > >> - also, foundations like OSGeo additionnaly put a stamp on the software > to guarantee that process and initial IP can be trusted enough to have a > legal insurance concerning the software > >> > >> Introducing IA black boxes into the development process breaks the > ability to control the lineage of the code and guarantee that it is a > genuine invention, and therefore allowed to be licenced under the GPL. > >> > >> For quality and security, a developer can always intrinsically assess > that the generated code has the required level of quality, and that it does > not include any security flaw. > >> > >> But **there is no way for a developer to evaluate the IP rights on a > code generated by a LLM**. How would one do it, since the code has been > generated through a total opaque black box ingesting non-identified > enormous volumes of data ? > >> > >> Today, we definitely know that LLMs ( ChatGPT, Claude and others ) have > been trained on illegal copyrighted material. It is proven that they > trained LLMs on pirated books. Furthermore, every time someone complaints > about IP violation by LLM, big corps settle a financial arrangement with > the copyright owners and move on. > >> > >> There is therefore no doubt that they have also trained LLMs on > proprietary code. And also on opensource code not compliant with GPLv2+. > >> > >> Big corp. currently hide behind a "fair use" argument, but this is > clearly rubbish, otherwise why would they bother to settle large financial > deals with copyright owners ? > >> > >> So, LLM-generated code contributed to QGIS will at some point be > plagiarized from random code available on the internet, and neither > QGIS.org nor the contributor will be able to know. > >> > >> If we start accepting such code without being able to check provenance > or copyright issues, it will end up buried deep inside QGIS, and the day we > will discover that it infringes copyright, it will be a nightmare to solve > : in this case we will want to revert all incriminated code, and also all > code depending on the plagiarized code **and have it rewritten from scratch > by someone who has never read the plagiarized code** ( ref : SCO/UNIX for > example ). This is almost impossible. > >> > >> This would be a nightmare, just for one identified contribution. > >> > >> Even more, if/when the fair-use principle of LLMs falls down, then all > LLM-generated code should be removed from QGIS, and all code depending on > it. This is a really high risk with high impact. > >> > >> You may say : "ok but everyone does it, the chances of being caught are > low, why not benefit from the opportunity ?" > >> > >> Then what about "everyone copies GPL code into proprietary code, the > chances of being caught are low, why not benefit from the opportunity ?" > >> > >> Copyright is at the foundation of OpenSource software, and especially > GPL-based software. If we choose to deny it, then we loose our core > principle. > >> > >> In the text Even propose, there is a copyright section, pushing the > responsibility of IP compliance control back to the contributor. It may > protect QGIS.org or other developers from being sued whenever there is a > problem, or they could sue back the faulty contributor, but this is not > enough : > >> > >> - the faulty contributor has no way to ensure his generated code has no > IP issue ( other than NOT using LLMs ) : responsibility without any mean of > action is not fair and sustainable > >> > >> - even if the QGIS projet can avoid being convicted by transferring > responsibility, then the situation would still be open and be a nightmare : > removing plagiarized code entangled down the core of the software and all > its dependency code, and rewrite it without IP issue is really hard > >> > >> Therefore, I do not think this mention is enough for IP protection. > >> > >> This rationale concerns the generated code itself, contributed to QGIS > or other software in the ecosystem. LLMs may be useful and without IP risks > to help find bugs, write parts of documentations where there is no risk of > plagiarism, or other use cases. > >> > >> But I would definitely **forbid any generated code to be introduced > into the main source code because of IP risk**. > >> > >> Also, the least we can do for any contribution, is not only to have a > human in the loop, but also to have a mandatory mention and description of > LLM usage for each contribution. This would at least give traceability. It > does not solve anything, but in case of a problem, we could at least start > to investigate. > >> > >> A am glad this conversation takes place, and willing to pursue the > discussion, sorry for having been long. > >> > >> Have a nice weekend, > >> > >> Vincent > >> > >> > >> > >> > >> > >> On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: > >>> I would suggest a much stronger policy: > >>> > >>> no LLM-generated code or discussion may be submitted to any QGIS > forum > >>> > >>> > >>> The idea that LLM-generated code has been "reviewed" intends to be that > >>> it is of high enough quality that it is reasonable for *humans* to > spend > >>> time reviewing it. But I don't believe that asking that it be reviewed > >>> will achieve that in practice. > >>> > >>> I've already had the experience (in a different project) of seeing a > >>> posted PR(ish, patch on list), taking the time to comment, and getting > >>> LLM-generated (vacuous) replies to my comments. > >>> > >>> Besides the ethical problems with asking humans to review, improve, > >>> judge or in any other way pay attention to LLM output, there's the > >>> problem of copyright. While machine-generated text isn't copyrightable > >>> as is, LLM output is a derived work of stolen human work, scraped > >>> and used without permission, often as DDOS. > >>> > >>> On the basis of each reason, I believe the policy about LLM should just > >>> be "no". > >>> _______________________________________________ > >>> 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 > On Tue, Feb 10, 2026 at 6:06?PM Vincent Picavet via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hello, > > On 07/02/2026 00:30, Even Rouault wrote: > > Thanks for your feedback. Yes copyright / IP issues are a tricky problem > to deal with and you make good points on how things could go wrong. That > said, in practice I believe most generated code would be mostly derived > from QGIS itself, QT code or doc or be non-copyrightable material. I can > > I seriously doubt that, given the amount of copyrighted material that has > already been used to train LLMs. And most important, we have no way to know > that, except if the LLM companies get subpoenaed and disclose hidden > practices when asked in court. > > Believing is not enough when talking about legal stuff. > > > imagine though that contributions including non-trivial algorithms could > possibly be infringing copyright. In that situation, the reviewers could > ask the > Even simpler code can be plagiarized, not only non-trivial algorithms. > > submitter to bring more light on the provenance of such code (the > contributor may ask the LLM to dig for references for the provenance and > check they are OK with GPL2 inclusion, being aware that the LLM could > hallucinate them...), and if no satisfactory answer is given, reject the > contribution. But that can be admitedly hard to spot for reviewers. I'd be > happy to amend the QEP with that if someone can propose an adequate > formulation. > Again, a reviewer has no way to know or imagine that a code has been > plagiarized : you would have to be aware of the full training dataset of > the LLM, and this is 1. behind closed fences 2. not humanly possible. > > I've doubts a "no AI" policy is achievable in practice, or people will > lie. As you mention, we can require people to mention the tool they have > used, possibly the prompt(s) they use, which manual modifications they > applied on top of that. Doesn't the paragraph starting at line 35 ( > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/changes#diff-4f4102e51f04fdfc82e843c6942abe9965c03ac85a92e9becf21bcca8b5571adR35) > cover enough your point about "have a mandatory mention and description of > LLM usage for each contribution" ? > > Lying about not using AI is just like lying about being sure one has the > right to contribute the code ( see contributor's agreement ) : if this is a > rule, we ask people and they lie, then we should also have sanctions and be > strict about it. > > For me, full transparency about usage of a blackbox **for code > generation** is not enough as a protection against legal matters. For > anything else that can be AI-aided, this is more about resiliency, > transparency and trust, and we should make it clear that explaining exactly > how AI has been used is mandatory and should be given along every > contribution. > > > The main driver for this QEP was to give us a tool to be able to quickly > reject sloppy contributions with a solid reference to back our decisions, > but we must indeed decide whether we go further than this. > > I guess there is matter to debate and a lot of uncertainty. Hence the > conservative approach, to avoid the worst and maybe open it later on > whenever we see the situation clearer. > > > For that purpose, I've created a quick poll at > https://docs.google.com/forms/d/e/1FAIpQLSdnVWoD5DrwCbNXqPqHsLw2jfbLkPMKBkvfyQfTQOPZkj_EaQ/viewform > so we can gather opinions on the general direction we want on that subject. > All, please fill! > > Ok to gather more advice, thanks for running the poll, > > > Vincent > > > > > Even > > > > Le 06/02/2026 ? 18:01, Vincent Picavet via QGIS-Developer a ?crit : > >> Hi, > >> > >> I would double-down on Greg Troxel's advice concerning copyright > issues, especially concerning the introduction of LLM-generated code into > QGIS codebase. > >> > >> Opensource's success is based on these main characteristics : quality, > security, trust. > >> > >> AI contributions pose a threat to quality, security and trust alike. > >> > >> A human-in-the-loop policy for contributions written with AI may help > for quality and security issues, but will still leaves a huge problem for > trust. > >> > >> Among the various aspects of trust, what worries me most right now is > the copyright issue. OpenSource software is based on intellectual property > laws, and especially on copyright, to be able to derive copyleft and grant > more rights to end-users. > >> > >> End-user trust opensource software from a legal point of view because : > >> > >> - they are backed by well-established copyright laws > >> > >> - they have clear and well established end-users contracts ( opensource > licences ) > >> > >> - they have a full record of modifications of the source code, hence a > full lineage and certification of IP rights for the code > >> > >> - also, foundations like OSGeo additionnaly put a stamp on the software > to guarantee that process and initial IP can be trusted enough to have a > legal insurance concerning the software > >> > >> Introducing IA black boxes into the development process breaks the > ability to control the lineage of the code and guarantee that it is a > genuine invention, and therefore allowed to be licenced under the GPL. > >> > >> For quality and security, a developer can always intrinsically assess > that the generated code has the required level of quality, and that it does > not include any security flaw. > >> > >> But **there is no way for a developer to evaluate the IP rights on a > code generated by a LLM**. How would one do it, since the code has been > generated through a total opaque black box ingesting non-identified > enormous volumes of data ? > >> > >> Today, we definitely know that LLMs ( ChatGPT, Claude and others ) have > been trained on illegal copyrighted material. It is proven that they > trained LLMs on pirated books. Furthermore, every time someone complaints > about IP violation by LLM, big corps settle a financial arrangement with > the copyright owners and move on. > >> > >> There is therefore no doubt that they have also trained LLMs on > proprietary code. And also on opensource code not compliant with GPLv2+. > >> > >> Big corp. currently hide behind a "fair use" argument, but this is > clearly rubbish, otherwise why would they bother to settle large financial > deals with copyright owners ? > >> > >> So, LLM-generated code contributed to QGIS will at some point be > plagiarized from random code available on the internet, and neither > QGIS.org nor the contributor will be able to know. > >> > >> If we start accepting such code without being able to check provenance > or copyright issues, it will end up buried deep inside QGIS, and the day we > will discover that it infringes copyright, it will be a nightmare to solve > : in this case we will want to revert all incriminated code, and also all > code depending on the plagiarized code **and have it rewritten from scratch > by someone who has never read the plagiarized code** ( ref : SCO/UNIX for > example ). This is almost impossible. > >> > >> This would be a nightmare, just for one identified contribution. > >> > >> Even more, if/when the fair-use principle of LLMs falls down, then all > LLM-generated code should be removed from QGIS, and all code depending on > it. This is a really high risk with high impact. > >> > >> You may say : "ok but everyone does it, the chances of being caught are > low, why not benefit from the opportunity ?" > >> > >> Then what about "everyone copies GPL code into proprietary code, the > chances of being caught are low, why not benefit from the opportunity ?" > >> > >> Copyright is at the foundation of OpenSource software, and especially > GPL-based software. If we choose to deny it, then we loose our core > principle. > >> > >> In the text Even propose, there is a copyright section, pushing the > responsibility of IP compliance control back to the contributor. It may > protect QGIS.org or other developers from being sued whenever there is a > problem, or they could sue back the faulty contributor, but this is not > enough : > >> > >> - the faulty contributor has no way to ensure his generated code has no > IP issue ( other than NOT using LLMs ) : responsibility without any mean of > action is not fair and sustainable > >> > >> - even if the QGIS projet can avoid being convicted by transferring > responsibility, then the situation would still be open and be a nightmare : > removing plagiarized code entangled down the core of the software and all > its dependency code, and rewrite it without IP issue is really hard > >> > >> Therefore, I do not think this mention is enough for IP protection. > >> > >> This rationale concerns the generated code itself, contributed to QGIS > or other software in the ecosystem. LLMs may be useful and without IP risks > to help find bugs, write parts of documentations where there is no risk of > plagiarism, or other use cases. > >> > >> But I would definitely **forbid any generated code to be introduced > into the main source code because of IP risk**. > >> > >> Also, the least we can do for any contribution, is not only to have a > human in the loop, but also to have a mandatory mention and description of > LLM usage for each contribution. This would at least give traceability. It > does not solve anything, but in case of a problem, we could at least start > to investigate. > >> > >> A am glad this conversation takes place, and willing to pursue the > discussion, sorry for having been long. > >> > >> Have a nice weekend, > >> > >> Vincent > >> > >> > >> > >> > >> > >> On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: > >>> I would suggest a much stronger policy: > >>> > >>> no LLM-generated code or discussion may be submitted to any QGIS > forum > >>> > >>> > >>> The idea that LLM-generated code has been "reviewed" intends to be that > >>> it is of high enough quality that it is reasonable for *humans* to > spend > >>> time reviewing it. But I don't believe that asking that it be reviewed > >>> will achieve that in practice. > >>> > >>> I've already had the experience (in a different project) of seeing a > >>> posted PR(ish, patch on list), taking the time to comment, and getting > >>> LLM-generated (vacuous) replies to my comments. > >>> > >>> Besides the ethical problems with asking humans to review, improve, > >>> judge or in any other way pay attention to LLM output, there's the > >>> problem of copyright. While machine-generated text isn't copyrightable > >>> as is, LLM output is a derived work of stolen human work, scraped > >>> and used without permission, often as DDOS. > >>> > >>> On the basis of each reason, I believe the policy about LLM should just > >>> be "no". > >>> _______________________________________________ > >>> 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: From julien.cabieces at oslandia.com Thu Feb 12 09:12:02 2026 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Thu, 12 Feb 2026 18:12:02 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: (Martin Dobias via's message of "Wed, 4 Feb 2026 22:17:20 +0100") References: Message-ID: <87ecmpevj1.fsf@julienlaptop.home> Hi Martin, Thank you for raising this important topic. I'm no expert in 3D, so my concerns are mainly about software developement general matters. I'm a bit afraid about moving from a Qt deprecated module to another Qt semi-private module where the documentation clearly state that the API is unstable [0] "[...] the API is only guaranteed to work with the Qt version the application was developed against. Source incompatible changes are however aimed to be kept at a minimum and will only be made in minor releases (6.7, 6.8, and so on)." That could lead to constant rework to adapt our code to their API modifications, and would require to support all different API versions because we don't control what Qt version is shipped in Linux distribution. We have no garantee that this API would become public one day, or that it would not be dropped/reworked completely. I read here [1] that Qt 3D "has for most use cases by now been superseded by Qt Quick 3D". Would it be possible to port our code to Qt Quick 3D? Or is it too limited for what we try to achieve? Finally, I imagine that moving to a low level dependency would force us to develop state of the art 3D features like you point it out in your mail, leading to increased developement costs. If we choose to move away from Qt 3D, shall we not move to a high level API 3D engine ? Kind regards, Julien [0] https://doc.qt.io/qt-6/qrhi.html#details [1] https://lists.qt-project.org/pipermail/development/2024-March/045127.html > Hi all > > As you know, 3D map views in QGIS are based on the Qt 3D module. Since Qt 6.8 (released in Oct 2024) the Qt 3D module is marked as > deprecated [1]. This does not mean that it will be removed anytime soon, but there's no development planned by the Qt company. There has > been very little development in Qt 3D in recent years and little adoption within wider Qt community. > > A question naturally comes up - what should we do within the QGIS project? Stay with Qt 3D or start moving towards something else? > > At Lutra, we have started some internal discussions about this. Qt 3D does its job, but we find it often over-complicated (e.g. framegraph, > entity-component-system scene representation) and under-documented. And with the lack of direct access to graphics APIs we have > accumulated various workarounds and bugs that are difficult to fix. > > If we wanted to switch to something else, there are lots of options: from the very low-level wrappers around graphics APIs all the way to full > blown 3D rendering engines for games. > > At this point, QRhi [2] looks like an interesting option. QRhi is a part of Qt GUI module and it is a relatively low-level abstraction on top of > modern graphics APIs (Metal, Vulkan, Direct3D). It is already being used under the hood by Qt Quick and Qt Quick 3D (and optionally also by Qt > 3D). It is kind of semi-private API of Qt GUI module, but it is well documented and the API has been quite stable despite the lack of > source/binary compatibility guarantees. > > With a low-level approach like QRhi we would get a lot of control, at the expense of having to roll out our own abstractions that Qt 3D provides > (e.g. camera, geometry, material, scene graph). > > I would love to hear some thoughts from other QGIS devs about the possible migration away from Qt 3D. If there will be consensus, we can > then start working on a QEP and prepare a more detailed plan. > > Regards > Martin > > [1] https://doc.qt.io/qt-6/whatsnew68.html > [2] https://doc.qt.io/qt-6/qrhi.html > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From wonder.sk at gmail.com Thu Feb 12 14:23:04 2026 From: wonder.sk at gmail.com (Martin Dobias) Date: Thu, 12 Feb 2026 23:23:04 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: <87ecmpevj1.fsf@julienlaptop.home> References: <87ecmpevj1.fsf@julienlaptop.home> Message-ID: Hi Julien Thanks for your response. On Thu, Feb 12, 2026 at 5:12?PM Julien Cabieces < julien.cabieces at oslandia.com> wrote: > > I'm no expert in 3D, so my concerns are mainly about > software developement general matters. > > I'm a bit afraid about moving from a Qt deprecated module to another Qt > semi-private module > where the documentation clearly state that the API is unstable [0] > > "[...] the API is only guaranteed to work with the Qt version the > application > was developed against. Source incompatible changes are however aimed to be > kept at a minimum and will only be made in minor releases (6.7, 6.8, and so > on)." > > That could lead to constant rework to adapt our code to their API > modifications, and would require to support all different API versions > because we don't control what Qt version is shipped in Linux distribution. > > We have no garantee that this API would become public one day, or that > it would not be dropped/reworked completely. > I do not see a problem with source incompatible changes in QRhi in minor Qt releases: - direct QRhi interaction would be limited to a small area of code with low level abstraction - incompatible changes can be dealt with a bunch of #ifdefs - Qt promises such changes to be kept at minimum. At this point, QRhi and Qt Quick on top of it are quite stable, so I don't see why they would suddenly do some large changes. I read here [1] that Qt 3D "has for most use cases by now been > superseded by Qt Quick 3D". Would it be possible to port our code to Qt > Quick 3D? Or is it too limited for what we try to achieve? > Qt Quick 3D is too limited. For a start, it has fixed rendering pipeline, more limited to what we already have in QGIS 3D. Then, there's only little support for C++ and most of APIs are simply QML-only. The claim about "most use cases" in the Qt mailing list was likely about use cases they had in mind, not _all_ use cases for a 3D engine :-) Finally, I imagine that moving to a low level dependency would force us to > develop > state of the art 3D features like you point it out in your mail, > leading to increased developement costs. If we choose > to move away from Qt 3D, shall we not move to a high level API 3D engine > ? > Bits like camera, material system, geometry primitives and a scene graph - that's standard 3D engine stuff really which has been done many times... High level 3D engines are certainly something to consider as well, and I have evaluated a couple of them. Overall my impression was that those are generally massive pieces of software with lots of new dependencies, that are generally not built for being embedded in existing applications. (e.g. Godot, O3DE) I would be happy to hear any recommendations for higher level 3D engines that would be easy to embed! Cheers Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Feb 12 14:34:21 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 12 Feb 2026 23:34:21 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: References: <87ecmpevj1.fsf@julienlaptop.home> Message-ID: Hi, > High level 3D engines are certainly something to consider as well, and > I have evaluated a couple of them. Overall my impression was that > those are generally massive pieces of software with lots of new > dependencies, that are generally not built for being embedded in > existing applications. (e.g. Godot, O3DE) I would be happy to hear any > recommendations for higher level 3D engines that would be easy to embed! Not necessarily a recommendation, but there's also Ogre3D (https://www.ogre3d.org/). In a project in a previous life (~15 years ago) we used it for flight preview.? If I remember well, there was no terrain tile loader shipped with the engine, but we plugged one. We didn't have lots of objects, a few OBJs, so not sure how that would behave with big models. At the time we used it through a GTK integration, but there's apparently a Qt one: https://ogrecave.github.io/ogre/api/latest/class_ogre_bites_1_1_application_context_qt.html Even -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dvdkon at konarici.cz Thu Feb 12 15:22:54 2026 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Fri, 13 Feb 2026 00:22:54 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: References: <87ecmpevj1.fsf@julienlaptop.home> Message-ID: <1d20f47f-b32b-48dd-b225-0db7525ab83c@konarici.cz> On 2/12/26 23:34, Even Rouault via QGIS-Developer wrote: > Hi, >> High level 3D engines are certainly something to consider as well, and >> I have evaluated a couple of them. Overall my impression was that >> those are generally massive pieces of software with lots of new >> dependencies, that are generally not built for being embedded in >> existing applications. (e.g. Godot, O3DE) I would be happy to hear any >> recommendations for higher level 3D engines that would be easy to embed! > > Not necessarily a recommendation, but there's also Ogre3D (https:// > www.ogre3d.org/). In a project in a previous life (~15 years ago) we > used it for flight preview.? If I remember well, there was no terrain > tile loader shipped with the engine, but we plugged one. We didn't have > lots of objects, a few OBJs, so not sure how that would behave with big > models. At the time we used it through a GTK integration, but there's > apparently a Qt one: https://ogrecave.github.io/ogre/api/latest/ > class_ogre_bites_1_1_application_context_qt.html Hi, you're right that 3D engines in a library form do exist, but sadly as far as I know they are mostly rather old. Ogre3D, Irrlicht, OpenSceneGraph are all products of the OpenGL 2 era, but nowadays our targets should be Vulkan and Metal, with very different paradigms. There is OGRE-Next and VulkanSceneGraph (which even has some GIS-esque examples). I can't say right now how well they'd integrate with our existing Qt-heavy codebase or how much of their code we'd use, though. That's always a question when including a new C++ library. Personally I think writing our own 3D view on top of a low-level API like QRhi or WebGPU is preferable to using a library that's not a good fit, but maybe there already exists one that would be a right for us, I just haven't seen it yet. David Ko?a??k From johannes.kroeger at wheregroup.com Thu Feb 12 23:43:49 2026 From: johannes.kroeger at wheregroup.com (=?UTF-8?Q?Johannes_Kr=C3=B6ger_=28WhereGroup=29?=) Date: Fri, 13 Feb 2026 08:43:49 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: References: <87ecmpevj1.fsf@julienlaptop.home> Message-ID: On 2/12/26 23:23, Martin Dobias via QGIS-Developer wrote: > I would be happy to hear any recommendations for higher level 3D > engines that would be easy to embed! Two engines from my bookmarks that might be interesting. I know little about the topic in relation to what QGIS would need though :) - https://github.com/bkaradzic/bgfx - https://o3de.org/ Open 3D Engine (O3DE), might not be easy to embed Cheers, Hannes From raphael.dasgupta at ost.ch Fri Feb 13 02:29:00 2026 From: raphael.dasgupta at ost.ch (Raphael Das Gupta) Date: Fri, 13 Feb 2026 11:29:00 +0100 Subject: [QGIS-Developer] How does one deprecate a plugin correctly? Message-ID: <8dd8c218-3ed1-4fe6-8aad-1ade023e660d@ost.ch> Dear all How does one deprecate one of one's own plugins correctly? * Should I set deprecated=True in metadata.txt and re-upload the plugin? o If so, should I also bump the version number, or upload a thusly changed copy of the so-far latest version? * Should I "Edit" the plugin on https://plugins.qgis.org/plugins/my and check the "Deprecated" checkbox? * Does it matter whether I do just one of those or both? Is the process documented anywhere? I couldn't find detailed instructions for this. Best regards, Raphael -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrmorreale_ml at enoreth.net Fri Feb 13 03:46:21 2026 From: jrmorreale_ml at enoreth.net (Jean-Roc Morreale) Date: Fri, 13 Feb 2026 12:46:21 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: References: <87ecmpevj1.fsf@julienlaptop.home> Message-ID: <77a35d4393424032ee845673652dc7022fc78487.camel@enoreth.net> Le jeudi 12 f?vrier 2026 ? 23:34 +0100, Even Rouault via QGIS-Developer a ?crit?: > ?Hi, > > ? > > High level 3D engines are certainly something to consider as well, > > and I have evaluated a couple of them. Overall my impression was > > that those are generally massive pieces of software with lots of > > new dependencies, that are generally not built for being embedded > > in existing applications. (e.g. Godot, O3DE) I would be happy to > > hear any recommendations for higher level 3D engines that would be > > easy to embed! > > ? > ? > Not necessarily a recommendation, but there's also Ogre3D > (https://www.ogre3d.org/). In a project in a previous life (~15 years > ago) we used it for flight preview.? If I remember well, there was no > terrain tile loader shipped with the engine, but we plugged one. We > didn't have lots of objects, a few OBJs, so not sure how that would > behave with big models. At the time we used it through a GTK > integration, but there's apparently a Qt > one:https://ogrecave.github.io/ogre/api/latest/class_ogre_bites_1_1_a > pplication_context_qt.html > ? > Even > ? Hi, may I suggest having a look at Kiware's VTK ? It's C++ with JS/WASM ports, been for 3 decades, not tied to the Qt Company but used with Qt-enabled softwares covering GIS/point cloud/volumetric usecases. From dvdkon at konarici.cz Fri Feb 13 04:08:21 2026 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Fri, 13 Feb 2026 13:08:21 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: References: <87ecmpevj1.fsf@julienlaptop.home> Message-ID: <1de62679-1380-4013-a514-e56a4c8a9a2c@konarici.cz> Hi, thanks for the links. On 2/13/26 08:43, Johannes Kr?ger (WhereGroup) via QGIS-Developer wrote: > Two engines from my bookmarks that might be interesting. I know little > about the topic in relation to what QGIS would need though :) > > - https://github.com/bkaradzic/bgfx bgfx might be an option. It is on a similar abstraction level as QRhi from what I can see. > - https://o3de.org/ Open 3D Engine (O3DE), might not be easy to embed O3DE is a full "game engine" with a lot of functionality that we don't need, meant to run standalone scenes made in their editor. Maybe we could use some of their code, but given the size of their codebase, I think it would be more trouble than it's worth. David Ko?a??k From gdt at lexort.com Fri Feb 13 05:33:54 2026 From: gdt at lexort.com (Greg Troxel) Date: Fri, 13 Feb 2026 08:33:54 -0500 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: ("Johannes =?utf-8?Q?Kr=C3=B6ger?= (WhereGroup) via QGIS-Developer"'s message of "Fri, 13 Feb 2026 08:43:49 +0100") References: <87ecmpevj1.fsf@julienlaptop.home> Message-ID: "Johannes Kr?ger (WhereGroup) via QGIS-Developer" writes: > Two engines from my bookmarks that might be interesting. I know little > about the topic in relation to what QGIS would need though :) Not about your suggestions, but we should think about portability. QGIS runs on a lot of places, not just the tri(mono)culture of GNU/Linux, macOS, windows. Also several BSDs and really it should work on illumos (don't know). Projects vary in home they approach portability, on one hand understanding POSIX and sticking to it, and at the other extreme being hostile to building the project on any system they don't have on their list of important systems. Thus, for any candidate library, I think we should ensure that their portability stance is at least as good as QGIS's, and definitely reasonably taking patches to fix portabilty bugs. From vincent.ml at oslandia.com Sat Feb 14 01:49:00 2026 From: vincent.ml at oslandia.com (Vincent Picavet) Date: Sat, 14 Feb 2026 10:49:00 +0100 Subject: [QGIS-Developer] [Poll created] Re: "Human In The Loop" Policy For AI/Tool-Assisted Contributions In-Reply-To: References: <556b38ab-0d35-444c-bd3e-8ba6708cb4db@oslandia.com> <2a83f100-2eca-4008-ae62-83f90bc8607c@spatialys.com> <77d5ef0b-16d6-4703-8b28-d2cdbdf1104f@oslandia.com> Message-ID: <3468014a-4195-4a30-8778-e54243606d19@oslandia.com> Hello, On 11/02/2026 16:03, Martin Dobias wrote: > Hi all > > My perspective on AI tools is that it's just another tool in a developer's toolbox, just like a debugger or a code analyzer. AI tools - LLMs have very specific characteristics? which are important to take into account : cost, transparency, vendor lock-in, social and environmental impacts to just cite a few aspects, are totally different for LLMs than for other tools like a debugger or code analyzer. Having a developer-centric approach to tooling would most probably leads us to choices not compatible with our global missions and views. > There are lots of unknowns about the training data, I agree. But being conservative and adopting a strict no AI tools policy seems like restricting ourselves from using the best tools for the job. In the end, it is still the responsibility of the developer to ensure their contribution is correct, and not violating copyright, whether they use AI tools or not. I have not been talking about a strict No-AI policy. I am saying that **code generation** by LLM pose an existential threat to OpenSource projects like QGIS. AI tools may be useful for other tasks than code generation. Again, pushing the responsibility to individual contributors would be very hypocritical : there is **no way** for anyone to assess the correctness of a contribution generated by LLM concerning copyright violation. Putting responsibility on people without giving them means of action and verification is definitely not something we should defend. Quality and security are concerns that can be intrinsically assessed by individuals, IP issues are not. > It is also hard to draw a line for a conservative "no AI" policy: > - is it acceptable to brainstorm design with AI? > - is it acceptable to get a prototype built with AI, for inspiration? > - is it acceptable to get AI to check code for bugs? > - is it acceptable to ask AI to improve tone of my reviews? > > With strict no AI policy, I guess we would also need to make sure that all of the 50+ dependencies also have strict no AI policy, otherwise QGIS builds could still in theory contain AI-generated copyrighted code? I am not sure that is realistic... Again, who has been arguing for a no-AI policy ? There are more balanced policies which can be evaluated. > Let's be pragmatic: AI tools are here to stay, we can either ignore them, or we can learn to use them responsibly to deliver even more QGIS goodness :-) And we can expect that with the increased risk of copyright issues, there will be automated tools to scan the code for possible copyright problems, integrated in CI, which will flag any risky contributions. "AI tools are here to stay" is your own opinion, and an idea LLM companies are trying to convince everyone it is a fact. Given the economy of data centers and LLM companies, this may or may not be true at all. Or at least not at the current costs, which is also a strong issue. To make a comparison, note that there was a time when asbestos was there to stay too. Also "we can expect that... " sounds like magic thoughts, definitely not something we can really count on. We cannot ignore LLM and AI though, and this is why this discussion takes place. Also, I saw an affirmation about "fair use" being the default legal position in the US right now. This is again what the 7 magnificents want you to believe, but actual analysis for the US congress is far away from this statement : https://www.congress.gov/crs_external_products/LSB/PDF/LSB10922/LSB10922.8.pdf Last but not least, let me point to the latest development of "AI contributions to OpenSource" : https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/ We are living interesting times? Vincent > > Cheers > Martin > > > On Tue, Feb 10, 2026 at 6:06?PM Vincent Picavet via QGIS-Developer wrote: > > Hello, > > On 07/02/2026 00:30, Even Rouault wrote: > > Thanks for your feedback. Yes copyright / IP issues are a tricky problem to deal with and you make good points on how things could go wrong. That said, in practice I believe most generated code would be mostly derived from QGIS itself, QT code or doc or be non-copyrightable material. I can > > I seriously doubt that, given the amount of copyrighted material that has already been used to train LLMs. And most important, we have no way to know that, except if the LLM companies get subpoenaed and disclose hidden practices when asked in court. > > Believing is not enough when talking about legal stuff. > > > imagine though that contributions including non-trivial algorithms could possibly be infringing copyright. In that situation, the reviewers could ask the > Even simpler code can be plagiarized, not only non-trivial algorithms. > > submitter to bring more light on the provenance of such code (the contributor may ask the LLM to dig for references for the provenance and check they are OK with GPL2 inclusion, being aware that the LLM could hallucinate them...), and if no satisfactory answer is given, reject the contribution. But that can be admitedly hard to spot for reviewers. I'd be happy to amend the QEP with that if someone can propose an adequate formulation. > Again, a reviewer has no way to know or imagine that a code has been plagiarized : you would have to be aware of the full training dataset of the LLM, and this is 1. behind closed fences 2. not humanly possible. > > I've doubts a "no AI" policy is achievable in practice, or people will lie.? As you mention, we can require people to mention the tool they have used, possibly the prompt(s) they use, which manual modifications they applied on top of that.? Doesn't the paragraph starting at line 35 (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/changes#diff-4f4102e51f04fdfc82e843c6942abe9965c03ac85a92e9becf21bcca8b5571adR35) cover enough your point about "have a mandatory mention and description of LLM usage for each contribution" ? > > Lying about not using AI is just like lying about being sure one has the right to contribute the code ( see contributor's agreement ) : if this is a rule, we ask people and they lie, then we should also have sanctions and be strict about it. > > For me, full transparency about usage of a blackbox **for code generation** is not enough as a protection against legal matters. For anything else that can be AI-aided, this is more about resiliency, transparency and trust, and we should make it clear that explaining exactly how AI has been used is mandatory and should be given along every contribution. > > > The main driver for this QEP was to give us a tool to be able to quickly reject sloppy contributions with a solid reference to back our decisions, but we must indeed decide whether we go further than this. > > I guess there is matter to debate and a lot of uncertainty. Hence the conservative approach, to avoid the worst and maybe open it later on whenever we see the situation clearer. > > > For that purpose, I've created a quick poll at https://docs.google.com/forms/d/e/1FAIpQLSdnVWoD5DrwCbNXqPqHsLw2jfbLkPMKBkvfyQfTQOPZkj_EaQ/viewform so we can gather opinions on the general direction we want on that subject. All, please fill! > > Ok to gather more advice, thanks for running the poll, > > > Vincent > > > > > Even > > > > Le 06/02/2026 ? 18:01, Vincent Picavet via QGIS-Developer a ?crit?: > >> Hi, > >> > >> I would double-down on Greg Troxel's advice concerning copyright issues, especially concerning the introduction of LLM-generated code into QGIS codebase. > >> > >> Opensource's success is based on these main characteristics : quality, security, trust. > >> > >> AI contributions pose a threat to quality, security and trust alike. > >> > >> A human-in-the-loop policy for contributions written with AI may help for quality and security issues, but will still leaves a huge problem for trust. > >> > >> Among the various aspects of trust, what worries me most right now is the copyright issue. OpenSource software is based on intellectual property laws, and especially on copyright, to be able to derive copyleft and grant more rights to end-users. > >> > >> End-user trust opensource software from a legal point of view because : > >> > >> - they are backed by well-established copyright laws > >> > >> - they have clear and well established end-users contracts ( opensource licences ) > >> > >> - they have a full record of modifications of the source code, hence a full lineage and certification of IP rights for the code > >> > >> - also, foundations like OSGeo additionnaly put a stamp on the software to guarantee that process and initial IP can be trusted enough to have a legal insurance concerning the software > >> > >> Introducing IA black boxes into the development process breaks the ability to control the lineage of the code and guarantee that it is a genuine invention, and therefore allowed to be licenced under the GPL. > >> > >> For quality and security, a developer can always intrinsically assess that the generated code has the required level of quality, and that it does not include any security flaw. > >> > >> But **there is no way for a developer to evaluate the IP rights on a code generated by a LLM**. How would one do it, since the code has been generated through a total opaque black box ingesting non-identified enormous volumes of data ? > >> > >> Today, we definitely know that LLMs ( ChatGPT, Claude and others ) have been trained on illegal copyrighted material. It is proven that they trained LLMs on pirated books. Furthermore, every time someone complaints about IP violation by LLM, big corps settle a financial arrangement with the copyright owners and move on. > >> > >> There is therefore no doubt that they have also trained LLMs on proprietary code. And also on opensource code not compliant with GPLv2+. > >> > >> Big corp. currently hide behind a "fair use" argument, but this is clearly rubbish, otherwise why would they bother to settle large financial deals with copyright owners ? > >> > >> So, LLM-generated code contributed to QGIS will at some point be plagiarized from random code available on the internet, and neither QGIS.org nor the contributor will be able to know. > >> > >> If we start accepting such code without being able to check provenance or copyright issues, it will end up buried deep inside QGIS, and the day we will discover that it infringes copyright, it will be a nightmare to solve : in this case we will want to revert all incriminated code, and also all code depending on the plagiarized code **and have it rewritten from scratch by someone who has never read the plagiarized code** ( ref : SCO/UNIX for example ). This is almost impossible. > >> > >> This would be a nightmare, just for one identified contribution. > >> > >> Even more, if/when the fair-use principle of LLMs falls down, then all LLM-generated code should be removed from QGIS, and all code depending on it. This is a really high risk with high impact. > >> > >> You may say : "ok but everyone does it, the chances of being caught are low, why not benefit from the opportunity ?" > >> > >> Then what about "everyone copies GPL code into proprietary code, the chances of being caught are low, why not benefit from the opportunity ?" > >> > >> Copyright is at the foundation of OpenSource software, and especially GPL-based software. If we choose to deny it, then we loose our core principle. > >> > >> In the text Even propose, there is a copyright section, pushing the responsibility of IP compliance control back to the contributor. It may protect QGIS.org or other developers from being sued whenever there is a problem, or they could sue back the faulty contributor, but this is not enough : > >> > >> - the faulty contributor has no way to ensure his generated code has no IP issue ( other than NOT using LLMs ) : responsibility without any mean of action is not fair and sustainable > >> > >> - even if the QGIS projet can avoid being convicted by transferring responsibility, then the situation would still be open and be a nightmare : removing plagiarized code entangled down the core of the software and all its dependency code, and rewrite it without IP issue is really hard > >> > >> Therefore, I do not think this mention is enough for IP protection. > >> > >> This rationale concerns the generated code itself, contributed to QGIS or other software in the ecosystem. LLMs may be useful and without IP risks to help find bugs, write parts of documentations where there is no risk of plagiarism, or other use cases. > >> > >> But I would definitely **forbid any generated code to be introduced into the main source code because of IP risk**. > >> > >> Also, the least we can do for any contribution, is not only to have a human in the loop, but also to have a mandatory mention and description of LLM usage for each contribution. This would at least give traceability. It does not solve anything, but in case of a problem, we could at least start to investigate. > >> > >> A am glad this conversation takes place, and willing to pursue the discussion, sorry for having been long. > >> > >> Have a nice weekend, > >> > >> Vincent > >> > >> > >> > >> > >> > >> On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: > >>> I would suggest a much stronger policy: > >>> > >>> ?? no LLM-generated code or discussion may be submitted to any QGIS forum > >>> > >>> > >>> The idea that LLM-generated code has been "reviewed" intends to be that > >>> it is of high enough quality that it is reasonable for *humans* to spend > >>> time reviewing it.? But I don't believe that asking that it be reviewed > >>> will achieve that in practice. > >>> > >>> I've already had the experience (in a different project) of seeing a > >>> posted PR(ish, patch on list), taking the time to comment, and getting > >>> LLM-generated (vacuous) replies to my comments. > >>> > >>> Besides the ethical problems with asking humans to review, improve, > >>> judge or in any other way pay attention to LLM output, there's the > >>> problem of copyright.? While machine-generated text isn't copyrightable > >>> as is, LLM output is a derived work of stolen human work, scraped > >>> and used without permission, often as DDOS. > >>> > >>> On the basis of each reason, I believe the policy about LLM should just > >>> be "no". > >>> _______________________________________________ > >>> 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 > > > On Tue, Feb 10, 2026 at 6:06?PM Vincent Picavet via QGIS-Developer wrote: > > Hello, > > On 07/02/2026 00:30, Even Rouault wrote: > > Thanks for your feedback. Yes copyright / IP issues are a tricky problem to deal with and you make good points on how things could go wrong. That said, in practice I believe most generated code would be mostly derived from QGIS itself, QT code or doc or be non-copyrightable material. I can > > I seriously doubt that, given the amount of copyrighted material that has already been used to train LLMs. And most important, we have no way to know that, except if the LLM companies get subpoenaed and disclose hidden practices when asked in court. > > Believing is not enough when talking about legal stuff. > > > imagine though that contributions including non-trivial algorithms could possibly be infringing copyright. In that situation, the reviewers could ask the > Even simpler code can be plagiarized, not only non-trivial algorithms. > > submitter to bring more light on the provenance of such code (the contributor may ask the LLM to dig for references for the provenance and check they are OK with GPL2 inclusion, being aware that the LLM could hallucinate them...), and if no satisfactory answer is given, reject the contribution. But that can be admitedly hard to spot for reviewers. I'd be happy to amend the QEP with that if someone can propose an adequate formulation. > Again, a reviewer has no way to know or imagine that a code has been plagiarized : you would have to be aware of the full training dataset of the LLM, and this is 1. behind closed fences 2. not humanly possible. > > I've doubts a "no AI" policy is achievable in practice, or people will lie.? As you mention, we can require people to mention the tool they have used, possibly the prompt(s) they use, which manual modifications they applied on top of that. Doesn't the paragraph starting at line 35 (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/changes#diff-4f4102e51f04fdfc82e843c6942abe9965c03ac85a92e9becf21bcca8b5571adR35) cover enough your point about "have a mandatory mention and description of LLM usage for each contribution" ? > > Lying about not using AI is just like lying about being sure one has the right to contribute the code ( see contributor's agreement ) : if this is a rule, we ask people and they lie, then we should also have sanctions and be strict about it. > > For me, full transparency about usage of a blackbox **for code generation** is not enough as a protection against legal matters. For anything else that can be AI-aided, this is more about resiliency, transparency and trust, and we should make it clear that explaining exactly how AI has been used is mandatory and should be given along every contribution. > > > The main driver for this QEP was to give us a tool to be able to quickly reject sloppy contributions with a solid reference to back our decisions, but we must indeed decide whether we go further than this. > > I guess there is matter to debate and a lot of uncertainty. Hence the conservative approach, to avoid the worst and maybe open it later on whenever we see the situation clearer. > > > For that purpose, I've created a quick poll at https://docs.google.com/forms/d/e/1FAIpQLSdnVWoD5DrwCbNXqPqHsLw2jfbLkPMKBkvfyQfTQOPZkj_EaQ/viewform so we can gather opinions on the general direction we want on that subject. All, please fill! > > Ok to gather more advice, thanks for running the poll, > > > Vincent > > > > > Even > > > > Le 06/02/2026 ? 18:01, Vincent Picavet via QGIS-Developer a ?crit?: > >> Hi, > >> > >> I would double-down on Greg Troxel's advice concerning copyright issues, especially concerning the introduction of LLM-generated code into QGIS codebase. > >> > >> Opensource's success is based on these main characteristics : quality, security, trust. > >> > >> AI contributions pose a threat to quality, security and trust alike. > >> > >> A human-in-the-loop policy for contributions written with AI may help for quality and security issues, but will still leaves a huge problem for trust. > >> > >> Among the various aspects of trust, what worries me most right now is the copyright issue. OpenSource software is based on intellectual property laws, and especially on copyright, to be able to derive copyleft and grant more rights to end-users. > >> > >> End-user trust opensource software from a legal point of view because : > >> > >> - they are backed by well-established copyright laws > >> > >> - they have clear and well established end-users contracts ( opensource licences ) > >> > >> - they have a full record of modifications of the source code, hence a full lineage and certification of IP rights for the code > >> > >> - also, foundations like OSGeo additionnaly put a stamp on the software to guarantee that process and initial IP can be trusted enough to have a legal insurance concerning the software > >> > >> Introducing IA black boxes into the development process breaks the ability to control the lineage of the code and guarantee that it is a genuine invention, and therefore allowed to be licenced under the GPL. > >> > >> For quality and security, a developer can always intrinsically assess that the generated code has the required level of quality, and that it does not include any security flaw. > >> > >> But **there is no way for a developer to evaluate the IP rights on a code generated by a LLM**. How would one do it, since the code has been generated through a total opaque black box ingesting non-identified enormous volumes of data ? > >> > >> Today, we definitely know that LLMs ( ChatGPT, Claude and others ) have been trained on illegal copyrighted material. It is proven that they trained LLMs on pirated books. Furthermore, every time someone complaints about IP violation by LLM, big corps settle a financial arrangement with the copyright owners and move on. > >> > >> There is therefore no doubt that they have also trained LLMs on proprietary code. And also on opensource code not compliant with GPLv2+. > >> > >> Big corp. currently hide behind a "fair use" argument, but this is clearly rubbish, otherwise why would they bother to settle large financial deals with copyright owners ? > >> > >> So, LLM-generated code contributed to QGIS will at some point be plagiarized from random code available on the internet, and neither QGIS.org nor the contributor will be able to know. > >> > >> If we start accepting such code without being able to check provenance or copyright issues, it will end up buried deep inside QGIS, and the day we will discover that it infringes copyright, it will be a nightmare to solve : in this case we will want to revert all incriminated code, and also all code depending on the plagiarized code **and have it rewritten from scratch by someone who has never read the plagiarized code** ( ref : SCO/UNIX for example ). This is almost impossible. > >> > >> This would be a nightmare, just for one identified contribution. > >> > >> Even more, if/when the fair-use principle of LLMs falls down, then all LLM-generated code should be removed from QGIS, and all code depending on it. This is a really high risk with high impact. > >> > >> You may say : "ok but everyone does it, the chances of being caught are low, why not benefit from the opportunity ?" > >> > >> Then what about "everyone copies GPL code into proprietary code, the chances of being caught are low, why not benefit from the opportunity ?" > >> > >> Copyright is at the foundation of OpenSource software, and especially GPL-based software. If we choose to deny it, then we loose our core principle. > >> > >> In the text Even propose, there is a copyright section, pushing the responsibility of IP compliance control back to the contributor. It may protect QGIS.org or other developers from being sued whenever there is a problem, or they could sue back the faulty contributor, but this is not enough : > >> > >> - the faulty contributor has no way to ensure his generated code has no IP issue ( other than NOT using LLMs ) : responsibility without any mean of action is not fair and sustainable > >> > >> - even if the QGIS projet can avoid being convicted by transferring responsibility, then the situation would still be open and be a nightmare : removing plagiarized code entangled down the core of the software and all its dependency code, and rewrite it without IP issue is really hard > >> > >> Therefore, I do not think this mention is enough for IP protection. > >> > >> This rationale concerns the generated code itself, contributed to QGIS or other software in the ecosystem. LLMs may be useful and without IP risks to help find bugs, write parts of documentations where there is no risk of plagiarism, or other use cases. > >> > >> But I would definitely **forbid any generated code to be introduced into the main source code because of IP risk**. > >> > >> Also, the least we can do for any contribution, is not only to have a human in the loop, but also to have a mandatory mention and description of LLM usage for each contribution. This would at least give traceability. It does not solve anything, but in case of a problem, we could at least start to investigate. > >> > >> A am glad this conversation takes place, and willing to pursue the discussion, sorry for having been long. > >> > >> Have a nice weekend, > >> > >> Vincent > >> > >> > >> > >> > >> > >> On 31/01/2026 01:01, Greg Troxel via QGIS-Developer wrote: > >>> I would suggest a much stronger policy: > >>> > >>> ?? no LLM-generated code or discussion may be submitted to any QGIS forum > >>> > >>> > >>> The idea that LLM-generated code has been "reviewed" intends to be that > >>> it is of high enough quality that it is reasonable for *humans* to spend > >>> time reviewing it.? But I don't believe that asking that it be reviewed > >>> will achieve that in practice. > >>> > >>> I've already had the experience (in a different project) of seeing a > >>> posted PR(ish, patch on list), taking the time to comment, and getting > >>> LLM-generated (vacuous) replies to my comments. > >>> > >>> Besides the ethical problems with asking humans to review, improve, > >>> judge or in any other way pay attention to LLM output, there's the > >>> problem of copyright.? While machine-generated text isn't copyrightable > >>> as is, LLM output is a derived work of stolen human work, scraped > >>> and used without permission, often as DDOS. > >>> > >>> On the basis of each reason, I believe the policy about LLM should just > >>> be "no". > >>> _______________________________________________ > >>> 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: From vincent.ml at oslandia.com Sat Feb 14 01:57:39 2026 From: vincent.ml at oslandia.com (Vincent Picavet) Date: Sat, 14 Feb 2026 10:57:39 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: <1de62679-1380-4013-a514-e56a4c8a9a2c@konarici.cz> References: <87ecmpevj1.fsf@julienlaptop.home> <1de62679-1380-4013-a514-e56a4c8a9a2c@konarici.cz> Message-ID: <399f4da1-c6e4-4ac6-9546-d2b644422124@oslandia.com> Hello, As often in OpenSource projects and engineering teams, I have the impression that we are looking for solutions before having defined the problem. 3D engines are as diverse as use cases can be. Without a clear vision of what we would like for 3D in QGIS in terms of features and goals, I do not see the point in assessing technical solutions. You cannot compare 3D framework if you do not know if your main goal is photorealistic rendering of objects, or 3D analysis ( or both ). I would rather suggest to : - ask end-users (and not developers) about what they really need in 3D - gather real-world use cases from users - get a list of features for 3D in other softwares ( ESRI & others ) - start establishing a roadmap and vision from these elements - THEN and only then, look for technical solutions Best regards, Vincent On 13/02/2026 13:08, David Ko?a??k via QGIS-Developer wrote: > Hi, thanks for the links. > > On 2/13/26 08:43, Johannes Kr?ger (WhereGroup) via QGIS-Developer wrote: >> Two engines from my bookmarks that might be interesting. I know little about the topic in relation to what QGIS would need though :) >> >> - https://github.com/bkaradzic/bgfx > > bgfx might be an option. It is on a similar abstraction level as QRhi from what I can see. > >> - https://o3de.org/ Open 3D Engine (O3DE), might not be easy to embed > > O3DE is a full "game engine" with a lot of functionality that we don't need, meant to run standalone scenes made in their editor. Maybe we could use some of their code, but given the size of their codebase, I think it would be more trouble than it's worth. > > David Ko?a??k > _______________________________________________ > 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 dvdkon at konarici.cz Sat Feb 14 06:27:21 2026 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Sat, 14 Feb 2026 15:27:21 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: <399f4da1-c6e4-4ac6-9546-d2b644422124@oslandia.com> References: <87ecmpevj1.fsf@julienlaptop.home> <1de62679-1380-4013-a514-e56a4c8a9a2c@konarici.cz> <399f4da1-c6e4-4ac6-9546-d2b644422124@oslandia.com> Message-ID: <5224dab3-6d30-4607-bfeb-047fad9447fd@konarici.cz> On 2/14/26 10:57, Vincent Picavet via QGIS-Developer wrote: > Hello, > > As often in OpenSource projects and engineering teams, I have the > impression that we are looking for solutions before having defined the > problem. > > 3D engines are as diverse as use cases can be. Without a clear vision of > what we would like for 3D in QGIS in terms of features and goals, I do > not see the point in assessing technical solutions. > > You cannot compare 3D framework if you do not know if your main goal is > photorealistic rendering of objects, or 3D analysis ( or both ). > > I would rather suggest to : > > - ask end-users (and not developers) about what they really need in 3D > > - gather real-world use cases from users > > - get a list of features for 3D in other softwares ( ESRI & others ) > > - start establishing a roadmap and vision from these elements > > - THEN and only then, look for technical solutions Hi, I've been working under the assumption that our goal would be to replicate QGIS' existing 3D functionality, just with a new engine. It would certainly be nice to have a formulated long-term plan for the 3D view, but I think that's somewhat orthogonal to the engine change. I'm not even sure how such a thing based primarily on user input would be created or applied when most work is funded by contracts for particular tasks. David Ko?a??k From wonder.sk at gmail.com Sat Feb 14 12:53:07 2026 From: wonder.sk at gmail.com (Martin Dobias) Date: Sat, 14 Feb 2026 21:53:07 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: <77a35d4393424032ee845673652dc7022fc78487.camel@enoreth.net> References: <87ecmpevj1.fsf@julienlaptop.home> <77a35d4393424032ee845673652dc7022fc78487.camel@enoreth.net> Message-ID: Hi Jean-Roc On Fri, Feb 13, 2026 at 12:46?PM Jean-Roc Morreale via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > > Hi, may I suggest having a look at Kiware's VTK ? It's C++ with > JS/WASM ports, been for 3 decades, not tied to the Qt Company but used > with Qt-enabled softwares covering GIS/point cloud/volumetric usecases. > Thanks for bringing it up. I am aware of the project, but haven't studied it in detail yet. Regards Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.bruy at gmail.com Sun Feb 15 00:38:15 2026 From: alexander.bruy at gmail.com (Alexander Bruy) Date: Sun, 15 Feb 2026 08:38:15 +0000 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: References: <87ecmpevj1.fsf@julienlaptop.home> <77a35d4393424032ee845673652dc7022fc78487.camel@enoreth.net> Message-ID: There is also osgEarth. We even used it for some time in the past in the Globe plugin. ??, 14 ???. 2026??. ? 20:53 Martin Dobias via QGIS-Developer ????: > > Hi Jean-Roc > > On Fri, Feb 13, 2026 at 12:46?PM Jean-Roc Morreale via QGIS-Developer wrote: >> >> >> Hi, may I suggest having a look at Kiware's VTK ? It's C++ with >> JS/WASM ports, been for 3 decades, not tied to the Qt Company but used >> with Qt-enabled softwares covering GIS/point cloud/volumetric usecases. > > > Thanks for bringing it up. I am aware of the project, but haven't studied it in detail yet. > > Regards > Martin > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy From lova at kartoza.com Sun Feb 15 22:09:16 2026 From: lova at kartoza.com (Lova Andriarimalala) Date: Mon, 16 Feb 2026 09:09:16 +0300 Subject: [QGIS-Developer] QEP 408: QGIS Plugins Security and QA Validator In-Reply-To: References: Message-ID: Hello everyone, This QEP has now passed the two-week threshold and is ready for voting. Thank you to everyone who responded, provided comments, and offered suggestions. 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 Tue, 27 Jan 2026 at 13:39, Lova Andriarimalala wrote: > Hello everyone, > > I have submitted a new QEP ( > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/361), and this is > to inform you that it is now ready for review. > Please feel free to add more comments or reviews there if you have any > questions or suggestions. Your insights will be greatly appreciated. > > Thank you so much. > > 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.* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wonder.sk at gmail.com Mon Feb 16 04:39:23 2026 From: wonder.sk at gmail.com (Martin Dobias) Date: Mon, 16 Feb 2026 13:39:23 +0100 Subject: [QGIS-Developer] QGIS 3D: Move away from Qt 3D? In-Reply-To: References: <87ecmpevj1.fsf@julienlaptop.home> <77a35d4393424032ee845673652dc7022fc78487.camel@enoreth.net> Message-ID: Hi Alex On Sun, Feb 15, 2026 at 9:38?AM Alexander Bruy wrote: > There is also osgEarth. We even used it for some time in the past in > the Globe plugin. > osgEarth builds on top of OpenSceneGraph, which all based on OpenGL stack, but we should switch to modern graphics APIs. There is also VulkanSceneGraph now from the author of OpenSceneGraph, and an experimental osgEarth replacement called Rocky (from the same authors as osgEarth). I don't think we want to build on top of osgEarth/Rocky - a great amount of code of these projects implement geospatial functionality, which is already present in QGIS, and then there is some amount of code that applies that within OSG/VSG framework. I think VSG is one of the options to consider, with the potential issue that it is Vulkan-oriented (no native support for Metal / DirectX). Cheers Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Tue Feb 17 14:50:44 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 17 Feb 2026 23:50:44 +0100 Subject: [QGIS-Developer] Call for vote on QEP 408 "AI tool use policy" In-Reply-To: <2960af73-65ce-4f39-aafe-80b26f4bb24b@spatialys.com> References: <2960af73-65ce-4f39-aafe-80b26f4bb24b@spatialys.com> Message-ID: <0bf1a8c3-2832-41d9-9820-c685026561ab@spatialys.com> Hi, with the latest amendments done in https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363/commits/e4baaeff970aee782362bdfd87eacbb9ee89ee0d, please cast your votes in the pull request Even Le 31/01/2026 ? 15:25, Even Rouault via QGIS-Developer a ?crit?: > Hi, > > please find it at > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/363 > > Even > > Le 30/01/2026 ? 19:20, Even Rouault via QGIS-Developer a ?crit?: >> Hi, >> >> as we're starting to get vibe coded pull requests, it might be >> interesting to adopt a policy similar to the one of LLVM pointed at >> https://www.phoronix.com/news/LLVM-Human-In-The-Loop. I guess we >> could just copy&paste it replacing LLVM by QGIS.? Won't stop the flow >> but at least we'd have something to point "vibe contributors" to. >> >> Even >> -- http://www.spatialys.com My software is free, but my time generally not. From nyall.dawson at gmail.com Tue Feb 17 20:05:58 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Wed, 18 Feb 2026 14:05:58 +1000 Subject: [QGIS-Developer] =?utf-8?q?Realistically=2C_we_can=27t_release_i?= =?utf-8?b?biAyIGRheXMg8J+YsQ==?= Message-ID: Hey list, Everyone who has been actively testing 4.0 nightlies has probably seen this coming, but we're just NOT ready to publicly release 4.0 on the 20th. Aside from anything else, we still don't have a fix for the profile corruption bug* which should be a blocker alone. With this one a user's 3.x profile can get completely corrupted, and/or cause hangs on loading 3.x/4.0. What should we do? Nyall * I've been working on a fix in https://github.com/qgis/QGIS/pull/64752, but it's not ready yet, and will need some decent testing after it lands before I'm confident we've resolved this one. -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.neumann at carto.net Tue Feb 17 23:33:41 2026 From: a.neumann at carto.net (Andreas Neumann) Date: Wed, 18 Feb 2026 08:33:41 +0100 Subject: [QGIS-Developer] =?utf-8?q?Realistically=2C_we_can=27t_release_i?= =?utf-8?b?biAyIGRheXMg8J+YsQ==?= In-Reply-To: References: Message-ID: <5a084a53425cf523954353aed80d087e@carto.net> Hi, I think in this case we should delay the release until this serious issue can be resolved and was properly tested. Nyall - are you available to finish the fix for the issue around the profile corruption issue? It can be handled through our bug fixing initiative. I would appreciate it a lot! We told everyone that QGIS 4.0 isn't ready for production use, so people probably aren't really counting on using QGIS 4.0 anytime soon. Andreas On 2026-02-18 05:05, Nyall Dawson via QGIS-Developer wrote: > Hey list, > > Everyone who has been actively testing 4.0 nightlies has probably seen > this coming, but we're just NOT ready to publicly release 4.0 on the > 20th. Aside from anything else, we still don't have a fix for the > profile corruption bug* which should be a blocker alone. With this one > a user's 3.x profile can get completely corrupted, and/or cause hangs > on loading 3.x/4.0. > > What should we do? > > Nyall > > * I've been working on a fix in > https://github.com/qgis/QGIS/pull/64752, but it's not ready yet, and > will need some decent testing after it lands before I'm confident we've > resolved this one. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From nirvn.asia at gmail.com Tue Feb 17 23:39:49 2026 From: nirvn.asia at gmail.com (Mathieu Pellerin) Date: Wed, 18 Feb 2026 14:39:49 +0700 Subject: [QGIS-Developer] =?utf-8?q?=5BQgis-psc=5D__Realistically=2C_we_c?= =?utf-8?b?YW4ndCByZWxlYXNlIGluIDIgZGF5cyDwn5ix?= In-Reply-To: <5a084a53425cf523954353aed80d087e@carto.net> References: <5a084a53425cf523954353aed80d087e@carto.net> Message-ID: I'd be -1 on undetermined delay, and generally not super enthusiastic about a further delay to 4.0. If we want to give ourselves say one more week to address really bad issues (like the one Nyall raised), let's set a firm date attached to an unbreakable vow that will be the date we release? :) As was pointed out by Andreas, while we should strive to provide the best possible experience for people who will jump onto 4.0, there's also plenty of understanding that 4.0 will be more disruptive than going to a new point release within our 3.X release cycles. On Wed, Feb 18, 2026 at 2:33?PM Andreas Neumann via QGIS-PSC < qgis-psc at lists.osgeo.org> wrote: > Hi, > > I think in this case we should delay the release until this serious issue > can be resolved and was properly tested. > > Nyall - are you available to finish the fix for the issue around the > profile corruption issue? It can be handled through our bug fixing > initiative. I would appreciate it a lot! > > We told everyone that QGIS 4.0 isn't ready for production use, so people > probably aren't really counting on using QGIS 4.0 anytime soon. > > Andreas > > On 2026-02-18 05:05, Nyall Dawson via QGIS-Developer wrote: > > Hey list, > > Everyone who has been actively testing 4.0 nightlies has probably seen > this coming, but we're just NOT ready to publicly release 4.0 on the 20th. > Aside from anything else, we still don't have a fix for the profile > corruption bug* which should be a blocker alone. With this one a user's 3.x > profile can get completely corrupted, and/or cause hangs on loading > 3.x/4.0. > > What should we do? > > Nyall > > * I've been working on a fix in https://github.com/qgis/QGIS/pull/64752, > but it's not ready yet, and will need some decent testing after it lands > before I'm confident we've resolved this one. > > _______________________________________________ > 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-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: From rdmailings at duif.net Tue Feb 17 23:52:48 2026 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Wed, 18 Feb 2026 08:52:48 +0100 Subject: [QGIS-Developer] =?utf-8?q?=5BQgis-psc=5D_Realistically=2C_we_ca?= =?utf-8?q?n=27t_release_in_2_days_=F0=9F=98=B1?= In-Reply-To: References: Message-ID: <904f0779-2641-43ee-ba31-e4e1eab3e289@duif.net> On 2/18/26 05:05, Nyall Dawson via QGIS-PSC wrote: > Hey list, > > Everyone who has been actively testing 4.0 nightlies has probably seen this coming, but we're just NOT ready to publicly release 4.0 on the 20th. Aside from anything else, we still don't have a fix for the profile corruption bug* which should be a blocker alone. With this one a user's 3.x profile can get completely corrupted, and/or cause hangs on loading 3.x/4.0. > > What should we do? As a heavy profile user (>25 profiles; why is OpenActiveProfile folder at the bottom anyway :-)), AND someone switching between QGIS versions a lot(!), I prefer to fix this first... Seems a real blocker to me :-( Just wondering, after reading https://github.com/qgis/QGIS/pull/64752: is this only about the encoding of ~/.local/share/QGIS/QGIS3/profiles//QGIS/QGIS3.ini ? or also about the (encoding? of) other files in the profile folder? You probably looked, but IF only about the ini file, it's not possible to create a QGIS4.ini (or just QGIS.ini) only ~/.local/share/QGIS/QGIS3/profiles//QGIS/QGIS4.ini ? But I reckon you are right :-) So we copy the full profiles folder to ~/.local/share/QGIS/QGIS4/profiles//QGIS/QGIS4.ini ? Doing that once, yes? Is there maybe an easy way to check (after the one-time copy) if a QGIS3 profile is newer then (or updated) the QGIS4 profile? And IF so let the user decide if we want to 'refresh/copy' the QGIS3->QGIS4 (1 profile folder) again? I'm thinking about peeps like me, who probably have to work some time in QGIS3 (because certain clients will stick to 3.40 or 3.44 for some time). Anyway: THANKS for feeling responsible for this! Regards, Richard Duivenvoorde From skampus at gmail.com Wed Feb 18 03:39:31 2026 From: skampus at gmail.com (Stefano Campus) Date: Wed, 18 Feb 2026 12:39:31 +0100 Subject: [QGIS-Developer] Using (or not) the upload functions in Transifex Message-ID: Good morning, I have a question about the use of QGIS translations in Transifex, which I have already sent to the translators' mailing list and which I would like to ask here as well, hoping for a reply. I don't understand what the upload functions in Transifex are for. I am the coordinator of the Italian translation team and I see that in Transifex I can upload a file (see image [1]), but I don't understand how this upload affects the flow from Transifex to QGIS. It might be useful to download the .ts files of the translations and perhaps make more detailed corrections in Qt Linguist, but then there is the problem of reconciliation. That is why I am asking you what the Transifex upload is for. To improve the translation and standardization of the translation in Desktop and then Documentation and Web, I enlisted the help of AI to create a script that compares the .ts files downloaded from Transifex and detects if a string has been translated differently in the various parts. For example, I did this for the three versions of Desktop (for_use_QGIS_qgis-application_it.ts, for_use_QGIS_release-3_40-qgis-application_it.ts, for_use_QGIS_release-3_44-qgis-application_it.ts). The result is a CSV file that contains only the strings that differ in translation and in which file. For example, see figure. [2] This is useful because in Tx I only select the original strings with translations to be standardized. I can send the script somewhere if you need it. Thanks for your help with the upload question. stefano [1] https://ibb.co/d4XpMXYm [2] https://ibb.co/3mkhFbwQ -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Wed Feb 18 05:31:30 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 18 Feb 2026 08:31:30 -0500 Subject: [QGIS-Developer] =?utf-8?q?Realistically=2C_we_can=27t_release_i?= =?utf-8?b?biAyIGRheXMg8J+YsQ==?= In-Reply-To: (Nyall Dawson via's message of "Wed, 18 Feb 2026 14:05:58 +1000") References: Message-ID: [dropping psc because it doesn't accept mail] Nyall Dawson via QGIS-Developer writes: > Everyone who has been actively testing 4.0 nightlies has probably seen this > coming, but we're just NOT ready to publicly release 4.0 on the 20th. Aside > from anything else, we still don't have a fix for the profile corruption > bug* which should be a blocker alone. With this one a user's 3.x profile > can get completely corrupted, and/or cause hangs on loading 3.x/4.0. In general, I think firmly fixed release dates are not a reasonable plan, except for micros along a stable branch which is kept stable at all times. What's reasonable is a firm feature freeze date. Basically one can stop destabilizing changes on command, but one can't make stability on command. (Yes, I have managed software development to deadlines, and yes, I know it's really not fun at times.) As a packager, the idea of a 4.0 (with massive change in dependencie) coming out without a 4.0a1 or 4.0b1 or even an rc is uncomfortable. I don't see how is served by tagging a 4.0 release before it's ready for use by random users. To me that's the key question. So I'd say: It's past time to be in feature freeze on master. Definitely bug fixes and doc fixes only. (Probably that's true and has been for a while.) (The last few years we have been able to get away without a/b/rc because there has been little change in deps and it's mostly core code that changes in a way that doesn't tend to lead to trouble in environments other than the developer's.) If it mostly works, which it sounds like it does, there should be a 4.0a1 tag laid down, and that can lead to 4.0a1 binary packages. (People who run an alpha should be making backups, even more than everybody else.) 4.0.0 should be tagged when it's ready, not before. I realize there is sort of ".0 releases are sort of rc", but I see that as a higher-level risk mitigation rather than truly being an rc. From bas at rdgland.com Wed Feb 18 06:19:25 2026 From: bas at rdgland.com (Sebastian Gutwein) Date: Wed, 18 Feb 2026 09:19:25 -0500 Subject: [QGIS-Developer] =?utf-8?q?Realistically=2C_we_can=27t_release_i?= =?utf-8?b?biAyIGRheXMg8J+YsQ==?= In-Reply-To: References: Message-ID: I hope it is ok that I chime in here. From my non developer perspective the 3.x.0 releases are not currently seen as release candidates by most people, if they even understand that concept. My recollection is that the website and OSGEO don't tag them as release candidates (is that true?) and it only shows up on the splash screen. My experience was that when 3.0 came out there were a lot of growing pains and I always used the LTR because the stability difference was significant. As 3.x releases have matured the stability difference was not as great and I started using the latest releases exclusively. If I correctly understand the issue I think releasing 4.0.0 with a potential profile corrupting bug even as a release candidate is problematic. I also think that the 4.x releases are a great time to switch how these things are numbered and show up on the website. Having separate download buttons for LTR, Latest, and Release Candidates could go a long way to communicating this difference in releases. Thanks for all of your amazing and hard work on this and I understand many of you are feeling pressure to release on time but I as someone who is getting a bunch of people to install QGIS I hope you give it a little more time. -Bas On Wed, Feb 18, 2026 at 8:31?AM Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > [dropping psc because it doesn't accept mail] > > Nyall Dawson via QGIS-Developer writes: > > > Everyone who has been actively testing 4.0 nightlies has probably seen > this > > coming, but we're just NOT ready to publicly release 4.0 on the 20th. > Aside > > from anything else, we still don't have a fix for the profile corruption > > bug* which should be a blocker alone. With this one a user's 3.x profile > > can get completely corrupted, and/or cause hangs on loading 3.x/4.0. > > In general, I think firmly fixed release dates are not a reasonable > plan, except for micros along a stable branch which is kept stable at > all times. What's reasonable is a firm feature freeze date. Basically > one can stop destabilizing changes on command, but one can't make > stability on command. (Yes, I have managed software development to > deadlines, and yes, I know it's really not fun at times.) > > As a packager, the idea of a 4.0 (with massive change in dependencie) > coming out without a 4.0a1 or 4.0b1 or even an rc is uncomfortable. > > I don't see how is served by tagging a 4.0 release before it's ready for > use by random users. To me that's the key question. > > So I'd say: > > It's past time to be in feature freeze on master. Definitely bug > fixes and doc fixes only. (Probably that's true and has been for a > while.) > > (The last few years we have been able to get away without a/b/rc > because there has been little change in deps and it's mostly core code > that changes in a way that doesn't tend to lead to trouble in > environments other than the developer's.) > > If it mostly works, which it sounds like it does, there should be a > 4.0a1 tag laid down, and that can lead to 4.0a1 binary packages. > (People who run an alpha should be making backups, even more than > everybody else.) > > 4.0.0 should be tagged when it's ready, not before. > > > I realize there is sort of ".0 releases are sort of rc", but I see that > as a higher-level risk mitigation rather than truly being an rc. > _______________________________________________ > 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 > -- ___________________________ Sebastian "Bas* " Gutwein *rhymes with Josh Regenerative Design Group 1 Chevalier Ave Greenfield, Ma 01301 Web: regenerativedesigngroup.com (631) 241-1018 *Look close, think big, make change. * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jef at norbit.de Wed Feb 18 07:49:37 2026 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Wed, 18 Feb 2026 16:49:37 +0100 Subject: [QGIS-Developer] Realistically, we can't release in 2 days ? In-Reply-To: References: Message-ID: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> Hi Nyall, On Wed, 18. Feb 2026 at 14:05:58 +1000, Nyall Dawson via QGIS-Developer wrote: > Everyone who has been actively testing 4.0 nightlies has probably seen this > coming, but we're just NOT ready to publicly release 4.0 on the 20th. Aside > from anything else, we still don't have a fix for the profile corruption > bug* which should be a blocker alone. With this one a user's 3.x profile > can get completely corrupted, and/or cause hangs on loading 3.x/4.0. If we have a blocker we should postpone. How much time do we need? I suppose we're just moving the release date ahead and don't do additional releases of 3.40 and 3.44 instead? 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 IRC: jef on Libera|OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gdt at lexort.com Wed Feb 18 08:27:35 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 18 Feb 2026 11:27:35 -0500 Subject: [QGIS-Developer] Realistically, we can't release in 2 days ? In-Reply-To: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> (=?utf-8?Q?=22J?= =?utf-8?Q?=C3=BCrgen?= E. Fischer via QGIS-Developer"'s message of "Wed, 18 Feb 2026 16:49:37 +0100") References: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> Message-ID: J?rgen E. Fischer via QGIS-Developer writes: > If we have a blocker we should postpone. How much time do we need? >From my viewpoint, there need to be an rc for a while before a 4.0, so it's not like waiting 5 days could address it. Realistically I cannot see a 4.0 (which has not been unreasonably rushed) before 2 weeks from now, even if a fix for the last problems magically lands today. > I suppose we're just moving the release date ahead and don't do additional > releases of 3.40 and 3.44 instead? >From my packager viewpoint, I would prefer one of - micro releases of 3.40 and 3.44 on schedule, because there's no reason not to. I really don't care that the eventual 4.0 release is or isn't synchronized to 3.4*.x point releases. Updating to new point releases is really easy - just change the version, regen checksum, build/replace package and start up qgis on a project, push changes. It's literally less than 10 minutes of effort and I have no memory of it going badly. - as above, but when releassing 3.40.x and 3.44.y, decide that 3.44 is now LTR. The fact that 4.0 is delayed is not related to "3.44 is fine and is what people ought to be running until their packaging system and they decide that it's wise to run 4.0". (I don't personally care which one has the LTR label as I have already changed pkgsrc, which has historically been LTRs, to be 3.44 a few months ago.) From gdt at lexort.com Wed Feb 18 15:04:55 2026 From: gdt at lexort.com (Greg Troxel) Date: Wed, 18 Feb 2026 18:04:55 -0500 Subject: [QGIS-Developer] building master in pkgsrc; mostly ok! Message-ID: I'm building qgis masterunder NetBSD 10, both not under pkgsrc and now as a 3.99.0 package, tracking git master. I am using gcc 12 which I believe should be ok with c++20. qgis's cmake accepts it. The exciting news is that things are mostly good. Three test files fail to build with an ambiguous overload, and I'm pretty sure there is one root cause for 3 problems. I'm including the build output from just the first. Trying to understand, it seems like a complex inheritance pattern and there are at least two ways to do it. I think the compiler is saying there is no valid way to break the tie. (This is after running make to build what builds, which is almost everything else.) Is anyon else seeing this? Using gcc12? => Bootstrap dependency digest>=20211023: found digest-20220214 ===> Checking for vulnerabilities in qgis-3.99.0 ===> Building for qgis-3.99.0 [1/22] Running crssync Detected locale "C" with character encoding "646", which is not UTF-8. Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead. If this causes problems, reconfigure your locale. See the locale(1) manual for more information. [2/22] Building CXX object tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o FAILED: [code=1] tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o /tmp/work/wip/qgis/work/.cwrapper/bin/c++ -DCMAKE_SOURCE_DIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759\" -DINSTALL_PREFIX=\"/usr/pkg\" -DPROTOBUF_USE_DLLS -DQT_CONCURRENT_LIB -DQT_CORE5COMPAT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_DEPRECATED_WARNINGS -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_TESTCASE_BUILDDIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/tests/src/core/geometry\" -DQT_TESTCASE_SOURCEDIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry\" -DQT_TESTLIB_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060e00 -DTEST_DATA_DIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/testdata\" -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/tests/src/core/geometry/test_core_geometry_linestring_autogen/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/tests/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/kdbush/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/test -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/lazperf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/tests/src/core/geometry -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/3d -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/actions -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/annotations -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/auth -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/browser -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/callouts -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/classification -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/diagram -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/dxf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/editform -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/effects -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/elevation -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/expression -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/externalstorage -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/fieldformatter -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geocoding -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/gps -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/labeling -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/labeling/rules -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/layertree -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/layout -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/locator -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/maprenderer -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/mesh -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/metadata -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/multimedia -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/network -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/numericformats -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/painting -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pal -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pdf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/plot -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pointcloud -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pointcloud/expression -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/processing -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/processing/models -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/proj -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/project -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/arcgis -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/memory -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/gdal -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/ogr -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/meshmemory -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/sensorthings -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/raster -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/renderer -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/scalebar -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/settings -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/sensor -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/stac -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/symbology -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/textrenderer -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/tiledscene -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/validity -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/vector -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/vectortile -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/web -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/delaunator-cpp -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/nanoarrow/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/nmea -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/rtree/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/tinygltf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/earcut -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/ept -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/copc -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/vpc -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/src/test -isystem /tmp/work/wip/qgis/work/.buildlink/include -isystem /usr/pkg/qt6/include/Qca-qt6/QtCrypto -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtCore -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/mkspecs/netbsd-g++ -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtGui -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtXml -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtWidgets -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtSvg -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtNetwork -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtSql -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtConcurrent -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtMultimedia -isystem /tmp/work/wip/qgis/work/.buildlink/include/geos -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtPositioning -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtDBus -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtPrintSupport -isystem /usr/pkg/include -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtCore5Compat -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtSerialPort -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtTest -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -Dz_off_t=long -I/usr/pkg/qt6/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/pkg/include/libxml2 -I/usr/pkg/include/minizip -I/usr/pkg/include/gstreamer-1.0 -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -Woverloaded-virtual -Wimplicit-fallthrough -Wsuggest-override -std=gnu++20 -fvisibility=hidden -fPIC -MD -MT tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o -MF tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o.d -o tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o -c /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp In file included from /usr/pkg/qt6/include/QtTest/qtest.h:13, from /usr/pkg/qt6/include/QtTest/QTest:1, from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/test/qgstest.h:50, from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:31: /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp: In member function 'void TestQgsLineString::equality()': /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:956:19: error: ambiguous overload for 'operator==' (operand types are 'QgsLineString' and 'QgsPoint') 956 | QVERIFY( !( ls6 == p1 ) ); | ~~~ ^~ ~~ | | | | | QgsPoint | QgsLineString In file included from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgsbox3d.h:22, from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:24, from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscircularstring.h:23, from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:22: /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgspoint.h:280:10: note: candidate: 'virtual bool QgsPoint::operator==(const QgsAbstractGeometry&) const' (reversed) 280 | bool operator==( const QgsAbstractGeometry &other ) const override SIP_HOLDGIL | ^~~~~~~~ /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:46:10: note: candidate: 'virtual bool QgsCurve::operator==(const QgsAbstractGeometry&) const' 46 | bool operator==( const QgsAbstractGeometry &other ) const override; | ^~~~~~~~ /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:957:16: error: ambiguous overload for 'operator!=' (operand types are 'QgsLineString' and 'QgsPoint') 957 | QVERIFY( ls6 != p1 ); | ~~~ ^~ ~~ | | | | | QgsPoint | QgsLineString /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgspoint.h:280:10: note: candidate: 'virtual bool QgsPoint::operator==(const QgsAbstractGeometry&) const' (reversed) 280 | bool operator==( const QgsAbstractGeometry &other ) const override SIP_HOLDGIL | ^~~~~~~~ /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:46:10: note: candidate: 'virtual bool QgsCurve::operator==(const QgsAbstractGeometry&) const' (rewritten) 46 | bool operator==( const QgsAbstractGeometry &other ) const override; | ^~~~~~~~ /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:47:10: note: candidate: 'virtual bool QgsCurve::operator!=(const QgsAbstractGeometry&) const' 47 | bool operator!=( const QgsAbstractGeometry &other ) const override; | ^~~~~~~~ ninja: build stopped: subcommand failed. *** Please use pkgtools/verifypc to sanity check dependencies. *** Error code 1 (continuing) `all' not remade because of errors. Stop. make[1]: stopped in /n0/gdt/pkgsrc-current/pkgsrc/wip/qgis *** Error code 1 (continuing) `all' not remade because of errors. Stop. make: stopped in /usr/pkgsrc/wip/qgis From even.rouault at spatialys.com Wed Feb 18 15:47:50 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 19 Feb 2026 00:47:50 +0100 Subject: [QGIS-Developer] building master in pkgsrc; mostly ok! In-Reply-To: References: Message-ID: <4238ef3c-5f51-4180-b99b-1442a9992ef3@spatialys.com> Greg, While playing with compiler explorer (https://godbolt.org/z/v1GEGnT6j) I suspect this is a bug in C++20 support in gcc 12 that got fixed in gcc 13 (similary clang 15 has the same issue, and clang 16 not). Likely an erratum of C++20 that didn't make it in early implementations. You could workaround it by down casting the left side member of the comparisons to (const QgsAbstractGeometry&) Even Le 19/02/2026 ? 00:04, Greg Troxel via QGIS-Developer a ?crit?: > I'm building qgis masterunder NetBSD 10, both not under pkgsrc and now > as a 3.99.0 package, tracking git master. > > I am using gcc 12 which I believe should be ok with c++20. qgis's cmake > accepts it. > > The exciting news is that things are mostly good. > > Three test files fail to build with an ambiguous overload, and I'm > pretty sure there is one root cause for 3 problems. I'm including the > build output from just the first. > > Trying to understand, it seems like a complex inheritance pattern and > there are at least two ways to do it. I think the compiler is saying > there is no valid way to break the tie. > > (This is after running make to build what builds, which is almost > everything else.) > > Is anyon else seeing this? Using gcc12? > > > => Bootstrap dependency digest>=20211023: found digest-20220214 > ===> Checking for vulnerabilities in qgis-3.99.0 > ===> Building for qgis-3.99.0 > [1/22] Running crssync > Detected locale "C" with character encoding "646", which is not UTF-8. > Qt depends on a UTF-8 locale, and has switched to "C.UTF-8" instead. > If this causes problems, reconfigure your locale. See the locale(1) manual > for more information. > [2/22] Building CXX object tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o > FAILED: [code=1] tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o > /tmp/work/wip/qgis/work/.cwrapper/bin/c++ -DCMAKE_SOURCE_DIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759\" -DINSTALL_PREFIX=\"/usr/pkg\" -DPROTOBUF_USE_DLLS -DQT_CONCURRENT_LIB -DQT_CORE5COMPAT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_MULTIMEDIA_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_DEPRECATED_WARNINGS -DQT_POSITIONING_LIB -DQT_PRINTSUPPORT_LIB -DQT_SERIALPORT_LIB -DQT_SQL_LIB -DQT_SVG_LIB -DQT_TESTCASE_BUILDDIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/tests/src/core/geometry\" -DQT_TESTCASE_SOURCEDIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry\" -DQT_TESTLIB_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSIP_VERSION=0x060e00 -DTEST_DATA_DIR=\"/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/testdata\" -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pk > gsrc-build/tests/src/core/geometry/test_core_geometry_linestring_autogen/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/tests/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/kdbush/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/test -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/lazperf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/tests/src/core/geometry -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cm > ake-pkgsrc-build/src/core -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/3d -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/actions -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/annotations -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/auth -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/browser -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/callouts -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/classification -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/diagram -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/dxf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/editform -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core > /effects -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/elevation -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/expression -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/externalstorage -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/fieldformatter -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geocoding -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/gps -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/labeling -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/labeling/rules -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/layertree -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d47 > 59/src/core/layout -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/locator -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/maprenderer -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/mesh -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/metadata -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/multimedia -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/network -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/numericformats -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/painting -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pal -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pdf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pl > ot -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pointcloud -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/pointcloud/expression -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/processing -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/processing/models -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/proj -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/project -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/arcgis -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/memory -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/gdal -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e > 622f327e5c000774d4759/src/core/providers/ogr -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/meshmemory -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/sensorthings -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/raster -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/renderer -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/scalebar -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/settings -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/sensor -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/stac -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/symbology -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/textrenderer -I/tmp/work/wip/qgis/work/QGI > S-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/tiledscene -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/validity -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/vector -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/vectortile -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/web -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/delaunator-cpp -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/nanoarrow/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/nmea -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/rtree/include -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/tinygltf -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/external/earcut -I/tmp/work/wip/qgis/work > /QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/ept -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/copc -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/providers/vpc -I/tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/cmake-pkgsrc-build/src/test -isystem /tmp/work/wip/qgis/work/.buildlink/include -isystem /usr/pkg/qt6/include/Qca-qt6/QtCrypto -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtCore -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/mkspecs/netbsd-g++ -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtGui -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtXml -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtWidgets -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtSvg -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtNetwork -isystem /tmp/work/wip/qgis/work/ > .buildlink/qt6/include/QtSql -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtConcurrent -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtMultimedia -isystem /tmp/work/wip/qgis/work/.buildlink/include/geos -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtPositioning -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtDBus -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtPrintSupport -isystem /usr/pkg/include -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtCore5Compat -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtSerialPort -isystem /tmp/work/wip/qgis/work/.buildlink/qt6/include/QtTest -O2 -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/python3.13 -Dz_off_t=long -I/usr/pkg/qt6/include -I/usr/pkg/include/glib-2.0 -I/usr/pkg/include/gio-unix-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include/harfbuzz -I/usr/pkg/include/freetype2 -I/usr/X11R7/include -I/usr/X11R7/include/libdrm -I/usr/pkg/include/libxml2 -I/usr/pkg > /include/minizip -I/usr/pkg/include/gstreamer-1.0 -Wall -Wextra -Wno-long-long -Wformat-security -Wno-strict-aliasing -Wnon-virtual-dtor -Wno-redundant-move -Wno-misleading-indentation -Wno-deprecated-copy -Woverloaded-virtual -Wimplicit-fallthrough -Wsuggest-override -std=gnu++20 -fvisibility=hidden -fPIC -MD -MT tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o -MF tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o.d -o tests/src/core/geometry/CMakeFiles/test_core_geometry_linestring.dir/testqgslinestring.cpp.o -c /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp > In file included from /usr/pkg/qt6/include/QtTest/qtest.h:13, > from /usr/pkg/qt6/include/QtTest/QTest:1, > from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/test/qgstest.h:50, > from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:31: > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp: In member function 'void TestQgsLineString::equality()': > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:956:19: error: ambiguous overload for 'operator==' (operand types are 'QgsLineString' and 'QgsPoint') > 956 | QVERIFY( !( ls6 == p1 ) ); > | ~~~ ^~ ~~ > | | | > | | QgsPoint > | QgsLineString > In file included from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgsbox3d.h:22, > from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:24, > from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscircularstring.h:23, > from /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:22: > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgspoint.h:280:10: note: candidate: 'virtual bool QgsPoint::operator==(const QgsAbstractGeometry&) const' (reversed) > 280 | bool operator==( const QgsAbstractGeometry &other ) const override SIP_HOLDGIL > | ^~~~~~~~ > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:46:10: note: candidate: 'virtual bool QgsCurve::operator==(const QgsAbstractGeometry&) const' > 46 | bool operator==( const QgsAbstractGeometry &other ) const override; > | ^~~~~~~~ > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/tests/src/core/geometry/testqgslinestring.cpp:957:16: error: ambiguous overload for 'operator!=' (operand types are 'QgsLineString' and 'QgsPoint') > 957 | QVERIFY( ls6 != p1 ); > | ~~~ ^~ ~~ > | | | > | | QgsPoint > | QgsLineString > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgspoint.h:280:10: note: candidate: 'virtual bool QgsPoint::operator==(const QgsAbstractGeometry&) const' (reversed) > 280 | bool operator==( const QgsAbstractGeometry &other ) const override SIP_HOLDGIL > | ^~~~~~~~ > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:46:10: note: candidate: 'virtual bool QgsCurve::operator==(const QgsAbstractGeometry&) const' (rewritten) > 46 | bool operator==( const QgsAbstractGeometry &other ) const override; > | ^~~~~~~~ > /tmp/work/wip/qgis/work/QGIS-a6644ddc2e269e32f6e622f327e5c000774d4759/src/core/geometry/qgscurve.h:47:10: note: candidate: 'virtual bool QgsCurve::operator!=(const QgsAbstractGeometry&) const' > 47 | bool operator!=( const QgsAbstractGeometry &other ) const override; > | ^~~~~~~~ > ninja: build stopped: subcommand failed. > *** Please use pkgtools/verifypc to sanity check dependencies. > *** Error code 1 (continuing) > `all' not remade because of errors. > > Stop. > make[1]: stopped in /n0/gdt/pkgsrc-current/pkgsrc/wip/qgis > *** Error code 1 (continuing) > `all' not remade because of errors. > > Stop. > make: stopped in /usr/pkgsrc/wip/qgis > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -- http://www.spatialys.com My software is free, but my time generally not. From david at opengis.ch Thu Feb 19 06:36:00 2026 From: david at opengis.ch (David Signer) Date: Thu, 19 Feb 2026 15:36:00 +0100 Subject: [QGIS-Developer] Announcing QEP 410: Layer Name in GetFeatureInfo JSON Result Message-ID: Hi everyone We would like to improve the WMS GetFeatureInfo JSON response with reliable layer name information. Please see my QEP here - your feedback is appreciated. https://github.com/qgis/QGIS-Enhancement-Proposals/pull/365 Have a nice day and cheers Dave --- David Signer Senior Developer & INTERLIS Architect Team QGIS & Industry Solutions david at opengis.ch opengis.ch -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.schimmel at sap.com Thu Feb 19 09:04:48 2026 From: florian.schimmel at sap.com (Schimmel, Florian) Date: Thu, 19 Feb 2026 17:04:48 +0000 Subject: [QGIS-Developer] SAP HANA on MacOS In-Reply-To: References: Message-ID: Hey Matthias, thank you for the reply, I like the idea and tried to implement it. I had to work into vcpkg and solve a few issues on the way, that took a while, but I have a working port now. While checking if it is possible to integrate the port in the QGIS build I noticed that there are custom ports in the repository. Since odbccpp is not broadly used, there is probably no application for a vcpkg port outside of QGIS, so would you mind if we add the port directly to the QGIS repository? Thanks Florian From: Matthias Kuhn Date: Friday, 30. January 2026 at 09:51 To: Schimmel, Florian Cc: qgis-developer at lists.osgeo.org Subject: Re: [QGIS-Developer] SAP HANA on MacOS You don't often get email from matthias at opengis.ch. Learn why this is important Hi Florian, Yes, the packages are produced using the build-macos-qt6 workflow. One thing I'd also suggest is to make it possible use the odbccpp library as an external dependency (compared to the current vendored copy), this would allow us to cache the prebuilt package in the workflow runs and support performance in our CI/CD pipelines. This would require a few tweaks like adding a vcpkg port, use a cmake target to link to the library and adding a cmake toggle to switch between using the vendored and an externally provided copy. Thanks Matthias On Thu, Jan 29, 2026 at 8:46?AM Schimmel, Florian via QGIS-Developer > wrote: Hi, I?m a developer in the geospatial team of SAP HANA. We were noticed that HANA is not available on the new releases of QGIS on MacOS. I built it locally and it is available with the WITH_HANA=TRUE option in cmake. So, I think it's simply not added during the release process, maybe after the switch to qt6 and the use of vcpkg. I?m not sure about the exact process, which creates the releases. Would it suffice to add it in the build-macos-qt6 workflow? And if so, would it be ok to do this? In that case I would open a pull-request. Let me know if I?m missing something. I will happily check again. Thanks for taking the time, Florian _______________________________________________ QGIS-Developer mailing list QGIS-Developer at lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman.barker at gmail.com Thu Feb 19 15:46:45 2026 From: norman.barker at gmail.com (Norman Barker) Date: Thu, 19 Feb 2026 17:46:45 -0600 Subject: [QGIS-Developer] STAC PR In-Reply-To: References: Message-ID: Hi, I have had time to made changes to https://github.com/qgis/QGIS/pull/62656 which you can see here https://github.com/qgis/QGIS/compare/master...AnalyticaSpatial:QGIS:nb/stac_updates?expand=1 . This restricts the changes to raster providers and brings in GDAL VSI object stores beyond s3. It also enables the reading of TileDB arrays. Can the PR above ( https://github.com/qgis/QGIS/pull/62656 ) be re-opened and if the changes are satisfactory, then merged. Thanks, Norman On Tue, Sep 30, 2025 at 12:53?PM Norman Barker wrote: > Hi, > > I have been developing https://github.com/qgis/QGIS/pull/62656 to make > the QGIS STAC client work with other cloud providers and also to support > other cloud optimized data types. > > I have been keeping the PR open but it was finally marked stale because I > missed a message from github. Can this PR be re-opened? > > Also if there is interest can it be reviewed as I am happy to keep working > on the internal STAC implementation. > > Many thanks, > > Norman > -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Thu Feb 19 16:37:28 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 20 Feb 2026 01:37:28 +0100 Subject: [QGIS-Developer] SAP HANA on MacOS In-Reply-To: References: Message-ID: Le 19/02/2026 ? 18:04, Schimmel, Florian via QGIS-Developer a ?crit?: > Hey Matthias, > > thank you for the reply, I like the idea and tried to implement it. I > had to work into vcpkg and solve a few issues on the way, that took a > while, but I have a working port now. While checking if it is possible > to integrate the port in the QGIS build I noticed that there are > custom ports in the repository. Since odbccpp is not broadly used, > there is probably no application for a vcpkg port outside of QGIS, so > would you mind if we add the port directly to the QGIS repository? The GDAL HANA driver depends on odbccpp too, so for GDAL vcpkg users, having a standalone port could make sense -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Fri Feb 20 06:00:00 2026 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 20 Feb 2026 17:00:00 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from February 9th to February 20th, 2026 Message-ID: Hello everyone, Please find some highlights regarding the development and maintenance of the QGIS Websites for the last two weeks, from February 9th to February 20th, 2026. *QGIS.org:* - Move Hugo theme to submodule [New PR] - Review and deploy the translated website to https://staging.qgis.org [see credentials at https://github.com/qgis/QGIS-Website/pull/696#issuecomment-3920433936 ] *QGIS Plugins:* - Move the login button and highlight no login required for download [Deployed] - Update invalid links in test packages [Deployed] - Allow uploading an empty plugin [Deployed] - Fix code formatting in security scan result [Deployed] - Improve API response handling for token-based upload [Deployed] - Disable pointer events for right ribbon overlay [Deployed] *QGIS Hub:* - Allow swiping through maps and screenshot [Deployed] - Handle screenshots and processing scripts domains [Deployed] - Show download button for reviewer in review details page [Deployed] - Show animated GIFs in details and review page [Deployed] *QGIS Feed:* - Deploy the news feed review process improvements on https://staging.feed.qgis.org Have a nice weekend, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.schimmel at sap.com Fri Feb 20 06:47:34 2026 From: florian.schimmel at sap.com (Schimmel, Florian) Date: Fri, 20 Feb 2026 14:47:34 +0000 Subject: [QGIS-Developer] SAP HANA on MacOS In-Reply-To: References: Message-ID: Hey Even, Thanks for the hint, that makes sense. I will add it to the vcpkg repo and note this thread again after it is merged and the QGIS change is pushed. Best regards Florian From: Even Rouault Date: Friday, 20. February 2026 at 01:37 To: Schimmel, Florian , Matthias Kuhn Cc: qgis-developer at lists.osgeo.org Subject: Re: [QGIS-Developer] SAP HANA on MacOS You don't often get email from even.rouault at spatialys.com. Learn why this is important Le 19/02/2026 ? 18:04, Schimmel, Florian via QGIS-Developer a ?crit : Hey Matthias, thank you for the reply, I like the idea and tried to implement it. I had to work into vcpkg and solve a few issues on the way, that took a while, but I have a working port now. While checking if it is possible to integrate the port in the QGIS build I noticed that there are custom ports in the repository. Since odbccpp is not broadly used, there is probably no application for a vcpkg port outside of QGIS, so would you mind if we add the port directly to the QGIS repository? The GDAL HANA driver depends on odbccpp too, so for GDAL vcpkg users, having a standalone port could make sense -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Sun Feb 22 06:57:20 2026 From: gdt at lexort.com (Greg Troxel) Date: Sun, 22 Feb 2026 09:57:20 -0500 Subject: [QGIS-Developer] building master in pkgsrc; mostly ok! In-Reply-To: <4238ef3c-5f51-4180-b99b-1442a9992ef3@spatialys.com> (Even Rouault's message of "Thu, 19 Feb 2026 00:47:50 +0100") References: <4238ef3c-5f51-4180-b99b-1442a9992ef3@spatialys.com> Message-ID: (following up more widely for those not watching the repo closely) Even Rouault writes: > While playing with compiler explorer (https://godbolt.org/z/v1GEGnT6j) > I suspect this is a bug in C++20 support in gcc 12 that got fixed in > gcc 13 (similary clang 15 has the same issue, and clang 16 > not). Likely an erratum of C++20 that didn't make it in early > implementations. You could workaround it by down casting the left side > member of the comparisons to (const QgsAbstractGeometry&) Thanks for figuring that out. The downcasts make it build with gcc 12.5.0. I submitted a PR, which Nyall munged and merged. I've updated pkgsrc-wip to 7d2ca374f2db34eef5b433d9dbf46ae894ada937. pkgsrc is missing a few qt6 packages, but it builds and packages, and I can open a project and things seem normal. There is a complaint about authentication, which is almost certainly about qgis not reaching the keyring daemon. That works with the 3.44 package, and I'll look into it. I have two patches to validate and maybe submit, both minor. Overall, master heading to 4 is in remarkably good shape for my system, and I think the remaining issues are mostly getting more qt6-foo packaged. From voting at qgis.org Sun Feb 22 19:22:15 2026 From: voting at qgis.org (Voting Officer) Date: Mon, 23 Feb 2026 11:22:15 +0800 Subject: [QGIS-Developer] Community Voting Members Election 2026: Results Message-ID: Hi everyone, Thanks for your patience! On behalf of the PSC, I can now announce the results of the ballot: - Jean-Marie Arsac: 2 votes - Lo?c Bartoletti: 10 votes - Lova Andriarimalala: 12 votes *With space for one new voting member, Lova Andriarimalala is elected.* Congratulations Lova! Big thanks to Jean-Marie, Lo?c, and Lova for agreeing to be nominated for this important role. Thank you to all QGIS committers who voted, your participation is vital. Cheers! John Bryant QGIS Voting Officer -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Sun Feb 22 22:23:50 2026 From: lova at kartoza.com (Lova Andriarimalala) Date: Mon, 23 Feb 2026 09:23:50 +0300 Subject: [QGIS-Developer] Community Voting Members Election 2026: Results In-Reply-To: References: Message-ID: Dear John and all, Thank you for the announcement and for your work as Voting Officer. I am honoured to accept the nomination and to be elected as a Community Voting Member. I would like to thank the QGIS committers for their participation and for placing their trust in me. I also want to extend my gratitude to Jean-Marie Arsac and Lo?c Bartoletti for their commitment to the community. I look forward to serving in this role. 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, 23 Feb 2026 at 06:22, Voting Officer via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi everyone, > > Thanks for your patience! On behalf of the PSC, I can now announce the > results of the ballot: > > - Jean-Marie Arsac: 2 votes > - Lo?c Bartoletti: 10 votes > - Lova Andriarimalala: 12 votes > > *With space for one new voting member, Lova Andriarimalala is elected.* > > Congratulations Lova! Big thanks to Jean-Marie, Lo?c, and Lova for > agreeing to be nominated for this important role. Thank you to all QGIS > committers who voted, your participation is vital. > > Cheers! > > John Bryant > QGIS Voting Officer > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jef at norbit.de Mon Feb 23 01:19:58 2026 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Mon, 23 Feb 2026 10:19:58 +0100 Subject: [QGIS-Developer] Realistically, we can't release in 2 days ? In-Reply-To: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> References: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> Message-ID: <20260223091958.2ga4cyeykihmxjcl@norbit.de> Hi Nyall, On Wed, 18. Feb 2026 at 16:49:37 +0100, J?rgen E. Fischer wrote: > On Wed, 18. Feb 2026 at 14:05:58 +1000, Nyall Dawson via QGIS-Developer wrote: > > Everyone who has been actively testing 4.0 nightlies has probably seen this > > coming, but we're just NOT ready to publicly release 4.0 on the 20th. Aside > > from anything else, we still don't have a fix for the profile corruption > > bug* which should be a blocker alone. With this one a user's 3.x profile > > can get completely corrupted, and/or cause hangs on loading 3.x/4.0. > If we have a blocker we should postpone. How much time do we need? > I suppose we're just moving the release date ahead and don't do additional > releases of 3.40 and 3.44 instead? Did you miss this? 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 IRC: jef on Libera|OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Pflichtangaben URL: From valentin.buira at gmail.com Mon Feb 23 12:47:13 2026 From: valentin.buira at gmail.com (Valentin Buira) Date: Mon, 23 Feb 2026 21:47:13 +0100 Subject: [QGIS-Developer] Call for vote on QEP 407 "Introduce a data viewer for the model designer" Message-ID: Hi all, The QEP 407 about adding a data viewer in the model designer has now passed the two-week threshold, and is now in a state ready for voting. Thank you everyone for your comments and your suggestions on the QEP. Please cast your votes in the pull request : https://github.com/qgis/QGIS-Enhancement-Proposals/pull/359 Thanks in advance for taking the time to vote Kind regards, Valentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Mon Feb 23 20:31:50 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 24 Feb 2026 14:31:50 +1000 Subject: [QGIS-Developer] Realistically, we can't release in 2 days ? In-Reply-To: <20260223091958.2ga4cyeykihmxjcl@norbit.de> References: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> <20260223091958.2ga4cyeykihmxjcl@norbit.de> Message-ID: On Mon, 23 Feb 2026 at 19:20, J?rgen E. Fischer wrote: > Hi Nyall, > > On Wed, 18. Feb 2026 at 16:49:37 +0100, J?rgen E. Fischer wrote: > > On Wed, 18. Feb 2026 at 14:05:58 +1000, Nyall Dawson via QGIS-Developer > wrote: > > > Everyone who has been actively testing 4.0 nightlies has probably seen > this > > > coming, but we're just NOT ready to publicly release 4.0 on the 20th. > Aside > > > from anything else, we still don't have a fix for the profile > corruption > > > bug* which should be a blocker alone. With this one a user's 3.x > profile > > > can get completely corrupted, and/or cause hangs on loading 3.x/4.0. > > > If we have a blocker we should postpone. How much time do we need? > > > I suppose we're just moving the release date ahead and don't do > additional > > releases of 3.40 and 3.44 instead? > > Did you miss this? > Yes, sorry. I've just updated the PR ( https://github.com/qgis/QGIS/pull/64752) which should address the profile corruption. Hopefully that's all good to go now, but I think we should give it at least a couple of days testing in master before proceeding with release. I've no personal opinion regarding 3.40/3.44 releases. 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 IRC: jef on Libera|OFTC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jef at norbit.de Tue Feb 24 04:57:17 2026 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Tue, 24 Feb 2026 13:57:17 +0100 Subject: [QGIS-Developer] Realistically, we can't release in 2 days ? In-Reply-To: References: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> <20260223091958.2ga4cyeykihmxjcl@norbit.de> Message-ID: <20260224125717.mmwr6gtnefjdfnjt@norbit.de> Hi Nyall, On Tue, 24. Feb 2026 at 14:31:50 +1000, Nyall Dawson via QGIS-Developer wrote: > Yes, sorry. I've just updated the PR ( > https://github.com/qgis/QGIS/pull/64752) which should address the profile > corruption. Hopefully that's all good to go now, but I think we should > give it at least a couple of days testing in master before proceeding with > release. Nice - so I moved 4.0 by two weeks. 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 IRC: jef on Libera|OFTC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From gdt at lexort.com Tue Feb 24 05:43:06 2026 From: gdt at lexort.com (Greg Troxel) Date: Tue, 24 Feb 2026 08:43:06 -0500 Subject: [QGIS-Developer] Realistically, we can't release in 2 days ? In-Reply-To: (Nyall Dawson via's message of "Tue, 24 Feb 2026 14:31:50 +1000") References: <20260218154937.3fpn5eslqwf5ewtw@norbit.de> <20260223091958.2ga4cyeykihmxjcl@norbit.de> Message-ID: Nyall Dawson via QGIS-Developer writes: > Yes, sorry. I've just updated the PR ( > https://github.com/qgis/QGIS/pull/64752) which should address the profile > corruption. Hopefully that's all good to go now, but I think we should > give it at least a couple of days testing in master before proceeding with > release. Could you announce here when there is a release candidate, so people can test that specifically? (and then not merge anything else :-) I don't mean to demand a tag; simply saying 'git sha1 foo is 4.0rc1; please test that'. I don't know how many are following along master, but I would think most of them would try to freshen/test. From clhermansen at gmail.com Tue Feb 24 11:12:59 2026 From: clhermansen at gmail.com (chris hermansen) Date: Tue, 24 Feb 2026 11:12:59 -0800 Subject: [QGIS-Developer] Another thought on accepting AI-generated code Message-ID: In case anyone has any further interest in this matter, here is an interesting read with regard to the same topic in relation to matplotlib: https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/?lid=wvyqmthu7d8k -- Chris Hermansen ? clhermansen "at" gmail "dot" com C'est ma fa?on de parler. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at borysjurgiel.pl Tue Feb 24 12:35:34 2026 From: lists at borysjurgiel.pl (Borys Jurgiel) Date: Tue, 24 Feb 2026 21:35:34 +0100 Subject: [QGIS-Developer] =?utf-8?q?Plugins=E2=80=99_Dual_QGIS_3_and_QGIS?= =?utf-8?q?_4_Compatibility?= Message-ID: I just realized that our mess with the `qgis_maximum_version` tag is escalating, and this may be the last moment to rethink whether we really want it to be set automatically. Years ago, I introduced this tag to the plugin installer in order to extend the compatibility range to more than one major version, which is exactly our current case. At the same time, @ElPaso implemented it in the repository application, but somehow we didn?t fully align on the idea: for me it was optional and not meant to be set by default. When it is missing, the plugin installer assumes compatibility up to the very end of the same major version. On the other hand, the repository always sets it to x.99 if it is not present. Many authors then assumed it was mandatory and started tagging plugins as x.99 or x.98. I guess we never really discussed this topic, and now we have a full variety of `qgis_maximum_version` values: either explicitly set by authors or automatically added by the repository. Furthermore, in recent years, the `qt6_compatible` tag was introduced, which made perfect sense at the time. However, it is now redundant if at least one of the version bounds is set to >= 4.0. Everything worked well as long as the PyQGIS API version was 3.99. When it was bumped to 4.0 last year (not to be confused with the general QGIS version), all Qt6-compatible plugins without `qgis_maximum_version` explicitly set to 4 became broken: https://github.com/qgis/QGIS/issues/62359 @JEF partially fixed this in: https://github.com/jef-n/QGIS/commit/eac401c009f11f58c0ac2253c98d35ec6338ca60 However, this only fixed loading plugins that were already installed in QGIS 3. In QGIS 4, they are not available from the official repository, so it is impossible to (re)install them. This happens because the condition `if not qgisMaximumVersion (...) and supports_qt6`: fails twice, as the official repository always returns the `qgis_maximum_version` and never returns `supports_qt6`. This is very unexpected behaviour, so many plugin authors explicitly set `qgis_maximum_version` to 4.99 in their plugins, what is actually how the tag was originally intended to be used in the installer. Currently, there are 171 or 182 such plugins in the official repository with `qgis_maximum_version` explicitly set to >= 4.0 (I don't know how many Qt6-compatible plugins are in the repo in total). I can see two straightforward ways to fix this issue, but they raise a strategic question: do we really want `qgis_maximum_version` to be completed automatically? 1: If we want the function of forcibly bumping Qt6 plugins from 3.x to 4.99 to work properly, it simply needs to be implemented in the official repository application as well, so that such plugins are exposed to the installer as 4.99 rather than 3.99. Pros: everything will work as expected. Cons: we introduce that rather nasty hardcoded 4.99 for a couple of years, and anybody will understand how it works in detail. 2: Or should we return to the original idea: make `qgis_maximum_version` optional, stop adding it in the repository when it is not present (and only handle it internally when resolving the version filter), and strictly require plugin authors to set this tag if they want to support dual major versions? In this scenario, we should also drop the qt6_compatible tag. Pros: we keep things simple and unambiguous. Cons: we break unprepared plugins until their metadata are updated. Personally, I?m fine with either solution, but with this rather long story I just wanted to provide some context on how we ended up here. Thanks to anyone who made it to the end :) Borys From rdmailings at duif.net Thu Feb 26 02:39:24 2026 From: rdmailings at duif.net (Richard Duivenvoorde) Date: Thu, 26 Feb 2026 11:39:24 +0100 Subject: [QGIS-Developer] =?utf-8?q?Plugins=E2=80=99_Dual_QGIS_3_and_QGIS?= =?utf-8?q?_4_Compatibility?= In-Reply-To: References: Message-ID: <44433d5b-9267-4400-b076-0d2e43ac3d17@duif.net> Hi Borys, I fully agree with your analysis (cc'ing lova which is doing current plugins server software). My choice would be your option 2: dropping the Qt6 tag etc etc So what about doing this for QGIS4 only? Would that be an option? When we move to QGIS4/Qt6 metadata and plugins have to be updated anyway. Others? Regards. Richard Duivenvoorde On 2/24/26 21:35, Borys Jurgiel via QGIS-Developer wrote: > I just realized that our mess with the `qgis_maximum_version` tag is escalating, and this may be the last moment to rethink whether we really want it to be set automatically. > > Years ago, I introduced this tag to the plugin installer in order to extend the compatibility range to more than one major version, which is exactly our current case. At the same time, @ElPaso implemented it in the repository application, but somehow we didn?t fully align on the idea: for me it was optional and not meant to be set by default. When it is missing, the plugin installer assumes compatibility up to the very end of the same major version. On the other hand, the repository always sets it to x.99 if it is not present. Many authors then assumed it was mandatory and started tagging plugins as x.99 or x.98. I guess we never really discussed this topic, and now we have a full variety of `qgis_maximum_version` values: either explicitly set by authors or automatically added by the repository. Furthermore, in recent years, the `qt6_compatible` tag was introduced, which made perfect sense at the time. However, it is now redundant if at least one of the version bounds is set > to >= 4.0. > > Everything worked well as long as the PyQGIS API version was 3.99. When it was bumped to 4.0 last year (not to be confused with the general QGIS version), all Qt6-compatible plugins without `qgis_maximum_version` explicitly set to 4 became broken: > > https://github.com/qgis/QGIS/issues/62359 > > @JEF partially fixed this in: > > https://github.com/jef-n/QGIS/commit/eac401c009f11f58c0ac2253c98d35ec6338ca60 > > However, this only fixed loading plugins that were already installed in QGIS 3. In QGIS 4, they are not available from the official repository, so it is impossible to (re)install them. This happens because the condition `if not qgisMaximumVersion (...) and supports_qt6`: fails twice, as the official repository always returns the `qgis_maximum_version` and never returns `supports_qt6`. > > This is very unexpected behaviour, so many plugin authors explicitly set `qgis_maximum_version` to 4.99 in their plugins, what is actually how the tag was originally intended to be used in the installer. Currently, there are 171 or 182 such plugins in the official repository with `qgis_maximum_version` explicitly set to >= 4.0 (I don't know how many Qt6-compatible plugins are in the repo in total). > > I can see two straightforward ways to fix this issue, but they raise a strategic question: do we really want `qgis_maximum_version` to be completed automatically? > > 1: If we want the function of forcibly bumping Qt6 plugins from 3.x to 4.99 to work properly, it simply needs to be implemented in the official repository application as well, so that such plugins are exposed to the installer as 4.99 rather than 3.99. > Pros: everything will work as expected. > Cons: we introduce that rather nasty hardcoded 4.99 for a couple of years, and anybody will understand how it works in detail. > > 2: Or should we return to the original idea: make `qgis_maximum_version` optional, stop adding it in the repository when it is not present (and only handle it internally when resolving the version filter), and strictly require plugin authors to set this tag if they want to support dual major versions? In this scenario, we should also drop the qt6_compatible tag. > Pros: we keep things simple and unambiguous. > Cons: we break unprepared plugins until their metadata are updated. > > Personally, I?m fine with either solution, but with this rather long story I just wanted to provide some context on how we ended up here. Thanks to anyone who made it to the end :) > > Borys > _______________________________________________ > 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 werner.macho at gmail.com Thu Feb 26 03:34:14 2026 From: werner.macho at gmail.com (Werner Macho) Date: Thu, 26 Feb 2026 12:34:14 +0100 Subject: [QGIS-Developer] =?utf-8?q?Plugins=E2=80=99_Dual_QGIS_3_and_QGIS?= =?utf-8?q?_4_Compatibility?= In-Reply-To: <44433d5b-9267-4400-b076-0d2e43ac3d17@duif.net> References: <44433d5b-9267-4400-b076-0d2e43ac3d17@duif.net> Message-ID: Hi Borys, all, I also made it through the mail and would prefer option 2. In such cases I prefer taking away the automation things and make the developers of the plugin responsible again. metadata updating should only be a matter of minutes for every plugin dev. regards Werner On Thu, Feb 26, 2026 at 11:40?AM Richard Duivenvoorde via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi Borys, > > I fully agree with your analysis (cc'ing lova which is doing current > plugins server software). > > My choice would be your option 2: dropping the Qt6 tag etc etc > > So what about doing this for QGIS4 only? Would that be an option? > When we move to QGIS4/Qt6 metadata and plugins have to be updated anyway. > > Others? > > Regards. > > Richard Duivenvoorde > > > On 2/24/26 21:35, Borys Jurgiel via QGIS-Developer wrote: > > I just realized that our mess with the `qgis_maximum_version` tag is > escalating, and this may be the last moment to rethink whether we really > want it to be set automatically. > > > > Years ago, I introduced this tag to the plugin installer in order to > extend the compatibility range to more than one major version, which is > exactly our current case. At the same time, @ElPaso implemented it in the > repository application, but somehow we didn?t fully align on the idea: for > me it was optional and not meant to be set by default. When it is missing, > the plugin installer assumes compatibility up to the very end of the same > major version. On the other hand, the repository always sets it to x.99 if > it is not present. Many authors then assumed it was mandatory and started > tagging plugins as x.99 or x.98. I guess we never really discussed this > topic, and now we have a full variety of `qgis_maximum_version` values: > either explicitly set by authors or automatically added by the repository. > Furthermore, in recent years, the `qt6_compatible` tag was introduced, > which made perfect sense at the time. However, it is now redundant if at > least one of the version bounds is set > > to >= 4.0. > > > > Everything worked well as long as the PyQGIS API version was 3.99. When > it was bumped to 4.0 last year (not to be confused with the general QGIS > version), all Qt6-compatible plugins without `qgis_maximum_version` > explicitly set to 4 became broken: > > > > https://github.com/qgis/QGIS/issues/62359 > > > > @JEF partially fixed this in: > > > > > https://github.com/jef-n/QGIS/commit/eac401c009f11f58c0ac2253c98d35ec6338ca60 > > > > However, this only fixed loading plugins that were already installed in > QGIS 3. In QGIS 4, they are not available from the official repository, so > it is impossible to (re)install them. This happens because the condition > `if not qgisMaximumVersion (...) and supports_qt6`: fails twice, as the > official repository always returns the `qgis_maximum_version` and never > returns `supports_qt6`. > > > > This is very unexpected behaviour, so many plugin authors explicitly set > `qgis_maximum_version` to 4.99 in their plugins, what is actually how the > tag was originally intended to be used in the installer. Currently, there > are 171 or 182 such plugins in the official repository with > `qgis_maximum_version` explicitly set to >= 4.0 (I don't know how many > Qt6-compatible plugins are in the repo in total). > > > > I can see two straightforward ways to fix this issue, but they raise a > strategic question: do we really want `qgis_maximum_version` to be > completed automatically? > > > > 1: If we want the function of forcibly bumping Qt6 plugins from 3.x to > 4.99 to work properly, it simply needs to be implemented in the official > repository application as well, so that such plugins are exposed to the > installer as 4.99 rather than 3.99. > > Pros: everything will work as expected. > > Cons: we introduce that rather nasty hardcoded 4.99 for a couple of > years, and anybody will understand how it works in detail. > > > > 2: Or should we return to the original idea: make `qgis_maximum_version` > optional, stop adding it in the repository when it is not present (and only > handle it internally when resolving the version filter), and strictly > require plugin authors to set this tag if they want to support dual major > versions? In this scenario, we should also drop the qt6_compatible tag. > > Pros: we keep things simple and unambiguous. > > Cons: we break unprepared plugins until their metadata are updated. > > > > Personally, I?m fine with either solution, but with this rather long > story I just wanted to provide some context on how we ended up here. Thanks > to anyone who made it to the end :) > > > > Borys > > _______________________________________________ > > QGIS-Developer mailing list > > QGIS-Developer at lists.osgeo.org > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gongch2024 at gmail.com Thu Feb 26 10:48:07 2026 From: gongch2024 at gmail.com (Chao Gong) Date: Thu, 26 Feb 2026 18:48:07 +0000 Subject: [QGIS-Developer] =?utf-8?q?=5BPlugin_Release=5D_Ireland_Nearest_?= =?utf-8?q?Analysis_=E2=80=93_Irish_Grid_=28EPSG=3A29902=29_Nearest?= =?utf-8?q?_Feature_=26_Official_API_Integration?= Message-ID: Dear QGIS community, I am pleased to announce the release of a new QGIS plugin: Plugin Name: Ireland Nearest Analysis (Irish Grid + Official API) Version: 1.1.4 Compatible with: QGIS 3.28+ *Overview* Ireland Nearest Analysis is a QGIS plugin designed specifically for Ireland-only spatial workflows. It supports projects using the Irish Grid (EPSG:29902) and integrates with Ireland?s official spatial API for automated data retrieval and nearest feature analysis. *Main Features* Designed for Irish Grid (EPSG:29902) projects Integration with Ireland official spatial API (internet connection required) Nearest feature analysis Automatic distance and bearing calculation CSV export of analysis results *Requirements* Project CRS must be EPSG:29902 (Irish Grid) Internet connection required for API access *Repository* Source code (GitHub): https://github.com/chao515737/nearest_analysis_plugin Issue tracker: https://github.com/chao515737/nearest_analysis_plugin/issues Documentation / Homepage: https://github.com/chao515737/nearest_analysis_plugin The plugin is open source and feedback, bug reports, and feature suggestions are very welcome. Best regards, Chao Gong Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: