From nyall.dawson at gmail.com Wed Jun 3 20:51:55 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Thu, 4 Jun 2026 13:51:55 +1000 Subject: [Qgis-psc] QEP: Add Exceptional Breakage clause to stable API policy Message-ID: Hi lists, Following up the recent formalisation of the PyQGIS stable API policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-425-stable-api.md), I've just submitted a proposed change to this policy to add a mechanism to allow API breaks in EXCEPTIONAL circumstances. See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/384 for the proposed changes and a detailed write up on the rationale behind this change. Please give all feedback on this proposed change as comments on the PR itself (not direct email replies) to keep the discussion centralized. Kind regards, Nyall -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Mon Jun 8 13:58:40 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 9 Jun 2026 06:58:40 +1000 Subject: [Qgis-psc] QEP426: Demotion of DB Manager plugin to community plugin Message-ID: Hi lists, I've just submitted QEP426: "Demotion of DB Manager plugin to community plugin" (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385) Historically, the DB Manager plugin was a critical component of the QGIS ecosystem, providing essential database administration and querying capabilities. However, over the 3.x development cycle, the direction of QGIS shifted toward integrating all database related functionality into the Browser Panel. This provides a better user experience, by exposing database tools alongside other layer and connection management tools. The browser-based functionality is all designed around generic, heavily tested connection APIs, which are also used by many other areas of QGIS. In contrast, the DB Manager plugin contains all its own logic and code for handling database integration, with extremely minimal (almost non-existent) test coverage. As of QGIS 4.2, the core functionality of the DB Manager has been fully ported to the built-in Browser Panel. Users can natively manage schemas, create and delete tables, manage fields, and execute SQL queries directly within the core interface. Maintaining the DB Manager plugin as a core component now duplicates this functionality, bloating the codebase and creating unnecessary maintenance overhead for core developers. This QEP proposes that DB Manager is demoted to a 3rd party, community maintained plugin, and describes the plan to implement this change. The full proposal and plan is available at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385 for discussion. Please don't reply to this email -- replies should be commented on the QEP itself to keep discussion centralised. Nyall -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at kartoza.com Tue Jun 9 00:16:17 2026 From: tim at kartoza.com (Tim Sutton) Date: Tue, 9 Jun 2026 08:16:17 +0100 Subject: [Qgis-psc] QEP426: Demotion of DB Manager plugin to community plugin In-Reply-To: References: Message-ID: Thanks Nyall and so long to the DB Manager, it has been a great component of QGIS all these years, glad to have all of its functionality implemented in core now! Regards Tim On Mon, Jun 8, 2026 at 9:59?PM Nyall Dawson via QGIS-PSC < qgis-psc at lists.osgeo.org> wrote: > Hi lists, > > I've just submitted QEP426: "Demotion of DB Manager plugin to community > plugin" (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385) > > Historically, the DB Manager plugin was a critical component of the QGIS > ecosystem, providing essential database administration and querying > capabilities. However, over the 3.x development cycle, the direction of > QGIS shifted toward integrating all database related functionality into the > Browser Panel. This provides a better user experience, by exposing database > tools alongside other layer and connection management tools. The > browser-based functionality is all designed around generic, heavily tested > connection APIs, which are also used by many other areas of QGIS. In > contrast, the DB Manager plugin contains all its own logic and code for > handling database integration, with extremely minimal (almost non-existent) > test coverage. > > As of QGIS 4.2, the core functionality of the DB Manager has been fully > ported to the built-in Browser Panel. Users can natively manage schemas, > create and delete tables, manage fields, and execute SQL queries directly > within the core interface. Maintaining the DB Manager plugin as a core > component now duplicates this functionality, bloating the codebase and > creating unnecessary maintenance overhead for core developers. > > This QEP proposes that DB Manager is demoted to a 3rd party, community > maintained plugin, and describes the plan to implement this change. > The full proposal and plan is available at > https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385 for > discussion. > > Please don't reply to this email -- replies should be commented on the QEP > itself to keep discussion centralised. > > Nyall > > _______________________________________________ > QGIS-PSC mailing list > QGIS-PSC at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/qgis-psc > -- Tim Sutton *Kartoza Cofounder*Tim is a member of the QGIS Project Steering Committee *T *: +27(0) 87 809 2702 *E *: tim at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Mon Jun 15 16:12:39 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 16 Jun 2026 09:12:39 +1000 Subject: [Qgis-psc] QEP: Add Exceptional Breakage clause to stable API policy In-Reply-To: References: Message-ID: On Thu, 4 Jun 2026 at 13:51, Nyall Dawson wrote: > > Hi lists, > > Following up the recent formalisation of the PyQGIS stable API policy (see https://github.com/qgis/QGIS-Enhancement-Proposals/blob/master/qep-425-stable-api.md), I've just submitted a proposed change to this policy to add a mechanism to allow API breaks in EXCEPTIONAL circumstances. > > See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/384 for the proposed changes and a detailed write up on the rationale behind this change. > > Please give all feedback on this proposed change as comments on the PR itself (not direct email replies) to keep the discussion centralized. This QEP has now progressed to the voting stage -- please cast your votes accordingly! Nyall From r.aguilar at utwente.nl Wed Jun 17 00:08:08 2026 From: r.aguilar at utwente.nl (Aguilar Bolivar, Rosa (UT-ITC)) Date: Wed, 17 Jun 2026 07:08:08 +0000 Subject: [Qgis-psc] Call for transparency - Generative AI plugins In-Reply-To: <216199f6-015a-4411-8a08-00c3d7c86558@gmx.at> References: <216199f6-015a-4411-8a08-00c3d7c86558@gmx.at> Message-ID: Dear PSC, First, I would like to express my appreciation for the continuous efforts invested in maintaining QGIS as a reliable and high-quality platform. I would like to draw your attention to the growing presence of AI-related plugins within the QGIS ecosystem. In my view, it is essential to ensure transparency for end users regarding which large language models (LLMs) are being utilized, as well as how user data may be processed, transmitted, or stored. As a specific example, I recently reviewed the Geo Knowledge AI plugin (https://github.com/robert6757/qgis-geo-knowledge-ai) and observed that no API key is required for its operation. Upon further inspection of the code, it appears that requests are routed to a remote server (as indicated in: https://github.com/robert6757/qgis-geo-knowledge-ai/blob/main/global_defs.py). While I am not certain of the best mechanism to address this, one potential approach could be the introduction of a developer declaration or compliance option (e.g., a checkbox or metadata field). This could require plugin developers to explicitly disclose key aspects such as the underlying AI model in use and the nature of any data collection, transmission, or processing. Such measures would enhance transparency and support users in making informed decisions. 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 regis at qgis.org Wed Jun 17 07:10:35 2026 From: regis at qgis.org (=?UTF-8?Q?R=C3=A9gis_Haubourg?=) Date: Wed, 17 Jun 2026 16:10:35 +0200 Subject: [Qgis-psc] Call for transparency - Generative AI plugins In-Reply-To: References: <216199f6-015a-4411-8a08-00c3d7c86558@gmx.at> Message-ID: Hi Rosa, thanks a lot for raising this issue. I agree that such plugins can be an issue with data privacy and probably security. I had a look at how Mozilla handles extensions [0] and I agree that we should aim toward more explicit consent and authorization model. Generally speaking, I think we should embrass privacy statements for our plugin repository. All data collection should be opt-in, so qgis-geo-knowledge-ai would then be not conformed with its default permissions. Ideally a permission system should block a plugin sending data without explicit permissions. Any other thoughts? [0] https://extensionworkshop.com/documentation/publish/add-on-policies/#data-collection-and-transmission-disclosure-and-control Best regards, R?gis Haubourg Elected member at the Program Steering Comitee of QGIS.org. Best regards, R?gis Haubourg Elected member at the Program Steering Comitee of QGIS.org. - On 17/06/2026 09:08, Aguilar Bolivar, Rosa (UT-ITC) via QGIS-PSC wrote: > > Dear PSC, > > First, I would like to express my appreciation for the continuous > efforts invested in maintaining QGIS as a reliable and high-quality > platform. > > I would like to draw your attention to the growing presence of > AI-related plugins within the QGIS ecosystem. > > In my view, it is essential to ensure transparency for end users > regarding which large language models (LLMs) are being utilized, as > well as how user data may be processed, transmitted, or stored. > > As a specific example, I recently reviewed the Geo Knowledge AI plugin > (https://github.com/robert6757/qgis-geo-knowledge-ai) and observed > that no API key is required for its operation. Upon further inspection > of the code, it appears that requests are routed to a remote server > (as indicated in: > https://github.com/robert6757/qgis-geo-knowledge-ai/blob/main/global_defs.py). > > While I am not certain of the best mechanism to address this, one > potential approach could be the introduction of a developer > declaration or compliance option (e.g., a checkbox or metadata field). > This could require plugin developers to explicitly disclose key > aspects such as the underlying AI model in use and the nature of any > data collection, transmission, or processing. Such measures would > enhance transparency and support users in making informed decisions. > > Best regards, > > Rosa > > From regis at qgis.org Wed Jun 17 07:08:07 2026 From: regis at qgis.org (=?UTF-8?Q?R=C3=A9gis_Haubourg?=) Date: Wed, 17 Jun 2026 16:08:07 +0200 Subject: [Qgis-psc] Call for transparency - Generative AI plugins In-Reply-To: References: <216199f6-015a-4411-8a08-00c3d7c86558@gmx.at> Message-ID: Hi Rosa, thanks a lot for raising this issue. I agree that such plugins can be an issue with data privacy and probably security. I had a look at how Mozilla handles extensions [0] and I agree that we should aim toward more explicit consent and authorization model. Generally speaking, I think we should embrass privacy statements for our plugin repository. All data collection should be opt-in, so qgis-geo-knowledge-ai would then be not conformed with its default permissions. Ideally a permission system should block a plugin sending data without explicit permissions. Any other thoughts? [0] https://extensionworkshop.com/documentation/publish/add-on-policies/#data-collection-and-transmission-disclosure-and-control Best regards, R?gis Haubourg Elected member at the Program Steering Comitee of QGIS.org. - On 17/06/2026 09:08, Aguilar Bolivar, Rosa (UT-ITC) via QGIS-PSC wrote: > > Dear PSC, > > First, I would like to express my appreciation for the continuous > efforts invested in maintaining QGIS as a reliable and high-quality > platform. > > I would like to draw your attention to the growing presence of > AI-related plugins within the QGIS ecosystem. > > In my view, it is essential to ensure transparency for end users > regarding which large language models (LLMs) are being utilized, as > well as how user data may be processed, transmitted, or stored. > > As a specific example, I recently reviewed the Geo Knowledge AI plugin > (https://github.com/robert6757/qgis-geo-knowledge-ai) and observed > that no API key is required for its operation. Upon further inspection > of the code, it appears that requests are routed to a remote server > (as indicated in: > https://github.com/robert6757/qgis-geo-knowledge-ai/blob/main/global_defs.py). > > While I am not certain of the best mechanism to address this, one > potential approach could be the introduction of a developer > declaration or compliance option (e.g., a checkbox or metadata field). > This could require plugin developers to explicitly disclose key > aspects such as the underlying AI model in use and the nature of any > data collection, transmission, or processing. Such measures would > enhance transparency and support users in making informed decisions. > > 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 > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 318796 bytes Desc: not available URL: From r.aguilar at utwente.nl Wed Jun 17 23:36:03 2026 From: r.aguilar at utwente.nl (Aguilar Bolivar, Rosa (UT-ITC)) Date: Thu, 18 Jun 2026 06:36:03 +0000 Subject: [Qgis-psc] Call for transparency - Generative AI plugins In-Reply-To: References: <216199f6-015a-4411-8a08-00c3d7c86558@gmx.at> Message-ID: Hi, Regis Thanks for your reply. I see in two steps: 1) Address this explicitly in the plugin development guidelines (https://docs.qgis.org/3.44/en/docs/pyqgis_developer_cookbook/plugins/index.html); and 2) at the approval stage, the developer should add , e.g., in the metadata, what services are used and how ? if any ? data is collected. An explicit user consent should be added when data is collected. My two cents 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] From: QGIS-PSC On Behalf Of R?gis Haubourg via QGIS-PSC Sent: Wednesday, 17 June 2026 16:08 To: qgis-psc at lists.osgeo.org Subject: Re: [Qgis-psc] Call for transparency - Generative AI plugins Hi Rosa, thanks a lot for raising this issue. I agree that such plugins can be an issue with data privacy and probably security. I had a look at how Mozilla handles extensions [0] and I agree that we should aim toward more explicit consent and authorization model. Generally speaking, I think we should embrass privacy statements for our plugin repository. All data collection should be opt-in, so qgis-geo-knowledge-ai would then be not conformed with its default permissions. Ideally a permission system should block a plugin sending data without explicit permissions. Any other thoughts? [0] https://extensionworkshop.com/documentation/publish/add-on-policies/#data-collection-and-transmission-disclosure-and-control Best regards, R?gis Haubourg Elected member at the Program Steering Comitee of QGIS.org. - On 17/06/2026 09:08, Aguilar Bolivar, Rosa (UT-ITC) via QGIS-PSC wrote: Dear PSC, First, I would like to express my appreciation for the continuous efforts invested in maintaining QGIS as a reliable and high-quality platform. I would like to draw your attention to the growing presence of AI-related plugins within the QGIS ecosystem. In my view, it is essential to ensure transparency for end users regarding which large language models (LLMs) are being utilized, as well as how user data may be processed, transmitted, or stored. As a specific example, I recently reviewed the Geo Knowledge AI plugin (https://github.com/robert6757/qgis-geo-knowledge-ai) and observed that no API key is required for its operation. Upon further inspection of the code, it appears that requests are routed to a remote server (as indicated in: https://github.com/robert6757/qgis-geo-knowledge-ai/blob/main/global_defs.py). While I am not certain of the best mechanism to address this, one potential approach could be the introduction of a developer declaration or compliance option (e.g., a checkbox or metadata field). This could require plugin developers to explicitly disclose key aspects such as the underlying AI model in use and the nature of any data collection, transmission, or processing. Such measures would enhance transparency and support users in making informed decisions. 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] _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 318796 bytes Desc: image001.jpg URL: From tim at qgis.org Thu Jun 18 12:39:30 2026 From: tim at qgis.org (Tim Sutton) Date: Thu, 18 Jun 2026 20:39:30 +0100 Subject: [Qgis-psc] Call for transparency - Generative AI plugins In-Reply-To: References: <216199f6-015a-4411-8a08-00c3d7c86558@gmx.at> Message-ID: Hi Rosa Thanks for this. Indeed, Lova and I are already thinking along these lines with adding various tags for security, maintainership, compliance and adding LLM declarations (e.g. completely vibe coded, vibe coded with human review, ai completion assisted, no LLM used). Probably better we also use explicit terminology (LLM vs AI). Then you are also raising another issue which is upstream services used (and whether they are used with permission, if I understand you right). I'm CC'ing in Lova who is our miracle worker on the backend. Regards Tim On Wed, Jun 17, 2026 at 3:10?PM R?gis Haubourg via QGIS-PSC < qgis-psc at lists.osgeo.org> wrote: > Hi Rosa, thanks a lot for raising this issue. > > I agree that such plugins can be an issue with data privacy and probably > security. > > I had a look at how Mozilla handles extensions [0] and I agree that we > should aim toward more explicit consent and authorization model. > > Generally speaking, I think we should embrass privacy statements for our > plugin repository. All data collection should be opt-in, so > qgis-geo-knowledge-ai would then be not conformed with its default > permissions. > Ideally a permission system should block a plugin sending data without > explicit permissions. > > Any other thoughts? > > [0] > > https://extensionworkshop.com/documentation/publish/add-on-policies/#data-collection-and-transmission-disclosure-and-control > > Best regards, > > R?gis Haubourg > Elected member at the Program Steering Comitee of QGIS.org. > > > Best regards, > > R?gis Haubourg > Elected member at the Program Steering Comitee of QGIS.org. > - > > On 17/06/2026 09:08, Aguilar Bolivar, Rosa (UT-ITC) via QGIS-PSC wrote: > > > > Dear PSC, > > > > First, I would like to express my appreciation for the continuous > > efforts invested in maintaining QGIS as a reliable and high-quality > > platform. > > > > I would like to draw your attention to the growing presence of > > AI-related plugins within the QGIS ecosystem. > > > > In my view, it is essential to ensure transparency for end users > > regarding which large language models (LLMs) are being utilized, as > > well as how user data may be processed, transmitted, or stored. > > > > As a specific example, I recently reviewed the Geo Knowledge AI plugin > > (https://github.com/robert6757/qgis-geo-knowledge-ai) and observed > > that no API key is required for its operation. Upon further inspection > > of the code, it appears that requests are routed to a remote server > > (as indicated in: > > > https://github.com/robert6757/qgis-geo-knowledge-ai/blob/main/global_defs.py > ). > > > > While I am not certain of the best mechanism to address this, one > > potential approach could be the introduction of a developer > > declaration or compliance option (e.g., a checkbox or metadata field). > > This could require plugin developers to explicitly disclose key > > aspects such as the underlying AI model in use and the nature of any > > data collection, transmission, or processing. Such measures would > > enhance transparency and support users in making informed decisions. > > > > Best regards, > > > > Rosa > > > > > _______________________________________________ > QGIS-PSC mailing list > QGIS-PSC at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/qgis-psc > -- *Tim Sutton* QGIS Project Steering Committee tim at qgis.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.aguilar at utwente.nl Fri Jun 19 00:10:53 2026 From: r.aguilar at utwente.nl (Aguilar Bolivar, Rosa (UT-ITC)) Date: Fri, 19 Jun 2026 07:10:53 +0000 Subject: [Qgis-psc] Call for transparency - Generative AI plugins In-Reply-To: References: <216199f6-015a-4411-8a08-00c3d7c86558@gmx.at> Message-ID: Hi, Tim Yes, I refer to the model/platform used for processing (prompts), for example gpt x, claude x, qwen etc. And whether data is collecting for training. Not the AI assisting tool used for coding. ? Best, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From strk at kbt.io Sun Jun 21 12:10:13 2026 From: strk at kbt.io (Sandro Santilli) Date: Sun, 21 Jun 2026 21:10:13 +0200 Subject: [Qgis-psc] [QGIS-Developer] QEP426: Demotion of DB Manager plugin to community plugin In-Reply-To: References: Message-ID: On Tue, Jun 09, 2026 at 06:58:40AM +1000, Nyall Dawson via QGIS-Developer wrote: > As of QGIS 4.2, the core functionality of the DB Manager has been fully > ported to the built-in Browser Panel. Does it mean TopologyViewer was also ported ? That part was the focus of https://github.com/qgis/QGIS-Enhancement-Proposals/pull/360 --strk; -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From even.rouault at spatialys.com Sun Jun 21 12:45:52 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 21 Jun 2026 21:45:52 +0200 Subject: [Qgis-psc] [QGIS-Developer] QEP426: Demotion of DB Manager plugin to community plugin In-Reply-To: References: Message-ID: Le 21/06/2026 ? 21:10, Sandro Santilli via QGIS-Developer a ?crit?: > On Tue, Jun 09, 2026 at 06:58:40AM +1000, Nyall Dawson via QGIS-Developer wrote: > >> As of QGIS 4.2, the core functionality of the DB Manager has been fully >> ported to the built-in Browser Panel. > Does it mean TopologyViewer was also ported ? > That part was the focus of https://github.com/qgis/QGIS-Enhancement-Proposals/pull/360 $ grep -ri topo src/core/browser/ (empty output) -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot From nyall.dawson at gmail.com Mon Jun 22 16:34:54 2026 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Tue, 23 Jun 2026 09:34:54 +1000 Subject: [Qgis-psc] QEP426: Demotion of DB Manager plugin to community plugin In-Reply-To: References: Message-ID: On Tue, 9 Jun 2026 at 06:58, Nyall Dawson wrote: > > Hi lists, > > I've just submitted QEP426: "Demotion of DB Manager plugin to community plugin" (https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385) > > Historically, the DB Manager plugin was a critical component of the QGIS ecosystem, providing essential database administration and querying capabilities. However, over the 3.x development cycle, the direction of QGIS shifted toward integrating all database related functionality into the Browser Panel. This provides a better user experience, by exposing database tools alongside other layer and connection management tools. The browser-based functionality is all designed around generic, heavily tested connection APIs, which are also used by many other areas of QGIS. In contrast, the DB Manager plugin contains all its own logic and code for handling database integration, with extremely minimal (almost non-existent) test coverage. > > As of QGIS 4.2, the core functionality of the DB Manager has been fully ported to the built-in Browser Panel. Users can natively manage schemas, create and delete tables, manage fields, and execute SQL queries directly within the core interface. Maintaining the DB Manager plugin as a core component now duplicates this functionality, bloating the codebase and creating unnecessary maintenance overhead for core developers. > > This QEP proposes that DB Manager is demoted to a 3rd party, community maintained plugin, and describes the plan to implement this change. > > The full proposal and plan is available at https://github.com/qgis/QGIS-Enhancement-Proposals/pull/385 for discussion. > > Please don't reply to this email -- replies should be commented on the QEP itself to keep discussion centralised. This QEP has passed the 2 week discussion period and is ready for voting now Kind regards, Nyall > > Nyall >