[QGIS-Developer] Plugin [1559] QuickMultiAttributeEdit3 approval notification.

[noreply]

Plugin QuickMultiAttributeEdit3 approval by pcav.
The plugin version "[1559] QuickMultiAttributeEdit3 3.0.1" is now approved
Link: http://plugins.qgis.org/plugins/QuickMultiAttributeEdit3/
___
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] Connected problems with QGIS3 crashes and python standalone crashes?

[John Harrop]

Nothing like posting a question to trigger stumbling across the solution.  It 
appears that a solution was found back in the Summer in this thread: 
https://www.mail-archive.com/qgis-user@lists.osgeo.org/msg40317.html

I tried adding this and both of the problems seem to have gone - although I 
still did get an exception when I exited the bare bones standalone python code.

export QT_QPA_PLATFORM_PLUGIN_PATH="/Applications/QGIS3.app/Contents/Plugins"

John




Hello,

Now that QGIS3 is well underway I’ve been looking at getting some Python3 code 
working with QGIS as standalone and plugins apps.  But I have two - possibly 
related persistent problems with QGIS3 and this list was suggested as a good 
place to ask advice.

I’m running 3.4 (just upgraded yesterday) on Mac OSX 10.13.6

I can work in QGIS and have been using it for ongoing work - so everything 
seems good until I get to quitting.  Shortly after I’ve closed QGIS I get crash 
report (parts included below).  Its a bit unclear exactly what is causing the 
crash - and its been happening since I went to QGIS3.  I should (admit) that I 
was also running the beta and building that so there is a possibility that I 
have some left over side effects of that I have not been able to clean up.  I 
have taken out everything I can track down on that and some other dev things 
(not QGIS) I was doing a year or longer ago.

The other crash that may be related and seems to give more info is when I run 
the basic standalone app example from the PyQGIS book.  The : = 
QgsApplication([], False) crashes with an abort trap 6 and the message: 
qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in “"

This looks a lot like a missing path problem, but I have been unable to resolve 
where it is missing.  As far as I can see the qt and cocoa support libraries 
are in the GIS3 app contents subdirectories, so I’m at a loss as to what is 
really missing.

Any suggestions for where to go would be appreciated.


John Harrop
Senior Project Geologist
CMG

Here is a part of the crash report after closing the QGIS app.  QT seems to be 
involved in this too - although the details are less clear to me.  So I’m 
hoping that solving one problem will clear both.:

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   EXC_I386_GPFLT
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Segmentation fault: 11
Termination Reason:Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.qt-project.QtWidgets0x00011524fd6e 
QWidget::mapTo(QWidget const*, QPoint const&) const + 46
1   org.qgis.qgis3_gui  0x000110221bef 
QgsFloatingWidget::onAnchorPointChanged() + 375
2   org.qt-project.QtCore   0x000118e7053b 
QMetaObject::activate(QObject*, int, int, void**) + 2347
3   org.qgis.qgis3_gui  0x000110222027 
QgsFloatingWidgetEventFilter::eventFilter(QObject*, QEvent*) + 21
4   org.qt-project.QtCore   0x000118e3f832 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) + 210
5   org.qt-project.QtWidgets0x00011522befd 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 285
6   org.qt-project.QtWidgets0x00011522d2ed 
QApplication::notify(QObject*, QEvent*) + 573
7   org.qgis.qgis3_core 0x00011127cb21 
QgsApplication::notify(QObject*, QEvent*) + 93
8   org.qt-project.QtCore   0x000118e3f54f 
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 159
9   org.qt-project.QtWidgets0x000115286ec7 0x11521c000 + 437959
10  org.qt-project.QtWidgets0x00011528512d 0x11521c000 + 430381
11  org.qt-project.QtWidgets0x00011522bf12 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 306
12  org.qt-project.QtWidgets0x00011522d2ed 
QApplication::notify(QObject*, QEvent*) + 573
13  org.qgis.qgis3_core 0x00011127cb21 
QgsApplication::notify(QObject*, QEvent*) + 93
14  org.qt-project.QtCore   0x000118e3f54f 
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 159
15  org.qt-project.QtGui0x00011862a1cd 
QGuiApplicationPrivate::processGeometryChangeEvent(QWindowSystemInterfacePrivate::GeometryChangeEvent*)
 + 381
16  org.qt-project.QtGui0x00011860f9b4 
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
 + 404
17  org.qt-project.QtGui0x00011860b320 
QWindowSystemInterface::flushWindowSystemEvents(QFlags)
 + 576
18  libqcocoa.dylib 0x00011b493a65 0x11b48 + 80485
19  org.qt-project.QtCore   0x000118e496dc 
QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, 

Re: [QGIS-Developer] Early 3.4 point release?

[Jürgen E . Fischer]

Hi Nyall,

On Thu, 01. Nov 2018 at 08:09:08 +1000, Nyall Dawson wrote:
> On Wed, 31 Oct 2018 at 21:23, Jürgen E. Fischer  wrote:

> > So where are we with fixing the urgent bugs?   EPR next friday 12:00 UTC?

> > Next regular PR would be 2018-11-23 12:00:00 UTC
 
> Thanks Jürgen -- for clarification do you mean 2018-11-02 or 2018-11-09?

I meant 2018-11-02.  2018-11-09 would of course work as well, if there's more
to fix.

 
Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
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] Early 3.4 point release?

[Pedro Venâncio]

Hi Nyall,


> > (tools not
> > working when windows regional settings are not set to English and also
>
> Someone else will need to fix this one, it's not something I can
> reproduce. Any volunteers? If there's none, we shouldn't hold back a
> release for this.
>

https://issues.qgis.org/issues/20244

To reproduce this one, I think you can, just changing your windows regional
settings to, for instance, Portuguese (Portugal).

Best regards,
Pedro

>
___
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] Early 3.4 point release?

[Nyall Dawson]

On Wed, 31 Oct 2018 at 20:22, Matthias Kuhn  wrote:

> But still then there will be issues and most people will only start
> testing the final release and we will run into "unknown issues" and
> "unreported issues" while working on QGIS and fix and push them without
> a big admin overhead. And we just have to accept that this is our life
> as software engineers and we all do the best we can :-)

Yep. 100% agree -- this is something we always must keep in mind in
these discussions. We'll never achieve a 100% regression free release,
it's just not possible given the complexity of QGIS. And probably has
never been done in the history of software development ever anyway!

In this particular case I don't see how we could have avoided it. It's
a "perfect storm" combination of:
1. Lack of clarity and huge warnings in the Qt docs about how an API
was designed to be used
2. QGIS developers relying on previous behavior of this API
3. Qt developers putting stronger checks preventing use of the API in
the way it wasn't designed, which as a result broke QGIS functionality
4. The bug only being visible in a highly GUI dependent setup -- it
relies on a very recent Qt version and QGIS network based request with
HTTPS in a background thread. Possibly we could/should have unit tests
for this, but it's a very difficult situation to test for and predict
in advance.
5. A QGIS release falling right at a time when a number of
platform/library upgrades occurred, which upgraded Qt to the newer
version, which meant that users had barely any time to test on these
upgraded platforms before final release.

I honestly can't see how any of these factors could have been avoided.
Maybe for 5 we could ensure that our release schedule doesn't coincide
with Ubuntu's, but we can't predict Windows/macOS/Fedora/etc release
schedules, so that would only be a small band aid.

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] QGISServer: how to find out shared lib path for qgis_mapserv.fcgi

[Richard Duivenvoorde]

Hi,

Compiling QGIS + server on a custom Debian machine here, install in my
local dir, make the install dir group www-data.

Put qgis_mapserv.fcgi in /usr/lib/cgi-bin

Testing an url I get ing logs:

/usr/lib/cgi-bin/qgis_mapserv.fcgi: error while loading shared
libraries: libqgis_server.so.3.5.0: cannot open shared object file: No
such file or directory

It IS working if I copy all the .so files to /usr/lib

BUT I thought I could instruct qgis/fcgi to use a custom, by using
something like below in my apache config (was not sure which one to use,
so used both):

FcgidInitialEnv
LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/home/richard/bin/qgis/master/debug/lib"
SetEnv
LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:/home/richard/bin/qgis/master/debug/lib"

This is not working, any fcgi guru has a hint?

Regards,

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

Re: [QGIS-Developer] Early 3.4 point release?

[Nyall Dawson]

On Wed, 31 Oct 2018 at 21:23, Jürgen E. Fischer  wrote:

> So where are we with fixing the urgent bugs?   EPR next friday 12:00 UTC?
>
> Next regular PR would be 2018-11-23 12:00:00 UTC

Thanks Jürgen -- for clarification do you mean 2018-11-02 or 2018-11-09?

Nyall


>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> ___
> 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] Early 3.4 point release?

[Nyall Dawson]

On Wed, 31 Oct 2018 at 19:12, Giovanni Manghi  wrote:
> there are also two major issues with Processing/GRASS

> not working for any multilayer datasource like gpkg),

Fixed by https://github.com/qgis/QGIS/pull/8393, which also adds unit
tests to this functionality.

> (tools not
> working when windows regional settings are not set to English and also

Someone else will need to fix this one, it's not something I can
reproduce. Any volunteers? If there's none, we shouldn't hold back a
release for 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

Re: [QGIS-Developer] Early 3.4 point release?

[Nyall Dawson]

On Wed, 31 Oct 2018 at 20:49, Richard Duivenvoorde  wrote:
>
> Anyway, before releasing 3.4.1 please can other check/confirm this one:
> https://issues.qgis.org/issues/20295

Fixed in master (and only an issue on debug enabled builds). Will
backport to 3.4.

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] Connected problems with QGIS3 crashes and python standalone crashes?

[John Harrop]

Hello,

Now that QGIS3 is well underway I’ve been looking at getting some Python3 code 
working with QGIS as standalone and plugins apps.  But I have two - possibly 
related persistent problems with QGIS3 and this list was suggested as a good 
place to ask advice.

I’m running 3.4 (just upgraded yesterday) on Mac OSX 10.13.6

I can work in QGIS and have been using it for ongoing work - so everything 
seems good until I get to quitting.  Shortly after I’ve closed QGIS I get crash 
report (parts included below).  Its a bit unclear exactly what is causing the 
crash - and its been happening since I went to QGIS3.  I should (admit) that I 
was also running the beta and building that so there is a possibility that I 
have some left over side effects of that I have not been able to clean up.  I 
have taken out everything I can track down on that and some other dev things 
(not QGIS) I was doing a year or longer ago.

The other crash that may be related and seems to give more info is when I run 
the basic standalone app example from the PyQGIS book.  The qgs = 
QgsApplication([], False) crashes with an abort trap 6 and the message: 
qt.qpa.plugin: Could not find the Qt platform plugin "cocoa" in “"

This looks a lot like a missing path problem, but I have been unable to resolve 
where it is missing.  As far as I can see the qt and cocoa support libraries 
are in the GIS3 app contents subdirectories, so I’m at a loss as to what is 
really missing.

Any suggestions for where to go would be appreciated.


John Harrop
Senior Project Geologist
CMG

Here is a part of the crash report after closing the QGIS app.  QT seems to be 
involved in this too - although the details are less clear to me.  So I’m 
hoping that solving one problem will clear both.:

Exception Type:EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:   EXC_I386_GPFLT
Exception Note:EXC_CORPSE_NOTIFY

Termination Signal:Segmentation fault: 11
Termination Reason:Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   org.qt-project.QtWidgets0x00011524fd6e 
QWidget::mapTo(QWidget const*, QPoint const&) const + 46
1   org.qgis.qgis3_gui  0x000110221bef 
QgsFloatingWidget::onAnchorPointChanged() + 375
2   org.qt-project.QtCore   0x000118e7053b 
QMetaObject::activate(QObject*, int, int, void**) + 2347
3   org.qgis.qgis3_gui  0x000110222027 
QgsFloatingWidgetEventFilter::eventFilter(QObject*, QEvent*) + 21
4   org.qt-project.QtCore   0x000118e3f832 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) + 210
5   org.qt-project.QtWidgets0x00011522befd 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 285
6   org.qt-project.QtWidgets0x00011522d2ed 
QApplication::notify(QObject*, QEvent*) + 573
7   org.qgis.qgis3_core 0x00011127cb21 
QgsApplication::notify(QObject*, QEvent*) + 93
8   org.qt-project.QtCore   0x000118e3f54f 
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 159
9   org.qt-project.QtWidgets0x000115286ec7 0x11521c000 + 437959
10  org.qt-project.QtWidgets0x00011528512d 0x11521c000 + 430381
11  org.qt-project.QtWidgets0x00011522bf12 
QApplicationPrivate::notify_helper(QObject*, QEvent*) + 306
12  org.qt-project.QtWidgets0x00011522d2ed 
QApplication::notify(QObject*, QEvent*) + 573
13  org.qgis.qgis3_core 0x00011127cb21 
QgsApplication::notify(QObject*, QEvent*) + 93
14  org.qt-project.QtCore   0x000118e3f54f 
QCoreApplication::notifyInternal2(QObject*, QEvent*) + 159
15  org.qt-project.QtGui0x00011862a1cd 
QGuiApplicationPrivate::processGeometryChangeEvent(QWindowSystemInterfacePrivate::GeometryChangeEvent*)
 + 381
16  org.qt-project.QtGui0x00011860f9b4 
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
 + 404
17  org.qt-project.QtGui0x00011860b320 
QWindowSystemInterface::flushWindowSystemEvents(QFlags)
 + 576
18  libqcocoa.dylib 0x00011b493a65 0x11b48 + 80485
19  org.qt-project.QtCore   0x000118e496dc 
QMetaMethod::invoke(QObject*, Qt::ConnectionType, QGenericReturnArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument, QGenericArgument, QGenericArgument, 
QGenericArgument, QGenericArgument) const + 1308
20  libqcocoa.dylib 0x00011b49a06d 0x11b48 + 106605
21  com.apple.Foundation0x7fff3097c640 -[__NSObserver 
_doit:] + 303
22  com.apple.CoreFoundation0x7fff2e86eedc 
__CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 12
23  com.apple.CoreFoundation0x7fff2e86edaa _CFXRegistrationPost 
+ 458
24  com.apple.CoreFoundation

[QGIS-Developer] Plugin [1357] Least-Cost-Paths Network approval notification.

[noreply]

Plugin Least-Cost-Paths Network approval by pcav.
The plugin version "[1357] Least-Cost-Paths Network 0.1.2 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/LCPNetwork/
___
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] Early 3.4 point release?

[Matthias Kuhn]

Hi Jürgen

On 10/31/18 12:14 PM, Jürgen E. Fischer wrote:
> Hi Matthias,
> 
> On Wed, 31. Oct 2018 at 11:22:40 +0100, Matthias Kuhn wrote:
>> I like the concept of a "release candidate".
>  
>> I think by labeling a package as RC we will encourage people to
> 
> I doubt that two letters will be a gamechanger.

Not that much on their own. I agree. But I don't expect them to hurt a
lot either.

> 
> 
>> Either we call the LTR x.y.0 version a RC (instead of the first release)
>> - or the 4 last weeklies before the release are labeled as RC.
> 
> Not very prominent, but that's already there:
> "In the feature freeze phase that [the weekly snapshot] also acts as release
> candidate."

We could try to put this on the main screen of qgis.org and do some
twitter / blog announcements when 3.10 LTR weeklies are released and see
if it helps.

Cheers
Matthias



signature.asc
Description: OpenPGP digital 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] Early 3.4 point release?

[Paolo Cavallini]

Hi all,


Il 10/31/2018 12:14 PM, Jürgen E. Fischer ha scritto:
>
> Sounds like the best option - other options probably end up with the same
> result just with more effort ;)
>
>
IMHO our release procedure is OK, I agree with Juergen.
IMHO it's just a matter of communication. We should make clear that upon
release there may still be bugs, even serious, so people are  prepared
to deal with it. Google solved a similar issue by calling their programs
"beta" for a long period.

All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/




signature.asc
Description: OpenPGP digital 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] Early 3.4 point release?

[Jürgen E . Fischer]

Hi Matthias,

On Wed, 31. Oct 2018 at 11:22:40 +0100, Matthias Kuhn wrote:
> I like the concept of a "release candidate".
 
> I think by labeling a package as RC we will encourage people to

I doubt that two letters will be a gamechanger.


> Either we call the LTR x.y.0 version a RC (instead of the first release)
> - or the 4 last weeklies before the release are labeled as RC.

Not very prominent, but that's already there:
"In the feature freeze phase that [the weekly snapshot] also acts as release
candidate."


> But still then there will be issues and most people will only start
> testing the final release and we will run into "unknown issues" and
> "unreported issues" while working on QGIS and fix and push them without
> a big admin overhead. And we just have to accept that this is our life
> as software engineers and we all do the best we can :-)

Sounds like the best option - other options probably end up with the same
result just with more effort ;)

And to me only people that tested the nightly before the release are allowed to
complain about preexisting bugs right after the release.  If you can jump on
the released packages right away, you should have also been able to do so with
a nightly earlier.  But this time they might even have done that and the
problem was introduced by upgrading Qt late.

So where are we with fixing the urgent bugs?   EPR next friday 12:00 UTC?

Next regular PR would be 2018-11-23 12:00:00 UTC


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
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] Early 3.4 point release?

[Matthias Kuhn]

Hi Giovanni,

On 10/31/18 11:47 AM, Giovanni Manghi wrote:
> Hi Matthias,
> 
>>> The problem here is the "known" part: if we had more testers on the
>>> nightlies during the two weeks before the release date, we would
>>> probably have catched some of these regression in time to fix them.
>>
>> Agreed, the more testing the better.
> 
> serious manual/semi-automated testing (of most functionalities, on the
> 3 major platforms, using multiple type/versions of QGIS and endpoints,
> etc.) is a full time job, I know because  I was lucky enough to have
> done it for a year and half. Without this type of effort we will
> always rely on reports sent in by people that find issues here and
> there while doing their normal workflow, which is ok but also has a
> good chance of not finding a number of serious bugs.

I am very much aware of the importance of testing in a structured way.
And I am very happy that we have a solid team of regular testers around you.

The limitation is that our current resources don't allow for employing
people to do more than that unless I am mistaken. So we are left with
less resources than a full-time job for that.

As a result of that, my proposal is aimed towards encouraging volunteers
to test as much as possible within the bounds of the available
resources. Tagging something as RC costs close to nothing but I have
hope that it helps to get more testing prior to a release.

If there's someone that comes up with a team of testers that is
available for serious structured testing, I'll be the last one to say no!

Cheers
Matthias

> 
> cheers!
> 
> -- g --
> 
___
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] Early 3.4 point release?

[Alessandro Pasotti]

On Wed, Oct 31, 2018 at 11:48 AM Giovanni Manghi 
wrote:

> Hi Matthias,
>
> > > The problem here is the "known" part: if we had more testers on the
> > > nightlies during the two weeks before the release date, we would
> > > probably have catched some of these regression in time to fix them.
> >
> > Agreed, the more testing the better.
>
> serious manual/semi-automated testing (of most functionalities, on the
> 3 major platforms, using multiple type/versions of QGIS and endpoints,
> etc.) is a full time job, I know because  I was lucky enough to have
> done it for a year and half. Without this type of effort we will
> always rely on reports sent in by people that find issues here and
> there while doing their normal workflow, which is ok but also has a
> good chance of not finding a number of serious bugs.
>
> cheers!
>
> -- g --
>


Giovanni,

I'm not talking about the test cycles a company could run, but if we did a
call for testers and prepared a page with instructions, we may have had a
dedicated group of people (users) who is willing to help the QGIS project
running test cyles, and as I said, going through the current
lessons/tutorial may be sufficient.

So, the plan would be:
1. prepare a page about how to run tests (based on the lessons/tutorials)
2. ask the community via email, twitter, whatever, to join the effort of
running test cycles when the code freezes
3. before any new release GOTO 2

I don't know if that will work, but worth trying.

-- 
Alessandro Pasotti
w3:   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] Early 3.4 point release?

[Richard Duivenvoorde]

On 10/31/2018 11:08 AM, Alessandro Pasotti wrote:
> We might want to introduce the concept of release candidate, in order to
> have a stricter code freeze, and give the testers and translators some
> amount of time for testing and translations, during this time only "real"
> bug fixes should be allowed.
> 
> That said, I think that "release early release often" is still the best way
> we can handle release cycles.

I'm also +1 for release early and often in the pace we do now.
I think FOSS depends on users. If you have are a commercial company you
can pay testers (who create test scenario's etc etc).. costing a lot of
money. We have users who test, and yes, they do mostly around (after?)
release... So: release often.

And I DO test (and compile) all the time (almost daily compiles).
Off course more testing would maybe make some(!) issues be fixed before
a release.

And we DO have a 'feature freeze' in which we should ( try to ;-) ) only
fix bugs (as if it was a RC). So adding another RC is only
theoretical/administrive in my view.
We could be more strict though...

Bugs like the one above can always be introduced even when we had a RC.
That is one of the drawbacks of compiling for so many platforms (with so
many versions of needed libs).

But that is also our strength!

Anyway, before releasing 3.4.1 please can other check/confirm this one:
https://issues.qgis.org/issues/20295

Regards,

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

Re: [QGIS-Developer] Early 3.4 point release?

[Giovanni Manghi]

Hi Matthias,

> > The problem here is the "known" part: if we had more testers on the
> > nightlies during the two weeks before the release date, we would
> > probably have catched some of these regression in time to fix them.
>
> Agreed, the more testing the better.

serious manual/semi-automated testing (of most functionalities, on the
3 major platforms, using multiple type/versions of QGIS and endpoints,
etc.) is a full time job, I know because  I was lucky enough to have
done it for a year and half. Without this type of effort we will
always rely on reports sent in by people that find issues here and
there while doing their normal workflow, which is ok but also has a
good chance of not finding a number of serious bugs.

cheers!

-- g --
___
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] Early 3.4 point release?

[Matthias Kuhn]

On 10/31/18 11:08 AM, Alessandro Pasotti wrote:
> 
> 
> On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi
> mailto:giovanni.man...@gmail.com>> wrote:
> 
> > This code freeze period will need to be associated with a strict
> definition of "blocker issues" that really need to by adressed
> immediatly. This issue here is a great example of a valid blocker.
> 
> big fan of the "no known regressions admitted", at least for LTR
> releases.
> 
> 
> The problem here is the "known" part: if we had more testers on the
> nightlies during the two weeks before the release date, we would
> probably have catched some of these regression in time to fix them.

Agreed, the more testing the better.

> I think that it would be a good idea to create a group of volunteer
> testers, like we have for translators, that can regularly run test
> cycles (for example going through the tutorials that we already have)>
> We might want to introduce the concept of release candidate, in order to
> have a stricter code freeze, and give the testers and translators some
> amount of time for testing and translations, during this time only
> "real" bug fixes should be allowed.

I like the concept of a "release candidate".

I think by labeling a package as RC we will encourage people to

 - download and test the application
 - not use them in production
 - be relaxed about issues (because they are expected)
 - as a nice side-effect, it's also a good point in time for rolling the
   drums about an upcoming LTR.

Either we call the LTR x.y.0 version a RC (instead of the first release)
- or the 4 last weeklies before the release are labeled as RC.

But still then there will be issues and most people will only start
testing the final release and we will run into "unknown issues" and
"unreported issues" while working on QGIS and fix and push them without
a big admin overhead. And we just have to accept that this is our life
as software engineers and we all do the best we can :-)

> 
> That said, I think that "release early release often" is still the best
> way we can handle release cycles.
> 
> -- 
> Alessandro Pasotti
> w3:   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
> 
___
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] Early 3.4 point release?

[Alessandro Pasotti]

On Wed, Oct 31, 2018 at 10:41 AM Giovanni Manghi 
wrote:

> > This code freeze period will need to be associated with a strict
> definition of "blocker issues" that really need to by adressed immediatly.
> This issue here is a great example of a valid blocker.
>
> big fan of the "no known regressions admitted", at least for LTR releases.
>

The problem here is the "known" part: if we had more testers on the
nightlies during the two weeks before the release date, we would probably
have catched some of these regression in time to fix them.

I think that it would be a good idea to create a group of volunteer
testers, like we have for translators, that can regularly run test cycles
(for example going through the tutorials that we already have).

We might want to introduce the concept of release candidate, in order to
have a stricter code freeze, and give the testers and translators some
amount of time for testing and translations, during this time only "real"
bug fixes should be allowed.

That said, I think that "release early release often" is still the best way
we can handle release cycles.

-- 
Alessandro Pasotti
w3:   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] MacOS packaging

[Peter Petrik]

Hi,

as my prototyping goes forward, I managed to create first dmg file for 3.5
master. If you want to try it out, here is the link:
https://www.dropbox.com/s/vkl9oe691lkdrqh/qgis_31102018_1.dmg?dl=0
I used Mojave 10.14, homebrew for dependecies, XCode Version 10.1 (10B61).

I would be glad for any feedback, either positive or negative on PM/email
or feel free to report the issues directly on
https://github.com/lutraconsulting/qgis-mac-packager/issues

Thanks,
Peter


On Tue, Oct 30, 2018 at 12:09 PM Tom Chadwin 
wrote:

> The NextGIS installer was cited to me by an expert user as the best
> installation method of which he was aware (discussion here:
> https://twitter.com/richardf/status/969522358640881664). I don't know how
> useful that information is.
>
> Thanks
>
> Tom
>
>
>
> -
> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> ___
> 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] Early 3.4 point release?

[Giovanni Manghi]

> This code freeze period will need to be associated with a strict definition 
> of "blocker issues" that really need to by adressed immediatly. This issue 
> here is a great example of a valid blocker.

big fan of the "no known regressions admitted", at least for LTR releases.

-- G --
___
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] Early 3.4 point release?

[Giovanni Manghi]

> there are also two major issues with Processing/GRASS (tools not
> working when windows regional settings are not set to English and also
> not working for any multilayer datasource like gpkg), this is for many
> a blocker for the process of adopting QGIS 3 LTR over 2.18.

both are regressions since 2.18

-- G --
___
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] Early 3.4 point release?

[Régis Haubourg]

Thanks Nyall for raising this.
This indeed fells like "deja vu" and we need to advertise users that a
fresh new major release will for sure need point releases. We didn't
probably explain well enough that 3.4 is the LTR candidate, but will
definitly be a LTR in january at the end of life of 2.18 version.

I am a big +1 on a code freeze period. This code freeze period will need to
be associated with a strict definition of "blocker issues" that really need
to by adressed immediatly. This issue here is a great example of a valid
blocker.

I also think we have now a large enough code base and user base to prepare
a slower release cycle with longer feature freeze, bugfix  and code freeze.
We talked about it in Zanzibar, and I think advertising now that by the end
of 2019, ltr should be supported for 2 years, and releases every 6 months
would be nice.

What worries me in current fast cycle is that we have a lot of packaging
burden for all OS, and each release has a human cost. I think it's time we
just slow down just a little, but 6 months would already be something
really fast for such a big software in fact.

Cheers

Régis



Le mer. 31 oct. 2018 à 10:12, Giovanni Manghi  a
écrit :

> Hi Nyall, all,
>
>
> > Soo could we break the normal cycle and get a point release out
> > quickly? (Ideally with a couple of days prenotice so that anyone else
> > working on urgent bug fixes could get them in too)
>
> there are also two major issues with Processing/GRASS (tools not
> working when windows regional settings are not set to English and also
> not working for any multilayer datasource like gpkg), this is for many
> a blocker for the process of adopting QGIS 3 LTR over 2.18.
>
> cheers!
>
> -- g --
> ___
> 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] Early 3.4 point release?

[Giovanni Manghi]

Hi Nyall, all,


> Soo could we break the normal cycle and get a point release out
> quickly? (Ideally with a couple of days prenotice so that anyone else
> working on urgent bug fixes could get them in too)

there are also two major issues with Processing/GRASS (tools not
working when windows regional settings are not set to English and also
not working for any multilayer datasource like gpkg), this is for many
a blocker for the process of adopting QGIS 3 LTR over 2.18.

cheers!

-- g --
___
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] Early 3.4 point release?

[Luigi Pirelli]

I feel that this is a really serious issue that IMHO can justify a point
release

Peter, +1 to a release candidate

Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
*
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**


On Wed, 31 Oct 2018 at 08:04, Peter Petrik <
peter.pet...@lutraconsulting.co.uk> wrote:

> Hi,
>
> > Bah... feels like *every* major release someone ends up sending an
> email like this...
>
> My opinion this may show a problem with our development cycle setup. In my
> previous company, different closed-sourced software, we had so called code
> freeze. For example it could be 1-2 weeks before actual release and ideally
> some users would have time to test the "release-candidate" of QGIS before
> going public.
>
> From wikipedia:
>
>- A *(complete) code freeze*, in which no changes whatsoever are
>permitted to a portion or the entirety of the program's source code.
>Particularly in large software systems, any change to the source code may
>have unintended consequences
>, potentially
>introducing new bugs; thus, a code freeze helps ensure that a portion of
>the program that is known to work correctly will continue to do so. Code
>freezes are often employed in the final stages of development, when a
>particular release or iteration is being tested, but may also be used to
>prevent changes to one portion of a program while another is undergoing
>development.
>
> Cheers,
> Peter
>
> On Wed, Oct 31, 2018 at 6:32 AM Mathieu Pellerin 
> wrote:
>
>> That's rather unfortunate, but most probably needed. The issue raised,
>> 20262, affects WMS(T), XYZ, WFS, etc. layers.
>>
>> On top of - and very much due to - the gravity of the bug itself, 3.4 is
>> flagged as LTR, and it'd be most appropriate to insure that people jumping
>> onto this new LTR aren't left with a bad first impression.
>>
>> Math
>>
>>
>>
>>
>> On Wed, Oct 31, 2018 at 8:55 AM Nyall Dawson 
>> wrote:
>>
>>> Bah... feels like every major release someone ends up sending an email
>>> like this... but in this case, https://issues.qgis.org/issues/20262
>>> has totally destroyed QGIS network based providers with Qt 5.11 and
>>> above.
>>>
>>> This is not anyone's fault -- it's an upstream change in the Qt
>>> library which changed some behavior we relied on. Not there fault, not
>>> our fault. But end result is that it makes QGIS basically unusable for
>>> any non gdal/ogr layers on Qt >= 5.11. And unfortunately our major
>>> platforms only saw an upgrade to Qt 5.11 late in the bug fixing
>>> period, which made this one slow to be identified.
>>>
>>> https://github.com/qgis/QGIS/pull/8383 should fix it.
>>>
>>> Soo could we break the normal cycle and get a point release out
>>> quickly? (Ideally with a couple of days prenotice so that anyone else
>>> working on urgent bug fixes could get them in too)
>>>
>>> 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 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

[QGIS-Developer] Plugin [1399] Physiocap3 approval notification.

[noreply]

Plugin Physiocap3 approval by pcav.
The plugin version "[1399] Physiocap3 3.4.0" is now approved
Link: http://plugins.qgis.org/plugins/Physiocap3/
___
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 [412] Qgis2threejs approval notification.

[noreply]

Plugin Qgis2threejs approval by pcav.
The plugin version "[412] Qgis2threejs 2.2" is now approved
Link: http://plugins.qgis.org/plugins/Qgis2threejs/
___
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 [1412] GeoDataFarm approval notification.

[noreply]

Plugin GeoDataFarm approval by pcav.
The plugin version "[1412] GeoDataFarm 2.0.2" is now approved
Link: http://plugins.qgis.org/plugins/geodatafarm/
___
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] Early 3.4 point release?

[Peter Petrik]

Hi,

> Bah... feels like *every* major release someone ends up sending an email
like this...

My opinion this may show a problem with our development cycle setup. In my
previous company, different closed-sourced software, we had so called code
freeze. For example it could be 1-2 weeks before actual release and ideally
some users would have time to test the "release-candidate" of QGIS before
going public.

>From wikipedia:

   - A *(complete) code freeze*, in which no changes whatsoever are
   permitted to a portion or the entirety of the program's source code.
   Particularly in large software systems, any change to the source code may
   have unintended consequences
   , potentially introducing
   new bugs; thus, a code freeze helps ensure that a portion of the program
   that is known to work correctly will continue to do so. Code freezes are
   often employed in the final stages of development, when a particular
   release or iteration is being tested, but may also be used to prevent
   changes to one portion of a program while another is undergoing development.

Cheers,
Peter

On Wed, Oct 31, 2018 at 6:32 AM Mathieu Pellerin 
wrote:

> That's rather unfortunate, but most probably needed. The issue raised,
> 20262, affects WMS(T), XYZ, WFS, etc. layers.
>
> On top of - and very much due to - the gravity of the bug itself, 3.4 is
> flagged as LTR, and it'd be most appropriate to insure that people jumping
> onto this new LTR aren't left with a bad first impression.
>
> Math
>
>
>
>
> On Wed, Oct 31, 2018 at 8:55 AM Nyall Dawson 
> wrote:
>
>> Bah... feels like every major release someone ends up sending an email
>> like this... but in this case, https://issues.qgis.org/issues/20262
>> has totally destroyed QGIS network based providers with Qt 5.11 and
>> above.
>>
>> This is not anyone's fault -- it's an upstream change in the Qt
>> library which changed some behavior we relied on. Not there fault, not
>> our fault. But end result is that it makes QGIS basically unusable for
>> any non gdal/ogr layers on Qt >= 5.11. And unfortunately our major
>> platforms only saw an upgrade to Qt 5.11 late in the bug fixing
>> period, which made this one slow to be identified.
>>
>> https://github.com/qgis/QGIS/pull/8383 should fix it.
>>
>> Soo could we break the normal cycle and get a point release out
>> quickly? (Ideally with a couple of days prenotice so that anyone else
>> working on urgent bug fixes could get them in too)
>>
>> 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 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