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

[Andreas Neumann via QGIS-Developer]

Hi,

We will discuss this at our PSC meeting on Tue 5.

Greetings,
Andreas

On Mon, 26 Feb 2024 at 00:21, Nyall Dawson via QGIS-PSC <
qgis-...@lists.osgeo.org> wrote:

> Hi PSC,
>
> I would love for an official call to be made on which of two
> conflicting pull request queue management policies should be adopted
> by QGIS.
>
> There are currently two proposals, and the lack of a formal policy is
> causing confusion/conflict in how pull requests are managed.
>
> 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.
>
> Currently, these pull requests will be auto-closed by stalebot due to
> the lack of activity on the ticket. Sandro's proposal is to disable
> stalebot handing of draft / WIP pull requests, and effectively to
> formalise that the queue is a valid place for work of this nature and
> status.
>
> (@strk please expand here if you feel I haven't summarised your point
> of view correctly!)
>
> Policy #2: https://github.com/qgis/QGIS/pull/56523
>
> In this PR I propose to set a formal policy that draft and WIP pull
> requests are NOT suitable for opening against the QGIS repository.
>
> My justification is that we have a long-standing issue with
> maintainability of the pull request queue, and anything which
> decreases the signal-to-noise ratio on open tickets is undesirable.
> 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. (Effectively right
> now we have a situation where any pull request which is pushed on the
> 2nd page of requests will basically NEVER get reviewed, as there is a
> constant stream of ready-for-review work flowing into the first page
> and the signal-to-noise ratio of ready-for-review/merge PRs on
> subsequent pages is extremely low). I do not believe it is fair for
> submissions like https://github.com/qgis/QGIS/pull/55172 or
> https://github.com/qgis/QGIS/pull/55293 where reviews take SUCH a long
> time, and it is my belief that by keeping the queue as small as
> possible and avoiding WIP/draft work we will increase the likelihood
> that PRs like these can be reviewed more quickly in future.
>
> Please note that there is considerable discussion on
> https://github.com/qgis/QGIS/pull/56062 already which should be read
> when reviewing this decision.
>
> Can I ask that PSC choose one of these two policies to formally adopt
> so that there is no misunderstanding or conflict in future?
>
> Thanks in advance!
> Nyall
> ___
> QGIS-PSC mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>


-- 

--
Andreas Neumann
QGIS.ORG board member (treasurer)
___
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] GDAL processing algorithms issues due the default output layer extensions weirdly changed

[Andrea Giudiceandrea via QGIS-Developer]

Hi all,

Il 26/02/2024 00:23, Nyall Dawson ha scritto:
> Hmm, I wonder if it's a plugin changing this setting. I've definitely
> seen plugins before doing unfriendly things like this...

I also suspected that a plugin may be involved, but I was unable to find 
a common plugin in all the reports.


Now it seems to me more likely that it may be the management of the 
settings, after seeing https://github.com/qgis/QGIS/issues/53204 and 
https://github.com/qgis/QGIS/pull/53458 precisely relating to the 
DefaultOutputRasterLayerExt and the DefaultOutputVectorLayerExt settings 
and the -1 index.



Il 26/02/2024 01:38, Even Rouault ha scritto:
> For example when using the ".xml" extension as a vector output, you'll
> probably be surprised that the obscure PDS4 vector driver (tabular data
> for planetary datasets) is used!

==> Those settings should actually be deprecated and replaced by others 
that save a GDAL driver name ... plus an extension, because the "MapInfo 
File" driver produces quite different output if you chose ".tab" or 
".mif" (or the GeoJSONSeq driver that will use different separators if 
you select the ".geojsonl" or ".geojsons" extensions)


The problem occurs also when saving the algorithm output to a file, 
instead of a temporary output, and choosing an extension.



Best regards.

Andrea
___
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

[Andreas Neumann via QGIS-Developer]

Hi,

I added Nyalls bug fixes to the visual change logs.

Mathieu: I already copied your entries on Friday. Do they need a revision?

Thanks and greetings,
Andreas

On Mon, 26 Feb 2024 at 03:05, Nyall Dawson via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> On Sun, 25 Feb 2024 at 17:47, Richard Duivenvoorde 
> wrote:
> >
> > I do not want to stress people, I just wanted to let people know.
> >
> > Just ping me here.
>
> Thanks, I'm all done now! I've sent through my bug fixes to Andreas too.
>
> Nyall
>
> >
> > Regards,
> >
> > Richard Duivenvoorde
> >
> > On 2/25/24 01:51, Mathieu Pellerin wrote:
> > > Same here, I'd appreciate a day
> > >
> > > On Sun, Feb 25, 2024, 03:24 Nyall Dawson via QGIS-Developer <
> qgis-developer@lists.osgeo.org >
> wrote:
> > >
> > >
> > >
> > > On Sat, 24 Feb 2024, 12:41 am Richard Duivenvoorde via
> QGIS-Developer,  qgis-developer@lists.osgeo.org>> wrote:
> > >
> > > Hi Devs,
> > >
> > > As release 3.36 Maidenhead is near...
> > >
> > > Please have a look at
> https://changelog.qgis.org/en/qgis/version/3.36/ <
> https://changelog.qgis.org/en/qgis/version/3.36/>
> > >
> > > To fix/polish or add stuff you did or is important to show to
> users.
> > >
> > >
> > > Could I have a day to polish off my entries please? 
> > > Nyall
> > >
> > >
> > > @Andreas: I'll wait for you to add the tables with notable
> changes, please ping me when done
> > >
> > > Then I will dump it to rst and include it in the website
> (probably for the last time, as hopefully we will have a new website next
> release :-)  ).
> > >
> > > Thanks in advance,
> > >
> > > Richard Duivenvoorde
> > > ___
> > > QGIS-Developer mailing list
> > > QGIS-Developer@lists.osgeo.org  QGIS-Developer@lists.osgeo.org>
> > > List info:
> https://lists.osgeo.org/mailman/listinfo/qgis-developer <
> https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > > Unsubscribe:
> https://lists.osgeo.org/mailman/listinfo/qgis-developer <
> https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > >
> > > ___
> > > QGIS-Developer mailing list
> > > QGIS-Developer@lists.osgeo.org  QGIS-Developer@lists.osgeo.org>
> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> > > Unsubscribe:
> https://lists.osgeo.org/mailman/listinfo/qgis-developer <
> 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
>


-- 

--
Andreas Neumann
QGIS.ORG board member (treasurer)
___
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] Plugin update

[Zoltán Siki via QGIS-Developer]

Dear Developers,

I have made a pull request one and half year ago to the MapSwipeTool
plugin, but the developer of the plugin didn't do anything with it. I made
only a minor change in the code, caused by the change in QLine parameters.
The latest version of the plugin, available from the plugins.qgis.org repo
is useless, it fails after activation. Some users react to my pull request,
that it solves the issue (
https://github.com/lmotta/mapswipetool_plugin/pulls). This plugin is/was
popular, more than hundred thousand downloads.
I don't want to take over the development and the maintenance of this
plugin, just make the workable version available for the users as a new
version in the plugin repo. Can it be done somehow without being the owner
of the plugin?
-- 
Thanks,
Zoltan Siki
___
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 Sun, 25 Feb 2024 at 17:47, Richard Duivenvoorde  wrote:
>
> I do not want to stress people, I just wanted to let people know.
>
> Just ping me here.

Thanks, I'm all done now! I've sent through my bug fixes to Andreas too.

Nyall

>
> Regards,
>
> Richard Duivenvoorde
>
> On 2/25/24 01:51, Mathieu Pellerin wrote:
> > Same here, I'd appreciate a day
> >
> > On Sun, Feb 25, 2024, 03:24 Nyall Dawson via QGIS-Developer 
> > mailto:qgis-developer@lists.osgeo.org>> 
> > wrote:
> >
> >
> >
> > On Sat, 24 Feb 2024, 12:41 am Richard Duivenvoorde via QGIS-Developer, 
> > mailto:qgis-developer@lists.osgeo.org>> 
> > wrote:
> >
> > Hi Devs,
> >
> > As release 3.36 Maidenhead is near...
> >
> > Please have a look at 
> > https://changelog.qgis.org/en/qgis/version/3.36/ 
> > 
> >
> > To fix/polish or add stuff you did or is important to show to users.
> >
> >
> > Could I have a day to polish off my entries please? 
> > Nyall
> >
> >
> > @Andreas: I'll wait for you to add the tables with notable changes, 
> > please ping me when done
> >
> > Then I will dump it to rst and include it in the website (probably 
> > for the last time, as hopefully we will have a new website next release :-) 
> >  ).
> >
> > Thanks in advance,
> >
> > Richard Duivenvoorde
> > ___
> > 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

Re: [QGIS-Developer] GDAL processing algorithms issues due the default output layer extensions weirdly changed

[Even Rouault via QGIS-Developer]

I'm not sure if that explains the family of bugs seen, but as those 
settings are a *integer* index in the list returned by 
QgsVectorFileWriter::supportedFormatExtensions() or 
QgsRasterFileWriter::supportedFormatExtensions() , they depend both on 
the QGIS list of known formats which may evolve over versions (not that 
frequent that said), and/or if the GDAL version changes and/or if 
drivers are enabled/disabled. It would be more robust to capture the 
extension as a string rather than an index.


And even capturing an extension is not super robust, as potentially 
several drivers could recognize the same extension


For example when using the ".xml" extension as a vector output, you'll 
probably be surprised that the obscure PDS4 vector driver (tabular data 
for planetary datasets) is used!


This is because:

$ ogrinfo --formats | grep xml | grep 'w'
  PDS4 -raster,vector- (rw+vs): NASA Planetary Data System 4 (*.xml)
  GML -vector- (rw+v): Geography Markup Language (GML) (*.gml, *.xml)
  Interlis 2 -vector- (rw+v): Interlis 2 (*.xtf, *.xml, *.ili)
  GMLAS -vector- (rwv): Geography Markup Language (GML) driven by 
application schemas (*.gml, *.xml)


whereas looking at QgsVectorFileWriterMetadataContainer , I strongly 
suspect that the intent was rather to use the GeoRSS driver for which 
QGIS registers a .xml extension (the GDAL GeoRSS driver doesn't 
advertize a particular file extension)


==> Those settings should actually be deprecated and replaced by others 
that save a GDAL driver name ... plus an extension, because the "MapInfo 
File" driver produces quite different output if you chose ".tab" or 
".mif" (or the GeoJSONSeq driver that will use different separators if 
you select the ".geojsonl" or ".geojsons" extensions)


Even

Le 26/02/2024 à 00:23, Nyall Dawson via QGIS-Developer a écrit :

On Mon, 26 Feb 2024 at 08:58, Andrea Giudiceandrea via QGIS-Developer
 wrote:

Hi developers,
various QGIS users have reported during the latest months (mostly since
September 2023, and a couple also back in July 2023) on various channels
a strange issue which makes the GDAL processing algorithms to fail when
the temporary output is set.

Looking at the provided processing logs, it turns out that the issue is
due to the fact that the default output vector layer extension was set
to .xtf "Interlis 2" (instead of the default .gpkg "GeoPackage") or that
the default output raster layer extension was set to .nc "NetCDF"
(instead of the default .tif "GeoTIFF").

The weird think is that all the users affected by the issue have
reported that they had not deliberately changed these settings.

Hmm, I wonder if it's a plugin changing this setting. I've definitely
seen plugins before doing unfriendly things like this...

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


--
http://www.spatialys.com
My software is free, but my time generally not.

___
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] GDAL processing algorithms issues due the default output layer extensions weirdly changed

[Nyall Dawson via QGIS-Developer]

On Mon, 26 Feb 2024 at 08:58, Andrea Giudiceandrea via QGIS-Developer
 wrote:
>
> Hi developers,
> various QGIS users have reported during the latest months (mostly since
> September 2023, and a couple also back in July 2023) on various channels
> a strange issue which makes the GDAL processing algorithms to fail when
> the temporary output is set.
>
> Looking at the provided processing logs, it turns out that the issue is
> due to the fact that the default output vector layer extension was set
> to .xtf "Interlis 2" (instead of the default .gpkg "GeoPackage") or that
> the default output raster layer extension was set to .nc "NetCDF"
> (instead of the default .tif "GeoTIFF").
>
> The weird think is that all the users affected by the issue have
> reported that they had not deliberately changed these settings.

Hmm, I wonder if it's a plugin changing this setting. I've definitely
seen plugins before doing unfriendly things like this...

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

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

[Nyall Dawson via QGIS-Developer]

Hi PSC,

I would love for an official call to be made on which of two
conflicting pull request queue management policies should be adopted
by QGIS.

There are currently two proposals, and the lack of a formal policy is
causing confusion/conflict in how pull requests are managed.

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.

Currently, these pull requests will be auto-closed by stalebot due to
the lack of activity on the ticket. Sandro's proposal is to disable
stalebot handing of draft / WIP pull requests, and effectively to
formalise that the queue is a valid place for work of this nature and
status.

(@strk please expand here if you feel I haven't summarised your point
of view correctly!)

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

In this PR I propose to set a formal policy that draft and WIP pull
requests are NOT suitable for opening against the QGIS repository.

My justification is that we have a long-standing issue with
maintainability of the pull request queue, and anything which
decreases the signal-to-noise ratio on open tickets is undesirable.
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. (Effectively right
now we have a situation where any pull request which is pushed on the
2nd page of requests will basically NEVER get reviewed, as there is a
constant stream of ready-for-review work flowing into the first page
and the signal-to-noise ratio of ready-for-review/merge PRs on
subsequent pages is extremely low). I do not believe it is fair for
submissions like https://github.com/qgis/QGIS/pull/55172 or
https://github.com/qgis/QGIS/pull/55293 where reviews take SUCH a long
time, and it is my belief that by keeping the queue as small as
possible and avoiding WIP/draft work we will increase the likelihood
that PRs like these can be reviewed more quickly in future.

Please note that there is considerable discussion on
https://github.com/qgis/QGIS/pull/56062 already which should be read
when reviewing this decision.

Can I ask that PSC choose one of these two policies to formally adopt
so that there is no misunderstanding or conflict in future?

Thanks in advance!
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

[QGIS-Developer] GDAL processing algorithms issues due the default output layer extensions weirdly changed

[Andrea Giudiceandrea via QGIS-Developer]

Hi developers,
various QGIS users have reported during the latest months (mostly since 
September 2023, and a couple also back in July 2023) on various channels 
a strange issue which makes the GDAL processing algorithms to fail when 
the temporary output is set.


Looking at the provided processing logs, it turns out that the issue is 
due to the fact that the default output vector layer extension was set 
to .xtf "Interlis 2" (instead of the default .gpkg "GeoPackage") or that 
the default output raster layer extension was set to .nc "NetCDF" 
(instead of the default .tif "GeoTIFF").


The weird think is that all the users affected by the issue have 
reported that they had not deliberately changed these settings.


Currently there is no issue report open on GitHub since they have been 
closed one by the reporter and one as duplicate.
Anyway the issues reports were about the processing issues and not about 
the "who changed the default output layer extensions?" issue.


I tried without success to find out what's going on and I hope some 
developers can have a look and find the root cause of the issue, since 
the issue continues to be reported by the users.
Actually the issue can also affect both the QGIS and the GRASS 
processing algorithms that have a raster output, although not reported yet.


Since both the layer extensions .xtf "Interlis 2" and .nc "NetCDF" are 
the last one (i.e. index -1) in the default output vector layer 
extension list and the the default output raster layer extension list, 
It may be possible that the issue may be due to the recent changes in 
the settings storing / retrieving logic.


You'll find the links to a dozen reports (either on GitHub, 
stackexchange, qgis-user ml, Facebook groups) listed in the comments of 
the closed issue report at https://github.com/qgis/QGIS/issues/54952


Best regards.

Andrea Giudiceandrea


P.S. while writing this message I found an issue report 
https://github.com/qgis/QGIS/issues/53204 and a PR 
https://github.com/qgis/QGIS/pull/53458 allegedly fixing it both dating 
May 2023 precisely relating to the DefaultOutputRasterLayerExt and the 
DefaultOutputVectorLayerExt settings.

___
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