Re: [QGIS-Developer] Official PSC call on pull request policies

[Julien Cabieces via QGIS-Developer]

Hi all,

> [[PGP Signed Part:Undecided]]
> Thanks Nyall for raising this thread!
>
> On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:
>
>> Policy #1: https://github.com/qgis/QGIS/pull/56062
>> 
>> In short, Sandro proposes that the pull request queue be an open queue
>> of ALL work happening everywhere, in any state of completeness. Pull
>> requests are permitted for semi-complete work, and for long-term
>> (including multi-year) projects which are not yet ready for review or
>> merge. The justification here is that having this work open in the
>> queue makes it widely visible and so that other developers are aware
>> of ongoing work across the community.
>
> I would add that allowing long-term PRs also serves the purpose of making
> it easy for contributors to check the state of their work against CI as
> running tests locally is so hard that I dubt anyone is doing that.
>

It's completely possible to trigger the GH CI without creating a PR
directly from your fork, you
just have to:
- create a branch
- add your branch name here [0] in a special commit that you will remove
once your work is ready to create a PR
- Push, the CI result appear in https://github.com//QGIS/actions

Prior to that you will have to "Allow all actions and reusable workflows"
from https://github.com//QGIS/settings/actions

It's pretty straightforward, and I use it everytime I want to check on CI.

Regards,
Julien

[0] 
https://github.com/qgis/QGIS/blob/release-3_28/.github/workflows/run-tests.yml#L6

>> Policy #2: https://github.com/qgis/QGIS/pull/56523
>
> [...]
>
>> When the queue includes work which is not ready for review, then it
>> becomes very tricky to work out the actual status of pull requests and
>> which ones should be focused on during review time.
>
> I think this is a limitation of the software used to get the list
> of pull requests needing focus, and should be threated as such.
> If github makes it hard to filter on "PR state" we could use a label
> to do that.
>
> --strk;
>
> [[End of PGP Signed Part]]
> ___
> 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


-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabie...@oslandia.com
___
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 Plugins Mechanism

[Emma Hain via QGIS-Developer]

Hi Olga
These plugins are maintained by each of the plugin's developers and not by
the project. It is up to them to ensure any dependency conflicts are
managed. Therefore, if you find any issues, you should contact the plugin
developers and put in bugs on their GitHub pages. A link to contact them is
in the plugin manager in their Plugin information section. Everything is
outlined here


For those plugins that are no longer maintained, this presents an
opportunity for the community to jump in and assist if they are passionate
about that plugin.

Thanks
Em

On Tue, 27 Feb 2024 at 21:51, Olga Hovhannisyan via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi!
> I want to ask a question related to plugins that are already integrated in
> QGIS. Aren't there any dependency conflicts, how you  solve those conflicts
> and how that plugins interact with QGIS Desktop internally, by using
> requests or something similar?
> ___
> 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
>


-- 
Emma Hain — Product Manager/Senior GIS Analyst
e...@north-road.com
[image: https://north-road.com]
*North Road*
Cartography • Development • Spatial Analysis
--
*north-road.com* 



___
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] Official PSC call on pull request policies

[Marco Bernasocchi via QGIS-Developer]

Thanks for the clarification Nyall, as Andreas wrote we'll discuss it next
Tuesday at PSC and will get back to you short after.

Cheers Marco

On Wed, 28 Feb 2024, 00:07 Nyall Dawson,  wrote:

>
>
> On Wed, 28 Feb 2024 at 08:49, Marco Bernasocchi  wrote:
>
>> Thanks Nyall, thanks Sandro,
>>
>> Just a quick question, is the
>>  -is:draft
>> Filter an option at all? I guess it does not reduce the n/r by default
>> but could help?
>>
>> https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft
>>
>
> That hides them, yes. But the bigger question remains as to what value
> having unfinished work in the queue has in the first place. In my opinion
> if it's not ready for review and merge, it's not actually a "pull REQUEST"
> and just doesn't belong there. In my proposal there's already mention that
> short term pull requests can be permitted for the express purpose of
> performing a CI test run, so after that why is there a need to allow
> unfinished work to remain in the queue?
>
> If the need is for others to see and be exposed to unfinished work, then
> let's look at an extreme example: I have some 100's of branches of work in
> an unfinished state on my QGIS fork, from proof of concept experiments
> through to things which I just don't think work well enough to be
> submitted. Should all of those draft/wip branches be pull requests in the
> QGIS repo? 🤣 If the justification for allowing draft/wip requests is that
> others can see what's being/been done, then I guess the same argument would
> apply to all of this.
>
> Nyall
>
>
>>
>>
>> Cheers Marco
>>
>>
>> On Tue, 27 Feb 2024, 23:09 Sandro Santilli via QGIS-PSC, <
>> qgis-...@lists.osgeo.org> wrote:
>>
>>> Thanks Nyall for raising this thread!
>>>
>>> On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:
>>>
>>> > Policy #1: https://github.com/qgis/QGIS/pull/56062
>>> >
>>> > In short, Sandro proposes that the pull request queue be an open queue
>>> > of ALL work happening everywhere, in any state of completeness. Pull
>>> > requests are permitted for semi-complete work, and for long-term
>>> > (including multi-year) projects which are not yet ready for review or
>>> > merge. The justification here is that having this work open in the
>>> > queue makes it widely visible and so that other developers are aware
>>> > of ongoing work across the community.
>>>
>>> I would add that allowing long-term PRs also serves the purpose of making
>>> it easy for contributors to check the state of their work against CI as
>>> running tests locally is so hard that I dubt anyone is doing that.
>>>
>>> > Policy #2: https://github.com/qgis/QGIS/pull/56523
>>>
>>> [...]
>>>
>>> > When the queue includes work which is not ready for review, then it
>>> > becomes very tricky to work out the actual status of pull requests and
>>> > which ones should be focused on during review time.
>>>
>>> I think this is a limitation of the software used to get the list
>>> of pull requests needing focus, and should be threated as such.
>>> If github makes it hard to filter on "PR state" we could use a label
>>> to do that.
>>>
>>> --strk;
>>> ___
>>> QGIS-PSC mailing list
>>> qgis-...@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>
___
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] Official PSC call on pull request policies

[Nyall Dawson via QGIS-Developer]

On Wed, 28 Feb 2024 at 08:49, Marco Bernasocchi  wrote:

> Thanks Nyall, thanks Sandro,
>
> Just a quick question, is the
>  -is:draft
> Filter an option at all? I guess it does not reduce the n/r by default but
> could help?
>
> https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft
>

That hides them, yes. But the bigger question remains as to what value
having unfinished work in the queue has in the first place. In my opinion
if it's not ready for review and merge, it's not actually a "pull REQUEST"
and just doesn't belong there. In my proposal there's already mention that
short term pull requests can be permitted for the express purpose of
performing a CI test run, so after that why is there a need to allow
unfinished work to remain in the queue?

If the need is for others to see and be exposed to unfinished work, then
let's look at an extreme example: I have some 100's of branches of work in
an unfinished state on my QGIS fork, from proof of concept experiments
through to things which I just don't think work well enough to be
submitted. Should all of those draft/wip branches be pull requests in the
QGIS repo? 🤣 If the justification for allowing draft/wip requests is that
others can see what's being/been done, then I guess the same argument would
apply to all of this.

Nyall


>
>
> Cheers Marco
>
>
> On Tue, 27 Feb 2024, 23:09 Sandro Santilli via QGIS-PSC, <
> qgis-...@lists.osgeo.org> wrote:
>
>> Thanks Nyall for raising this thread!
>>
>> On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:
>>
>> > Policy #1: https://github.com/qgis/QGIS/pull/56062
>> >
>> > In short, Sandro proposes that the pull request queue be an open queue
>> > of ALL work happening everywhere, in any state of completeness. Pull
>> > requests are permitted for semi-complete work, and for long-term
>> > (including multi-year) projects which are not yet ready for review or
>> > merge. The justification here is that having this work open in the
>> > queue makes it widely visible and so that other developers are aware
>> > of ongoing work across the community.
>>
>> I would add that allowing long-term PRs also serves the purpose of making
>> it easy for contributors to check the state of their work against CI as
>> running tests locally is so hard that I dubt anyone is doing that.
>>
>> > Policy #2: https://github.com/qgis/QGIS/pull/56523
>>
>> [...]
>>
>> > When the queue includes work which is not ready for review, then it
>> > becomes very tricky to work out the actual status of pull requests and
>> > which ones should be focused on during review time.
>>
>> I think this is a limitation of the software used to get the list
>> of pull requests needing focus, and should be threated as such.
>> If github makes it hard to filter on "PR state" we could use a label
>> to do that.
>>
>> --strk;
>> ___
>> QGIS-PSC mailing list
>> qgis-...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>
___
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] Official PSC call on pull request policies

[Marco Bernasocchi via QGIS-Developer]

Thanks Nyall, thanks Sandro,

Just a quick question, is the
 -is:draft
Filter an option at all? I guess it does not reduce the n/r by default but
could help?

https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft

Cheers Marco


On Tue, 27 Feb 2024, 23:09 Sandro Santilli via QGIS-PSC, <
qgis-...@lists.osgeo.org> wrote:

> Thanks Nyall for raising this thread!
>
> On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:
>
> > Policy #1: https://github.com/qgis/QGIS/pull/56062
> >
> > In short, Sandro proposes that the pull request queue be an open queue
> > of ALL work happening everywhere, in any state of completeness. Pull
> > requests are permitted for semi-complete work, and for long-term
> > (including multi-year) projects which are not yet ready for review or
> > merge. The justification here is that having this work open in the
> > queue makes it widely visible and so that other developers are aware
> > of ongoing work across the community.
>
> I would add that allowing long-term PRs also serves the purpose of making
> it easy for contributors to check the state of their work against CI as
> running tests locally is so hard that I dubt anyone is doing that.
>
> > Policy #2: https://github.com/qgis/QGIS/pull/56523
>
> [...]
>
> > When the queue includes work which is not ready for review, then it
> > becomes very tricky to work out the actual status of pull requests and
> > which ones should be focused on during review time.
>
> I think this is a limitation of the software used to get the list
> of pull requests needing focus, and should be threated as such.
> If github makes it hard to filter on "PR state" we could use a label
> to do that.
>
> --strk;
> ___
> QGIS-PSC mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
___
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] Finishing Visual Changelog for export to site

[Nyall Dawson via QGIS-Developer]

On Wed, 28 Feb 2024 at 02:55, Richard Duivenvoorde 
wrote:

> On 2/27/24 8:17 AM, Nyall Dawson wrote:
> > Hmm, would it be possible to do the export again? I noticed a few extra
> entries were added overnight too, and these aren't present on the site.
> (Plus a few wording improvements I made this morning too)..
>
> Yep, no problem. Please let me know
>

This should be good to re-export, I've deleted all the junk backport
entries from 3.36 on changelog.qgis now.

Thanks!
Nyall


>
> Richard
>
___
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] Official PSC call on pull request policies

[Sandro Santilli via QGIS-Developer]

Thanks Nyall for raising this thread!

On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:

> Policy #1: https://github.com/qgis/QGIS/pull/56062
> 
> In short, Sandro proposes that the pull request queue be an open queue
> of ALL work happening everywhere, in any state of completeness. Pull
> requests are permitted for semi-complete work, and for long-term
> (including multi-year) projects which are not yet ready for review or
> merge. The justification here is that having this work open in the
> queue makes it widely visible and so that other developers are aware
> of ongoing work across the community.

I would add that allowing long-term PRs also serves the purpose of making
it easy for contributors to check the state of their work against CI as
running tests locally is so hard that I dubt anyone is doing that.

> Policy #2: https://github.com/qgis/QGIS/pull/56523

[...]

> When the queue includes work which is not ready for review, then it
> becomes very tricky to work out the actual status of pull requests and
> which ones should be focused on during review time.

I think this is a limitation of the software used to get the list
of pull requests needing focus, and should be threated as such.
If github makes it hard to filter on "PR state" we could use a label
to do that.

--strk;


signature.asc
Description: PGP signature
___
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] Finishing Visual Changelog for export to site

[Richard Duivenvoorde via QGIS-Developer]

On 2/27/24 8:17 AM, Nyall Dawson wrote:

Hmm, would it be possible to do the export again? I noticed a few extra entries 
were added overnight too, and these aren't present on the site. (Plus a few 
wording improvements I made this morning too)..


Yep, no problem. Please let me know

Richard
___
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 3.34.4 LTR ?

[Régis Haubourg via QGIS-Developer]

We are in the process of building a new website, I think you're right we
should simplify the roadmap page and communicate more on the binary release
date than on source code in our phrasing.

As for external communication, indeed many posts are launched individually
when source code is branched. I hope this is not a race to be the first to
communicate and gather traffic.  I'll raise the issue to the PSC.
Thanks a lot!

Le mar. 27 févr. 2024 à 10:20, Nick Bearman via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi Régis, Luca, list,
>
> I think some of the confusion might be over the term of "Release". I read
> this as release of the binaries, i.e. something we can download and install
> from the QGIS website as a user. From what you said Luca, it seems you view
> "Release" as release of the source code before packaging into binaries. Do
> I understand this correctly?
>
> I've always found the Road Map page slightly confusing. Is there space on
> the website for a "simpler" explanation of this process somewhere? Yes, I
> am happy to have a go at writing a first draft!
>
> Also - I think the release process is complicated by OSGeo4W Network
> installer. I used this to install both LTR and current versions of QGIS
> yesterday (26th Feb) and got 3.36.0 (branded as Release Candidate) and
> 3.34.3 (branded at LTR) which I think is a bit ahead of the game.
>
> I think Kurt's post on LinkedIn (
> https://www.linkedin.com/feed/update/urn:li:activity:7167793362815717376/)
> may have also made some people this 3.36 is available when it is not.
>
> Hope this is useful!
>
> Best wishes,
> Nick.
> On 27/02/2024 08:58, Régis Haubourg via QGIS-Developer wrote:
>
> Hi Luca, as always, there is a delay between source code releases events,
> and the packaging can only start, as per
> https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release
>
> QGIS website indicates that packaging is on its way.
>
> Official communication including the changelog and binaries are on their
> way.
>
> How do you think we could improve our communication to clarify this ? You
> are not the only one asking, so I think we still have work to improve.
>
> Le mar. 27 févr. 2024 à 09:40, Luca Manganelli via QGIS-Developer <
> qgis-developer@lists.osgeo.org> a écrit :
>
>> Good morning,
>>
>> according to the QGIS roadmap, I see that the 3.34 LTR release is on 23th
>> february, but on the site I see that the latest LTR is still 3.28
>>
>>
>>
>>
>> --
>>
>> Comune di Trento
>>
>> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>>
>> tel. +39 0461.884111 | www.comune.trento.it
>> --
>> *Informativa privacy*
>> I dati contenuti nella presente e-mail sono raccolti e trattati nel
>> rispetto del Regolamento UE 2016/679 (GDPR). Gli interessati possono
>> rivolgersi in qualsiasi momento al Titolare del trattamento, Comune di
>> Trento, per esercitare i diritti previsti dal GDPR. I dati di contatto del
>> RPD e del Titolare oltre che l’informativa completa sono disponibili al
>> link https://www.comune.trento.it/ sotto la voce “Privacy”.
>> Si precisa inoltre che le informazioni contenute nel presente messaggio,
>> e negli eventuali allegati, sono riservate e per uso esclusivo del
>> destinatario. In caso di ricezione dello stesso per errore, siete pregati
>> di informare immediatamente il mittente e di cancellarlo dal vostro
>> archivio, in conformità con quanto disposto dall'art. 17 del GDPR. Ogni
>> trattamento della presente mail che non sia quello del destinatario reale è
>> inteso come non autorizzato dal mittente. Inoltre, in quanto non
>> destinatari reali, Vi informiamo che il mittente si oppone alla copia, la
>> diffusione e la rivelazione anche parziale dei dati in esso contenuti alle
>> persone non autorizzate dal medesimo, in virtù di quanto disposto dall'art.
>> 21 del GDPR.
>> ___
>> 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 listqgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Nick Bearman
> +44 (0) 7717745715n...@geospatialtrainingsolutions.co.uk
>
> Please let me know if I can make any adjustments related to disability or 
> neurodivergence to improve how we interact.
>
> Due to my own life/work balance, you may get emails from me outside of normal 
> working hours. Please do not feel any pressure to respond outside of your own 
> working pattern.
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsu

[QGIS-Developer] How QGIS handles on-the-fly projection?

[Ionut Ungurianu via QGIS-Developer]

Hi!

I’m looking to understand  in a more advanced way how QGIS handles on-the-fly 
projection.
In my case I set the project crs in epsg:3857 and I have a raster layer in 
epsg:4326. In this case what is happening with the layer?

I know that it’s based on PROJ, but I’m wondering what is actually happening in 
the back-end, what is happening in the map canvas, how is the layer render, is 
being resampled every time you pan the map or do zoom in/out ...

So, if someone can help with a detailed explanation, I would really appreciate 
it.

Thanks in advance!

All the best!
Ionut
___
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 Plugins Mechanism

[Olga Hovhannisyan via QGIS-Developer]

Hi!
I want to ask a question related to plugins that are already integrated in
QGIS. Aren't there any dependency conflicts, how you  solve those conflicts
and how that plugins interact with QGIS Desktop internally, by using
requests or something similar?
___
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] Access to shapeDigitizeToolBar menu's text

[Jacky Volpes via QGIS-Developer]

Hi Luke,

As you can see on the printed text, objects are QWigetAction, not QAction.
This is because you get each category of the tool bar, where then each 
one contains one or more digitizing QActions.



Here is a snippet that can help you explore the tool bar:


sdtb = iface.shapeDigitizeToolBar()
for i, action_widget_item in enumerate(sdtb.actions()):
    print(f"{i}: {action_widget_item.defaultWidget().text()}")
    for j, action_item in 
enumerate(action_widget_item.defaultWidget().menu().actions()):

    print (f"\t{j}: {action_item.data()}")  # id like
    print (f"\t\ttranslated text: {action_item.text()}")


Regards,

Jacky Volpes

Ingénieur SIG - Oslandia


Le 27/02/2024 à 04:10, Catania, Luke A ERDC-RDE-GRL-VA CIV via 
QGIS-Developer a écrit :


Trying to get access to the button menus in shapeDigitizeToolBar.

from qgis.utils import iface

from PyQt5.QtWidgets import QWidgetAction

sdtb = iface.shapeDigitizeToolBar()

i=0

for action_item in sdtb.actions():

    i=i+1

    print (f"{i}: {action_item}")

This prints:

1: 

2: 

3: 

4: 

5: 

I want to access each button and the menus of the button so I can 
disable certain tools.  I need to get the text associated with the 
tools so I can key on that.


I can’t figure out how to get to them from QWidgetAction. I called all 
the methods on QAction that returns a string: data, iconText, 
statusTip, whatsThis and they all return empty strings.  So how are 
these menus labeled.


Thanks,

Luke


___
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

Re: [QGIS-Developer] Qgis 3.34.4 LTR ?

[Jürgen E . Fischer via QGIS-Developer]

Hi,

On Tue, 27. Feb 2024 at 09:39:23 +0100, Luca Manganelli via QGIS-Developer 
wrote:
> Good morning,
> 
> according to the QGIS roadmap, I see that the 3.34 LTR release is on 23th
> february, but on the site I see that the latest LTR is still 3.28

Quoting the website (right above the roadmap):

> Release

> On major and minor release dates, the release branch is created and the 
> release
> is tagged and tar balls are prepared. Point releases are just tagged and tar
> balls are created.

> The packagers are notified that packaging can begin.

> Once some packages are available the release can be announced and the website
> is updated accordingly.

OSGeo4W packages, MSIs and Mac packages are already available, but the
debian/ubuntu packages are still building, while the MSIs are being tested.
Once that's done the website will be updated.

But that's nothing new - most of that happens every month.


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC


signature.asc
Description: PGP signature
___
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 3.34.4 LTR ?

[Nick Bearman via QGIS-Developer]

Hi Régis, Luca, list,

I think some of the confusion might be over the term of "Release". I 
read this as release of the binaries, i.e. something we can download and 
install from the QGIS website as a user. From what you said Luca, it 
seems you view "Release" as release of the source code before packaging 
into binaries. Do I understand this correctly?


I've always found the Road Map page slightly confusing. Is there space 
on the website for a "simpler" explanation of this process somewhere? 
Yes, I am happy to have a go at writing a first draft!


Also - I think the release process is complicated by OSGeo4W Network 
installer. I used this to install both LTR and current versions of QGIS 
yesterday (26th Feb) and got 3.36.0 (branded as Release Candidate) and 
3.34.3 (branded at LTR) which I think is a bit ahead of the game.


I think Kurt's post on LinkedIn 
(https://www.linkedin.com/feed/update/urn:li:activity:7167793362815717376/) 
may have also made some people this 3.36 is available when it is not.


Hope this is useful!

Best wishes,
Nick.

On 27/02/2024 08:58, Régis Haubourg via QGIS-Developer wrote:
Hi Luca, as always, there is a delay between source code releases 
events, and the packaging can only start, as per 
https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release


QGIS website indicates that packaging is on its way.

Official communication including the changelog and binaries are on 
their way.


How do you think we could improve our communication to clarify this ? 
You are not the only one asking, so I think we still have work to 
improve.


Le mar. 27 févr. 2024 à 09:40, Luca Manganelli via QGIS-Developer 
 a écrit :


Good morning,

according to the QGIS roadmap, I see that the 3.34 LTR release is
on 23th february, but on the site I see that the latest LTR is
still 3.28






Comune di Trento

via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221

tel. +39 0461.884111 | www.comune.trento.it



*Informativa privacy*
I dati contenuti nella presente e-mail sono raccolti e trattati
nel rispetto del Regolamento UE 2016/679 (GDPR). Gli interessati
possono rivolgersi in qualsiasi momento al Titolare del
trattamento, Comune di Trento, per esercitare i diritti previsti
dal GDPR. I dati di contatto del RPD e del Titolare oltre che
l’informativa completa sono disponibili al link
https://www.comune.trento.it/ sotto la voce “Privacy”.
Si precisa inoltre che le informazioni contenute nel presente
messaggio, e negli eventuali allegati, sono riservate e per uso
esclusivo del destinatario. In caso di ricezione dello stesso per
errore, siete pregati di informare immediatamente il mittente e di
cancellarlo dal vostro archivio, in conformità con quanto disposto
dall'art. 17 del GDPR. Ogni trattamento della presente mail che
non sia quello del destinatario reale è inteso come non
autorizzato dal mittente. Inoltre, in quanto non destinatari
reali, Vi informiamo che il mittente si oppone alla copia, la
diffusione e la rivelazione anche parziale dei dati in esso
contenuti alle persone non autorizzate dal medesimo, in virtù di
quanto disposto dall'art. 21 del GDPR.
___
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


--
Nick Bearman
+44 (0) 7717745715
n...@geospatialtrainingsolutions.co.uk

Please let me know if I can make any adjustments related to disability or 
neurodivergence to improve how we interact.

Due to my own life/work balance, you may get emails from me outside of normal 
working hours. Please do not feel any pressure to respond outside of your own 
working pattern.
___
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 3.34.4 LTR ?

[Luca Manganelli via QGIS-Developer]

Thank you for your response. Yes, I suggest you to indicate that the date
are only suggested.

See this example for LibreOffice:

https://wiki.documentfoundation.org/ReleasePlan

there's a column for the Freeze and one for Publishing, with a range of
dates and not a fixed day.



Il giorno mar 27 feb 2024 alle ore 09:59 Régis Haubourg <
regis.haubo...@gmail.com> ha scritto:

> Hi Luca, as always, there is a delay between source code releases events,
> and the packaging can only start, as per
> https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release
>
> QGIS website indicates that packaging is on its way.
>
> Official communication including the changelog and binaries are on their
> way.
>
> How do you think we could improve our communication to clarify this ? You
> are not the only one asking, so I think we still have work to improve.
>
> Le mar. 27 févr. 2024 à 09:40, Luca Manganelli via QGIS-Developer <
> qgis-developer@lists.osgeo.org> a écrit :
>
>> Good morning,
>>
>> according to the QGIS roadmap, I see that the 3.34 LTR release is on 23th
>> february, but on the site I see that the latest LTR is still 3.28
>>
>>
>>
>>
>> --
>>
>> Comune di Trento
>>
>> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>>
>> tel. +39 0461.884111 | www.comune.trento.it
>> --
>> *Informativa privacy*
>> I dati contenuti nella presente e-mail sono raccolti e trattati nel
>> rispetto del Regolamento UE 2016/679 (GDPR). Gli interessati possono
>> rivolgersi in qualsiasi momento al Titolare del trattamento, Comune di
>> Trento, per esercitare i diritti previsti dal GDPR. I dati di contatto del
>> RPD e del Titolare oltre che l’informativa completa sono disponibili al
>> link https://www.comune.trento.it/ sotto la voce “Privacy”.
>> Si precisa inoltre che le informazioni contenute nel presente messaggio,
>> e negli eventuali allegati, sono riservate e per uso esclusivo del
>> destinatario. In caso di ricezione dello stesso per errore, siete pregati
>> di informare immediatamente il mittente e di cancellarlo dal vostro
>> archivio, in conformità con quanto disposto dall'art. 17 del GDPR. Ogni
>> trattamento della presente mail che non sia quello del destinatario reale è
>> inteso come non autorizzato dal mittente. Inoltre, in quanto non
>> destinatari reali, Vi informiamo che il mittente si oppone alla copia, la
>> diffusione e la rivelazione anche parziale dei dati in esso contenuti alle
>> persone non autorizzate dal medesimo, in virtù di quanto disposto dall'art.
>> 21 del GDPR.
>> ___
>> 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
>>
>

-- 
Luca Manganelli
Assistente informatico
Servizio Innovazione e Sistemi digitali
Via Ezio Maccani 148
38121 Trento (TN)

-- 





Comune di Trento 

via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 
00355870221

tel. +39 0461.884111 | www.comune.trento.it 
 
*Informativa privacy*
I dati contenuti nella 
presente e-mail sono raccolti e trattati nel rispetto del Regolamento UE 
2016/679 (GDPR). Gli interessati possono rivolgersi in qualsiasi momento al 
Titolare del trattamento, Comune di Trento, per esercitare i diritti 
previsti dal GDPR. I dati di contatto del RPD e del Titolare oltre che 
l’informativa completa sono disponibili al link 
https://www.comune.trento.it/  sotto la voce 
“Privacy”.
Si precisa inoltre che le informazioni contenute nel presente 
messaggio, e negli eventuali allegati, sono riservate e per uso esclusivo 
del destinatario. In caso di ricezione dello stesso per errore, siete 
pregati di informare immediatamente il mittente e di cancellarlo dal vostro 
archivio, in conformità con quanto disposto dall'art. 17 del GDPR. Ogni 
trattamento della presente mail che non sia quello del destinatario reale è 
inteso come non autorizzato dal mittente. Inoltre, in quanto non 
destinatari reali, Vi informiamo che il mittente si oppone alla copia, la 
diffusione e la rivelazione anche parziale dei dati in esso contenuti alle 
persone non autorizzate dal medesimo, in virtù di quanto disposto dall'art. 
21 del GDPR.

___
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] Problems with text when exporting to SVG from composer

[Pierson Julie via QGIS-Developer]

Hi all,

Some months ago there was a discussion 
 
on the french qgis user group about problems with svg export in QGIS. 
This is a follow-up to this discussion but centered on text, because it 
seemed better to start with a more "focused" problem :-) For a bit of 
context my colleague Nelly Martin and myself would like to help improve 
QGIS export to SVG to help other colleagues (and ourselves !) switch to 
QGIS. We're aware that QGIS has great possibilities to make maps, but 
for a lot of people editing GIS output in vector graphic editors 
software like Adobe Illustrator, Affinity Designer, or Inkscape is part 
of their workflow.


So this is an attempt to group multiple issues with text and SVG export. 
Maybe this can help to see if these multiple bugs have the same source ?


1. *Text gets exported as separated lines or separated letters :* when 
exporting multi-line text, each line gets exported as a distinct text 
element. When exporting curved label, each letter gets exported as a 
distinct element as well. This is documented in issue 24639 
. There is also an older 
issue documenting an inverse problem when importing into QGIS a SVG with 
multi-line text created in Inkscape : issue 11856 
.


2. *Wrong font size :* when setting a font size of 10pt in QGIS for some 
text and exporting to SVG, and opening SVG in Inkscape, Affinity 
Designer,  or Adobe Illustrator, font size is 10.07747412 pt. This is 
documented in issue 49761 .


3. *Wrong font :* exported SVG do not always use correct fonts, simple 
fonts are ok but more complicated one are not. This is documented in 
issue 47017 .


4. *Wrong character :* minus character gets exported as a dash, this is 
documented in issue 4 . 
Perhaps other characters get exported wrongly as well ?


As I understand it, these bugs are not QGIS-related but stem from Qt. In 
the initial discussion in the french list, Régis Haubourg and Julien 
Cabieces mentioned that KDAB could be a good interlocutor for Qt 
developments (thanks again Régis and Julien for your answers !).


Would this problem be eligible for a QGIS grant, even if this is not a 
QGIS development ? Or do you have any idea how to have a go at this ? We 
haven't found any funding source for now, but we keep looking ! In the 
meantime having input from the QGIS community on this would be valuable.


Thanks a lot for your input ! Have a nice day,

Julie & Nelly.

--
Géomaticienne
UMR 6554 LETG
tel 02 98 49 86 81
Institut Universitaire Européen de la Mer
29280 Plouzané
https://letg.cnrs.fr/
___
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 3.34.4 LTR ?

[Régis Haubourg via QGIS-Developer]

Hi Luca, as always, there is a delay between source code releases events,
and the packaging can only start, as per
https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release

QGIS website indicates that packaging is on its way.

Official communication including the changelog and binaries are on their
way.

How do you think we could improve our communication to clarify this ? You
are not the only one asking, so I think we still have work to improve.

Le mar. 27 févr. 2024 à 09:40, Luca Manganelli via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Good morning,
>
> according to the QGIS roadmap, I see that the 3.34 LTR release is on 23th
> february, but on the site I see that the latest LTR is still 3.28
>
>
>
>
> --
>
> Comune di Trento
>
> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>
> tel. +39 0461.884111 | www.comune.trento.it
> --
> *Informativa privacy*
> I dati contenuti nella presente e-mail sono raccolti e trattati nel
> rispetto del Regolamento UE 2016/679 (GDPR). Gli interessati possono
> rivolgersi in qualsiasi momento al Titolare del trattamento, Comune di
> Trento, per esercitare i diritti previsti dal GDPR. I dati di contatto del
> RPD e del Titolare oltre che l’informativa completa sono disponibili al
> link https://www.comune.trento.it/ sotto la voce “Privacy”.
> Si precisa inoltre che le informazioni contenute nel presente messaggio, e
> negli eventuali allegati, sono riservate e per uso esclusivo del
> destinatario. In caso di ricezione dello stesso per errore, siete pregati
> di informare immediatamente il mittente e di cancellarlo dal vostro
> archivio, in conformità con quanto disposto dall'art. 17 del GDPR. Ogni
> trattamento della presente mail che non sia quello del destinatario reale è
> inteso come non autorizzato dal mittente. Inoltre, in quanto non
> destinatari reali, Vi informiamo che il mittente si oppone alla copia, la
> diffusione e la rivelazione anche parziale dei dati in esso contenuti alle
> persone non autorizzate dal medesimo, in virtù di quanto disposto dall'art.
> 21 del GDPR.
> ___
> 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 3.34.4 LTR ?

[Luca Manganelli via QGIS-Developer]

Good morning,

according to the QGIS roadmap, I see that the 3.34 LTR release is on 23th
february, but on the site I see that the latest LTR is still 3.28

-- 





Comune di Trento 

via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 
00355870221

tel. +39 0461.884111 | www.comune.trento.it 
 
*Informativa privacy*
I dati contenuti nella 
presente e-mail sono raccolti e trattati nel rispetto del Regolamento UE 
2016/679 (GDPR). Gli interessati possono rivolgersi in qualsiasi momento al 
Titolare del trattamento, Comune di Trento, per esercitare i diritti 
previsti dal GDPR. I dati di contatto del RPD e del Titolare oltre che 
l’informativa completa sono disponibili al link 
https://www.comune.trento.it/  sotto la voce 
“Privacy”.
Si precisa inoltre che le informazioni contenute nel presente 
messaggio, e negli eventuali allegati, sono riservate e per uso esclusivo 
del destinatario. In caso di ricezione dello stesso per errore, siete 
pregati di informare immediatamente il mittente e di cancellarlo dal vostro 
archivio, in conformità con quanto disposto dall'art. 17 del GDPR. Ogni 
trattamento della presente mail che non sia quello del destinatario reale è 
inteso come non autorizzato dal mittente. Inoltre, in quanto non 
destinatari reali, Vi informiamo che il mittente si oppone alla copia, la 
diffusione e la rivelazione anche parziale dei dati in esso contenuti alle 
persone non autorizzate dal medesimo, in virtù di quanto disposto dall'art. 
21 del GDPR.

___
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] Another (final?) qt6 progress catchup?

[Jürgen E . Fischer via QGIS-Developer]

Hi Matthias,

On Mon, 12. Feb 2024 at 08:11:32 +0100, Matthias Kuhn via QGIS-Developer wrote:
> I had a bit of fun over the weekend trying to build QGIS with Qt6 for
> Windows (unfortunately no executable yet), and would be interested in
> joining.

Did you run into the gperf issue?  Where gperf more or less silently produces
nearly empty files that lead to unclear link errors later?  All that deep in
webengine/chromium?  Or the long path issue?


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 Nordenhttps://www.norbit.de
QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC


signature.asc
Description: PGP signature
___
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