Re: [QGIS-Developer] QGIS Full Stack Web Developer Report
@Matthias Kuhn and @Julien Moura I fixed the permissions, the board for Lova is public now. Please feel free to add items to the backlog and mark them as priority as needed. I also asked Lova to try to work through all the old issues and fix / close them as appropriate so we can try to get the number of tickets down to a small number. Regards Tim On Sat, Nov 25, 2023 at 8:37 AM Matthias Kuhn wrote: > Hi, > > Thank you very much Lova for working on this application, it's a very > important piece in the QGIS ecosystem! > > For the current discussion, I would also suggest making the license > recommended for now and only start enforcing it on a schedule. And I was > wondering if a license field in the metadata.txt would be even better (cmp. > https://python-poetry.org/docs/pyproject/#license), that would be easier > to show on the plugin page? > > Is there any way to help prioritizing the issues? I have some wishes that > I would love to see land on the backlog > > Kind regards and thanks again for all the good work on this ! > Matthias > > On Fri, Nov 24, 2023 at 11:49 AM Julien Moura via QGIS-Developer < > qgis-developer@lists.osgeo.org> wrote: > >> Dear Tim, >> >> Thanks for taking in account my thoughts and make the discussion possible. >> >> Regarding the second about change management, I totally agree and feel >> really thankful that you make those changes. I can imagine the work it >> represents for your teams maintaining a project like this one. So thank you >> again. >> >> Regarding your proposal about the license requirements, why not starting >> apply the change management to this? It's a breaking change, even for new >> plugins, right? So, it should be lowered to a non blocking warning, >> documented in PyQGIS cookbook and then deployed as a blocking error in a >> known time windows. This way, in the meanwhile, the plugins ecosystem can >> adapt to new rules (new versions for tools like minimal plugin, >> qgis-plugin-ci, plugin builder...) and make this change more acceptable and >> frictionless. >> >> Moreover, the rationale behind the required license file into the plugin >> archive is still not solved. >> >> If you want, I can make a PR to change the warning but I'm pretty sure >> that's not the question here. >> >> https://github.com/orgs/qgis/projects/6 >> >> Just to let you know this hyperlink leads to a 404 (probably a Github >> rights access setting somewhere). >> >> Regards >> On 24/11/2023 10:50, Tim Sutton wrote: >> >> Dear Julien >> >> Thank you so much for your engagement and suggestions. Fully agreed that >> breaking changes should be well communicated first. So splitting the >> discussion in two: >> >> >> 1) License requirements: for now I have chatted with Lova and we propose: >> >> a) Change the logic such that a license is required for newly registered >> plugins >> b) When updates are made to existing plugins that do not include a >> license, the uploader will be shown a warning indicating that in future the >> license will be mandatory >> >> This is already implemented in >> https://github.com/qgis/QGIS-Django/pull/311 and I propose we deploy >> this today / ASAP to address the previously raised issues. >> >> 2) Change management: >> >> Yes I think we can introduce more rigour in the process. >> >> * breaking changes: discuss with the community first, implement, deploy >> in a known time window >> * non-breaking changes: for simple bug fixes, just fix, test and deploy >> as needed >> * non-breaking changes: for features etc. these will be managed on the >> project board here, anyone who wants to be engaged in the process can see >> the planned upcomming work and interact with Lova via the ticket queue. >> https://github.com/orgs/qgis/projects/6 >> * requests to improvements: please file tickets here >> https://github.com/qgis/QGIS-Django/issues >> >> Regarding a staging site, currently we do not run a staging environment, >> developers have local test environments and I am on the fence as to whether >> there is a lot of value in us maintaining a long running staging site. >> >> Regards >> >> Tim >> >> >> >> >> On Fri, Nov 24, 2023 at 8:08 AM Lova Andriarimalala via QGIS-Developer < >> qgis-developer@lists.osgeo.org> wrote: >> >>> Dear Julien, >>> >>> >>> >>> That’s well noted. Thank you. >>> >>> I will add a detailed description in each PR in the future. >>> >>> Regarding the issue of LICENSE file requirements, I totally agree with >>> you. I will also ask Tim if he has suggestions about it. >>> >>> >>> >>> Best regards, >>> >>> Lova >>> >>> >>> >>> — >>> >>> [image: Image] >>> >>> >>> >>> *Lova Andriarimalala* >>> >>> *QGIS Full Stack Developer* >>> >>> Visit http://kartoza.com to find out about open source: >>> >>> * Desktop GIS programming services >>> >>> * Geospatial web development >>> >>> * GIS Training >>> >>> * Consulting Services >>> >>> Office: +261(0)34 09 524 73 <+261340952473> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From: *Julien Moura >>> *Date:
Re: [QGIS-Developer] [Qgis-psc] QGIS grant report: Improve test result handling on QGIS CI
On Mon, Nov 27, 2023 at 8:09 AM Nyall Dawson wrote: > > > > On Mon, 27 Nov 2023, 4:56 pm Alessandro Pasotti, wrote: >> >> Hi Nyall, >> >> good news, thank you for this improvement! >> >> Just a quick question, in the linked PR: >> https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755 >> comment the instructions say: >> >> "The full test report (included comparison of rendered vs expected >> images) can be found under the 'Checks' tab - 'QGIS tests', >> 'Artifacts' section as test-results-5." >> >> But I couldn't find any test-results-5 in the artifacts section, there are >> only: >> >> Artifacts >> build-22.04-qt5.tgz >> build-38-qt6.tgz > > > That's caused by a limitation in GitHub API. We can't retrieve the workflow > run id in an action, so that link will always just point to the most recent > workflow run for the PR. > > And in this case I reverted the change causing a test failure, so the most > recent workflow doesn't have the failure report. > > Hope that makes sense! > Yes, thanks for clarifying. -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [Qgis-psc] QGIS grant report: Improve test result handling on QGIS CI
On Mon, 27 Nov 2023, 4:56 pm Alessandro Pasotti, wrote: > Hi Nyall, > > good news, thank you for this improvement! > > Just a quick question, in the linked PR: > https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755 > comment the instructions say: > > "The full test report (included comparison of rendered vs expected > images) can be found under the 'Checks' tab - 'QGIS tests', > 'Artifacts' section as test-results-5." > > But I couldn't find any test-results-5 in the artifacts section, there are > only: > > Artifacts > build-22.04-qt5.tgz > build-38-qt6.tgz > That's caused by a limitation in GitHub API. We can't retrieve the workflow run id in an action, so that link will always just point to the most recent workflow run for the PR. And in this case I reverted the change causing a test failure, so the most recent workflow doesn't have the failure report. Hope that makes sense! Nyall > > Cheers. > > > On Mon, Nov 27, 2023 at 5:29 AM Nyall Dawson via QGIS-PSC > wrote: > > > > Hi PSC, > > > > I'm happy to announce that this grant is now complete! > > > > While the original proposal was explicitly stated to be a research > project with no guarantees of success, the end result is predominantly a > success (with some limitations!) > > > > You can see the new failure handling in action in this PR: > https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755 > > > > What we have now is that any tests which fail a rendering comparison > will write a descriptive comment to the PR, as shown in the above link. The > comment details which render tests failed, where they are in the code, and > includes some helpful pointers to downloading the full test report and the > QGIS developer documentation. > > > > Originally, I hoped to link directly to the full test report or include > it as an attachment to the comment. Unfortunately this is NOT possible > given the current Github API. There's a bunch of notes I've added to the > initial comment in https://github.com/qgis/QGIS/pull/54906 which link to > the limitations / feature requests on Github's side, so we can monitor the > situation and further improve the reports if/when Github add this > functionality. > > > > As well as the above described improvements on the CI side, I've also > implemented lots of improvements in running the tests locally and how the > render test reports are generated and presented to developers! > > > > Thanks for making this possible! > > > > Nyall > > > > > > > > > > > > ___ > > QGIS-PSC mailing list > > qgis-...@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/qgis-psc > > > > -- > Alessandro Pasotti > QCooperative: www.qcooperative.net > ItOpen: www.itopen.it > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [Qgis-psc] QGIS grant report: Improve test result handling on QGIS CI
On Mon, Nov 27, 2023, at 09:09, Nyall Dawson via QGIS-Developer wrote: > That's caused by a limitation in GitHub API. We can't retrieve the workflow > run id in an action, so that link will always just point to the most recent > workflow run for the PR. Hi Nyall, I'm not sure if that's the one you're missing, and you might be aware of it, but there's a run_id field in the https://docs.github.com/en/actions/learn-github-actions/contexts#github-context. Laurentiu ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] [Qgis-psc] QGIS grant report: Improve test result handling on QGIS CI
Hi Nyall, good news, thank you for this improvement! Just a quick question, in the linked PR: https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755 comment the instructions say: "The full test report (included comparison of rendered vs expected images) can be found under the 'Checks' tab - 'QGIS tests', 'Artifacts' section as test-results-5." But I couldn't find any test-results-5 in the artifacts section, there are only: Artifacts build-22.04-qt5.tgz build-38-qt6.tgz Cheers. On Mon, Nov 27, 2023 at 5:29 AM Nyall Dawson via QGIS-PSC wrote: > > Hi PSC, > > I'm happy to announce that this grant is now complete! > > While the original proposal was explicitly stated to be a research project > with no guarantees of success, the end result is predominantly a success > (with some limitations!) > > You can see the new failure handling in action in this PR: > https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755 > > What we have now is that any tests which fail a rendering comparison will > write a descriptive comment to the PR, as shown in the above link. The > comment details which render tests failed, where they are in the code, and > includes some helpful pointers to downloading the full test report and the > QGIS developer documentation. > > Originally, I hoped to link directly to the full test report or include it as > an attachment to the comment. Unfortunately this is NOT possible given the > current Github API. There's a bunch of notes I've added to the initial > comment in https://github.com/qgis/QGIS/pull/54906 which link to the > limitations / feature requests on Github's side, so we can monitor the > situation and further improve the reports if/when Github add this > functionality. > > As well as the above described improvements on the CI side, I've also > implemented lots of improvements in running the tests locally and how the > render test reports are generated and presented to developers! > > Thanks for making this possible! > > Nyall > > > > > > ___ > QGIS-PSC mailing list > qgis-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/qgis-psc -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Embedded styling in some datatypes
On Thu, 23 Nov 2023 at 20:51, Bo Victor Thomsen via QGIS-Developer < qgis-developer@lists.osgeo.org> wrote: > > Hi list - > > I'm wondering about how to use embedded styling in certain types of file > formats (like MapInfo Tab). I know its possible to read the embedded > styling from a Tab fil and then convert it to a styling object in QGIS. > > However, what about the other direction ? Take a specific QGIS style > from the layer styling of a tab file, and and write the specific style > into the feature, so it will be present if you later open the tab file > in (gasp!) MapIno ? There's an option in the right-click, Export - Save Features As dialog for "Symbology Export". This only shows up for some formats (depending on GDAL library support for that format), of which Mapinfo TAB is one. If you set this to anything other than "No Symbology" then ** IN SOME CASES ** the QGIS symbology will be written as the embedded symbols for the features. The big disclaimer is that the GDAL api for embedding styles, AND the underlying format support is very limited compared with QGIS symbology options. Eg it'll work for embedding colored line symbols, but won't for shapeburst gradient fill polygons with data defined overrides 藍! There's likely many ways we could improve this at both the QGIS and GDAL levels to better handle the full range of symbology options possible in TAB files, and adding more graceful fallbacks from QGIS symbology to the limited symbology options possible in GDAL/TAB. Nyall > > The use case would be organisations that have a mixed environment of > QGIS and MapInfo installations. It would allow QGIS users to create and > update object in a .tab file and save the file. Later this file - if > opened in MapInfo (or QGIS) - would be shown with the correct embedded > styling. > > -- > Med venlig hilsen / Best regards > > Bo Victor Thomsen > > ___ > QGIS-Developer mailing list > QGIS-Developer@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] QGIS grant report: Improve test result handling on QGIS CI
Hi PSC, I'm happy to announce that this grant is now complete! While the original proposal was explicitly stated to be a research project with no guarantees of success, the end result is predominantly a success (with some limitations!) You can see the new failure handling in action in this PR: https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755 What we have now is that any tests which fail a rendering comparison will write a descriptive comment to the PR, as shown in the above link. The comment details which render tests failed, where they are in the code, and includes some helpful pointers to downloading the full test report and the QGIS developer documentation. Originally, I hoped to link directly to the full test report or include it as an attachment to the comment. Unfortunately this is NOT possible given the current Github API. There's a bunch of notes I've added to the initial comment in https://github.com/qgis/QGIS/pull/54906 which link to the limitations / feature requests on Github's side, so we can monitor the situation and further improve the reports if/when Github add this functionality. As well as the above described improvements on the CI side, I've also implemented lots of improvements in running the tests locally and how the render test reports are generated and presented to developers! Thanks for making this possible! Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QGIS Full Stack Web Developer Report
On Mon, 27 Nov 2023 at 00:19, Tim Sutton via QGIS-Developer < qgis-developer@lists.osgeo.org> wrote: > > @Matthias Kuhn and @Julien Moura I fixed the permissions, the board for Lova is public now. Please feel free to add items to the backlog and mark them as priority as needed. I also asked Lova to try to work through all the old issues and fix / close them as appropriate so we can try to get the number of tickets down to a small number. Tim/Lova, thanks for your outstanding efforts and commitment here! It's really exciting to see all the love and attention that the web and plugin infrastructure is getting as a result! Nyall > > Regards > > Tim > > On Sat, Nov 25, 2023 at 8:37 AM Matthias Kuhn wrote: >> >> Hi, >> >> Thank you very much Lova for working on this application, it's a very important piece in the QGIS ecosystem! >> >> For the current discussion, I would also suggest making the license recommended for now and only start enforcing it on a schedule. And I was wondering if a license field in the metadata.txt would be even better (cmp. https://python-poetry.org/docs/pyproject/#license), that would be easier to show on the plugin page? >> >> Is there any way to help prioritizing the issues? I have some wishes that I would love to see land on the backlog >> >> Kind regards and thanks again for all the good work on this ! >> Matthias >> >> On Fri, Nov 24, 2023 at 11:49 AM Julien Moura via QGIS-Developer < qgis-developer@lists.osgeo.org> wrote: >>> >>> Dear Tim, >>> >>> Thanks for taking in account my thoughts and make the discussion possible. >>> >>> Regarding the second about change management, I totally agree and feel really thankful that you make those changes. I can imagine the work it represents for your teams maintaining a project like this one. So thank you again. >>> >>> Regarding your proposal about the license requirements, why not starting apply the change management to this? It's a breaking change, even for new plugins, right? So, it should be lowered to a non blocking warning, documented in PyQGIS cookbook and then deployed as a blocking error in a known time windows. This way, in the meanwhile, the plugins ecosystem can adapt to new rules (new versions for tools like minimal plugin, qgis-plugin-ci, plugin builder...) and make this change more acceptable and frictionless. >>> >>> Moreover, the rationale behind the required license file into the plugin archive is still not solved. >>> >>> If you want, I can make a PR to change the warning but I'm pretty sure that's not the question here. >>> >>> https://github.com/orgs/qgis/projects/6 >>> >>> Just to let you know this hyperlink leads to a 404 (probably a Github rights access setting somewhere). >>> >>> Regards >>> >>> On 24/11/2023 10:50, Tim Sutton wrote: >>> >>> Dear Julien >>> >>> Thank you so much for your engagement and suggestions. Fully agreed that breaking changes should be well communicated first. So splitting the discussion in two: >>> >>> >>> 1) License requirements: for now I have chatted with Lova and we propose: >>> >>> a) Change the logic such that a license is required for newly registered plugins >>> b) When updates are made to existing plugins that do not include a license, the uploader will be shown a warning indicating that in future the license will be mandatory >>> >>> This is already implemented in https://github.com/qgis/QGIS-Django/pull/311 and I propose we deploy this today / ASAP to address the previously raised issues. >>> >>> 2) Change management: >>> >>> Yes I think we can introduce more rigour in the process. >>> >>> * breaking changes: discuss with the community first, implement, deploy in a known time window >>> * non-breaking changes: for simple bug fixes, just fix, test and deploy as needed >>> * non-breaking changes: for features etc. these will be managed on the project board here, anyone who wants to be engaged in the process can see the planned upcomming work and interact with Lova via the ticket queue. https://github.com/orgs/qgis/projects/6 >>> * requests to improvements: please file tickets here https://github.com/qgis/QGIS-Django/issues >>> >>> Regarding a staging site, currently we do not run a staging environment, developers have local test environments and I am on the fence as to whether there is a lot of value in us maintaining a long running staging site. >>> >>> Regards >>> >>> Tim >>> >>> >>> >>> >>> On Fri, Nov 24, 2023 at 8:08 AM Lova Andriarimalala via QGIS-Developer < qgis-developer@lists.osgeo.org> wrote: Dear Julien, That’s well noted. Thank you. I will add a detailed description in each PR in the future. Regarding the issue of LICENSE file requirements, I totally agree with you. I will also ask Tim if he has suggestions about it. Best regards, Lova — Lova Andriarimalala QGIS Full Stack Developer Visit http://kartoza.com to find out about
Re: [QGIS-Developer] Embedded styling in some datatypes
On Fri, 24 Nov 2023 at 17:28, Régis Haubourg via QGIS-Developer < qgis-developer@lists.osgeo.org> wrote: > > Hi Bo, > Regarding MapInfo, I know the french ministry of environment has tried something like this years ago. > It was an attempt to handle the transition period between M and Q. > > But honestly the style specifications of each proprietary format are really hard to interoperate. This leads to partially compatible styles, and data loss. > > SLD was a promise to have a common standard but I think all the developers that tried to implement conversion utilities have been having hard days. Maybe except for Slyr by Nyall. > Data can be shared across systems. But styles can be shared with very limited support and this somewhat negates the work of talented cartographers. FWIW, symbology can be converted from ArcMap -> QGIS almost completely losslessly. And from ArcGIS Pro -> QGIS at ≊95% losslessly. And then from QGIS -> ArcGIS Pro at ≲ 50%. We've well overtaken Arc in what's possible in map symbology in recent years. 拾 Nyall > > > > Le jeu. 23 nov. 2023, 11:51, Bo Victor Thomsen via QGIS-Developer < qgis-developer@lists.osgeo.org> a écrit : >> >> Hi list - >> >> I'm wondering about how to use embedded styling in certain types of file >> formats (like MapInfo Tab). I know its possible to read the embedded >> styling from a Tab fil and then convert it to a styling object in QGIS. >> >> However, what about the other direction ? Take a specific QGIS style >> from the layer styling of a tab file, and and write the specific style >> into the feature, so it will be present if you later open the tab file >> in (gasp!) MapIno ? >> >> The use case would be organisations that have a mixed environment of >> QGIS and MapInfo installations. It would allow QGIS users to create and >> update object in a .tab file and save the file. Later this file - if >> opened in MapInfo (or QGIS) - would be shown with the correct embedded >> styling. >> >> -- >> Med venlig hilsen / Best regards >> >> Bo Victor Thomsen >> >> ___ >> QGIS-Developer mailing list >> QGIS-Developer@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@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@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
