Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Nyall Dawson]

On Thu, 18 Nov 2021 at 04:46, Bo Victor Thomsen
 wrote:
>
> Hi list -
>
> I've summed up some ideas about have to handle the LTR situation.  The 
> policies is not carved in stone or complete but suggestions for a more stable 
> regime regarding LTR  (and they have probably already been mentioned 
> sometimes by someones before)
>
> However - Policy for LTR releases:
>
> At most one LTR release for every year.
>
> Point releases for LTR every 2 or 3 months.

I'm fine with these

> Point releases for LTR contains only security or bug patches. Never introduce 
> new functionality or change in the user interface ( Translation files might 
> be exempted from this rule)

That's already the rule which is in place. We also have an additional
rules that any non-crash fix, non-data corruption fixes have to go in
a delayed queue were they can only be included in the LTR after
they've been in a stable release for at least a month. (I.e. a fix
would have to be included in 3.22.1 so it gets once month of testing
before it's permitted into the 3.16.15 LTR patch release).

> The supporting libraries ( qt, proj, gdal, ogr etc. ) is covered by the same 
> rules. Only security or bug patches, never introduce newer major versions.
> Major changes in supporting libraries for non-LTR releases is restricted to 
> the release just after a LTR. Thus there will be 3 or more non-LTR releases 
> to stabilize QGIS before next LTR.

This is not so straightforward, for a couple of reasons:

1. QGIS is heavily tied to the underlying libraries, and often bugs
exposed in QGIS need fixes in GDAL/PROJ or GEOS. It would be
unfortunate if an LTR never gets a crash or data corruption fix
because that fix resides in a lower-level library. Similarly there's
situations where I think it IS important that a non-bug-fix library
update gets pushed to a stable release. For example, updates to the
PROJ projection libraries aren't backported to older PROJ releases. A
local agency may release a new local transformation or CRS and mandate
its use in a geographic area... and without a PROJ library update all
LTR users won't see the CRS updates until the next LTR major release.

2. It's not true that older libraries are inherently more stable than
newer library releases. Take the Qt library for example -- sticking
with an older Qt release just means that you're running an older,
unsupported library. There's no bug fixes or maintenance at all for
the older releases, and the ONLY way to get bugfixes from Qt is to
update to the latest major release. (Basically we're trading one set
of older bugs for the risk of a different set of newer bugs! :P )

3. Sometimes library updates are just necessary to keep things running
without breakage. (Eg. when an older library stops working because
some certificate has expired or upstream URL has changed... we've seen
in the past a situation where python package installation was broken
for a time because we were using an older unmaintained Python library
version, and the only solution was to update the python library to fix
the broken package downloads)

So I'm personally -1 to this particular idea.

Nyall


>
>
> The general idea is that the QGIS release following a LTR is a "Big Bang" 
> release: Everything goes.
>
> The following non-LTR releases can introduce new functionality but no changes 
> in the supporting libraries (This rule could maybe be bend a little) . But 
> when you come around to the LTR release you deep-freeze any changes except 
> security- and bug correcting patches
>
>
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> Den 17-11-2021 kl. 08:27 skrev Luca Manganelli:
>
> > [... ]
>
> As an IT administrator in our public organization, I confess that I have 
> packaged and distributed to all PCs the (old) 3.16.4 version. Why? Because 
> with this version there are 0 problems among users and with our customized 
> plugins.
>
> Before the 3.16 release, the other 3.x versions were a disaster, many things 
> didn't work, so before this 3.16, I had distributed 2.x to many users and 
> 3.12 to only few PCs.
>
> In a big organization the most important thing is not, "strangely", the more 
> features a piece of a software has, but the ... stability. Remember that 
> every worker wants a product that... works.
>
> And, the upgrade. The QGIS package is big (the archive is over 320MB) and we 
> have many offices in slw networks (2M ADSL... don't laugh, this is the 
> situ
>
>
>
>
>
>
>
>
>
> 
>
> Comune di Trento
>
> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>
> tel. +39 0461.884111 | www.comune.trento.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-Develope

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Bo Victor Thomsen]

However, you can control the versions of the supporting libraries /in/ 
OSGeo4W ?


It's mostly the Windows versions of QGIS we have problems with. And all 
the QGIS Windows versions is build using OSGeo4W ??


The policies is suggestions. For example: Change only QT from 5.x to 
5.x+1 just /after/ a LTR release, not just /before/. That would give us 
a year to fix the possibly bad consequences of the version change


Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 17-11-2021 kl. 19:54 skrev Sebastiaan Couwenberg:

On 11/17/21 19:45, Bo Victor Thomsen wrote:

  * The supporting libraries ( qt, proj, gdal, ogr etc. ) is covered by
    the same rules. Only security or bug patches, never introduce newer
    major versions.


You don't control the dependencies outside OSGeo4W, so this is not 
going to fly.


Kind Regards,

Bas
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Sebastiaan Couwenberg]

On 11/17/21 19:45, Bo Victor Thomsen wrote:

  * The supporting libraries ( qt, proj, gdal, ogr etc. ) is covered by
    the same rules. Only security or bug patches, never introduce newer
    major versions.


You don't control the dependencies outside OSGeo4W, so this is not going 
to fly.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[C Hamilton]

+1 you concisely expressed my thoughts about this.

Calvin

On Wed, Nov 17, 2021 at 1:45 PM Bo Victor Thomsen <
bo.victor.thom...@gmail.com> wrote:

> Hi list -
>
> I've summed up some ideas about have to handle the LTR situation.  The
> policies is not carved in stone or complete but suggestions for a more
> stable regime regarding LTR  (and they have probably already been mentioned
> sometimes by someones before)
>
> However - Policy for LTR releases:
>
>- At most one LTR release for every year.
>
>- Point releases for LTR every 2 or 3 months.
>
>- Point releases for LTR contains only security or bug patches. Never
>introduce new functionality or change in the user interface ( Translation
>files might be exempted from this rule)
>
>- The supporting libraries ( qt, proj, gdal, ogr etc. ) is covered by
>the same rules. Only security or bug patches, never introduce newer major
>versions.
>
>- Major changes in supporting libraries for non-LTR releases is
>restricted to the release just after a LTR. Thus there will be 3 or more
>non-LTR releases to stabilize QGIS before next LTR.
>
>
> The general idea is that the QGIS release following a LTR is a "Big Bang"
> release: Everything goes.
>
> The following non-LTR releases can introduce new functionality but no
> changes in the supporting libraries (This rule could maybe be bend a
> little) . But when you come around to the LTR release you deep-freeze any
> changes except security- and bug correcting patches
>
>
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> Den 17-11-2021 kl. 08:27 skrev Luca Manganelli:
>
> > [... ]
>
> As an IT administrator in our public organization, I confess that I have
> packaged and distributed to all PCs the (old) 3.16.4 version. Why? Because
> with this version there are 0 problems among users and with our customized
> plugins.
>
> Before the 3.16 release, the other 3.x versions were a disaster, many
> things didn't work, so before this 3.16, I had distributed 2.x to many
> users and 3.12 to only few PCs.
>
> In a big organization the most important thing is not, "strangely", the
> more features a piece of a software has, but the ... stability. Remember
> that every worker wants a product that... works.
>
> And, the upgrade. The QGIS package is big (the archive is over 320MB) and
> we have many offices in slw networks (2M ADSL... don't laugh, this is
> the situ
>
>
>
>
>
>
>
>
>
> --
>
> Comune di Trento
>
> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>
> tel. +39 0461.884111 | www.comune.trento.it
>
> ___
> 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
>
> ___
> 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-psc] QGIS LTR releases -- is it time to pull the plug?

[Bo Victor Thomsen]

Hi list -

I've summed up some ideas about have to handle the LTR situation.  The 
policies is not carved in stone or complete but suggestions for a more 
stable regime regarding LTR  (and they have probably already been 
mentioned sometimes by someones before)


However - Policy for LTR releases:

 * At most one LTR release for every year.

 * Point releases for LTR every 2 or 3 months.

 * Point releases for LTR contains only security or bug patches. Never
   introduce new functionality or change in the user interface (
   Translation files might be exempted from this rule)

 * The supporting libraries ( qt, proj, gdal, ogr etc. ) is covered by
   the same rules. Only security or bug patches, never introduce newer
   major versions.

 * Major changes in supporting libraries for non-LTR releases is
   restricted to the release just after a LTR. Thus there will be 3 or
   more non-LTR releases to stabilize QGIS before next LTR.


The general idea is that the QGIS release following a LTR is a "Big 
Bang" release: Everything goes.


The following non-LTR releases can introduce new functionality but no 
changes in the supporting libraries (This rule could maybe be bend a 
little) . But when you come around to the LTR release you deep-freeze 
any changes except security- and bug correcting patches



Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 17-11-2021 kl. 08:27 skrev Luca Manganelli:

> [... ]

As an IT administrator in our public organization, I confess that I 
have packaged and distributed to all PCs the (old) 3.16.4 version. 
Why? Because with this version there are 0 problems among users and 
with our customized plugins.


Before the 3.16 release, the other 3.x versions were a disaster, many 
things didn't work, so before this 3.16, I had distributed 2.x to many 
users and 3.12 to only few PCs.


In a big organization the most important thing is not, "strangely", 
the more features a piece of a software has, but the ... stability. 
Remember that every worker wants a product that... works.


And, the upgrade. The QGIS package is big (the archive is over 320MB) 
and we have many offices in slw networks (2M ADSL... don't laugh, 
this is the situ














Comune di Trento

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

tel. +39 0461.884111 | www.comune.trento.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] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Luca Manganelli]

> [... ]

As an IT administrator in our public organization, I confess that I have
packaged and distributed to all PCs the (old) 3.16.4 version. Why? Because
with this version there are 0 problems among users and with our customized
plugins.

Before the 3.16 release, the other 3.x versions were a disaster, many
things didn't work, so before this 3.16, I had distributed 2.x to many
users and 3.12 to only few PCs.

In a big organization the most important thing is not, "strangely", the
more features a piece of a software has, but the ... stability. Remember
that every worker wants a product that... works.

And, the upgrade. The QGIS package is big (the archive is over 320MB) and
we have many offices in slw networks (2M ADSL... don't laugh, this is
the situ

-- 





Comune di Trento 

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

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


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Greg Troxel]

Jürgen E. Fischer  writes:

> Hi Bo,
>
> On Tue, 16. Nov 2021 at 18:41:31 +0100, Bo Victor Thomsen wrote:
>> So yes, the LTR point releases are used. Not all point releases will be
>> installed every time, but some will.
>
> So you could agree that a monthly frequency it to high and a point release
> every two or three month could suffice?

From my view as a user and packaging in pkgsrc, every 2 or 3 months is
fine, especially if there haven't been any serious bugs.

My experience has been that the LTR point releases have all been totally
boring from a packaging/install point of view, which is good.  But I'm
just using the source tarballs, and my doing an update of qgis to a new
point LTR does not cause changes in dependencies.




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-psc] QGIS LTR releases -- is it time to pull the plug?

[Nyall Dawson]

On Tue, 16 Nov 2021 at 21:00, Bo Victor Thomsen
 wrote:
>

> Whatever that's decided regarding the LTR, I personally still will be a 
> staunch supporter of QGIS. But please don't throw the baby out with the 
> bathwater without due consideration and without trying alternative solutions.

Just to clarify: my personal view is also that the LTR is extremely
important for QGIS, especially for enterprise deployments of QGIS. I'd
hate to see it go! I also realise that providing the LTR comes with an
implicit promise of stability... every regression in the LTR hurts our
users, and a release-breaking bug this late in the LTR cycle is a
clear indication that something is wrong and we need to fix our
processes.

In short, I'm personally hoping that the conversation stays
constructive and that the outcome is a better-supported, more
trustworthy LTR release. (Again, my personal view is that we won't be
able to achieve this without a funding drive to start paying the
packagers/maintainers/QA teams to ensure that LTR releases aren't just
a "side thing" for them, but something which is always prioritised and
financially justified!)

Nyall

>
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> Den 16-11-2021 kl. 09:22 skrev Alessandro Pasotti:
>
>
> On Tue, Nov 16, 2021 at 8:50 AM Marco Bernasocchi  wrote:
>>
>> Hi Anita, Hi Nyall, Hi All
>> I think that it is a good idea to allocate the first half hour (and more if 
>> needed) in tonight's budget meeting to this very pressing subject.
>> Nyall, thanks a lot for your analysis, we'll use it as discussion base.
>>
>> I extended the meeting invitation from 18:00 to 19:30.
>>
>> See you later
>> Marco
>>
>>
>
> Hi,
>
> thinking about how to possibly prevent this to happen again I think that the 
> manual testing cycles as proposed with 
> https://lists.osgeo.org/pipermail/qgis-psc/2020-December/009186.html could 
> help in identifying biggest issues before a release.
>
> I think we should consider the possibility of investing in that direction.
>
> Kind regards.
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> 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-psc] QGIS LTR releases -- is it time to pull the plug?

[Bo Victor Thomsen]

Hi Jürgen -

So reduce the total number of point releases in the lifetime of a LTR  
from ca. 16 to somewhere between 6 or 8 point releases ?


That would be fine for me at least.

I don't think it would disrupt that many update schedules. I never 
experienced a single department that implemented every point release 
(including my own, when I was a GIS admin)


Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 16-11-2021 kl. 21:16 skrev Jürgen E. Fischer:

Hi Bo,

On Tue, 16. Nov 2021 at 18:41:31 +0100, Bo Victor Thomsen wrote:

So yes, the LTR point releases are used. Not all point releases will be
installed every time, but some will.

So you could agree that a monthly frequency it to high and a point release
every two or three month could suffice?


Jürgen



___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Jürgen E . Fischer]

Hi Calvin,

On Tue, 16. Nov 2021 at 15:27:06 -0500, C Hamilton wrote:
> I know this is a question for Bo, but thought I would respond as well.

Sure.  The more responses the better.


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-psc] QGIS LTR releases -- is it time to pull the plug?

[C Hamilton]

Jürgen,

I know this is a question for Bo, but thought I would respond as well.
Since we only update QGIS LTR perhaps 1 to 3 times during the lifetime of a
LTR, we do not need monthly LTR releases. The only reason we might update
sooner is if there is a bug found that impacts our users. The latest
release probably needs to be updated monthly.

On Tue, Nov 16, 2021 at 3:16 PM Jürgen E. Fischer  wrote:

> Hi Bo,
>
> On Tue, 16. Nov 2021 at 18:41:31 +0100, Bo Victor Thomsen wrote:
> > So yes, the LTR point releases are used. Not all point releases will be
> > installed every time, but some will.
>
> So you could agree that a monthly frequency it to high and a point release
> every two or three month could suffice?
>
>
> 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
> https://www.norbit.de
> QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC
> ___
> 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-psc] QGIS LTR releases -- is it time to pull the plug?

[Jürgen E . Fischer]

Hi Bo,

On Tue, 16. Nov 2021 at 18:41:31 +0100, Bo Victor Thomsen wrote:
> So yes, the LTR point releases are used. Not all point releases will be
> installed every time, but some will.

So you could agree that a monthly frequency it to high and a point release
every two or three month could suffice?


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
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher 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] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Bo Victor Thomsen]

Hi Jürgen -

Let me clarify (and make some pretty hefty generalisations, so apologies 
beforehand to any IT admin on the list)  -


 * IT admins don't like to make "new" versions 3.16, 3.18 and
   especially not every 4 months. It's a bother to make a new package
   from scratch; to register it in whatever installation/upgrade system
   they have and start some automatic or manual roll-out.

 * But most IT admins can make a "point" upgrade like 3.16.11 ->
   3.16.12, because they don't need to do anything than "refreshing" an
   already existing package and push the button for an automatic
   roll-out. No extra administration.

 * They probably won't make an upgrade and roll-out for each and every
   minor point release, i.e. from 3.16.11 -> 3.16.12 but will wait for
   the GIS admin to come and ask for it.

 * Most will wait for a specific QGIS release to get the LTR
   designation and probably a point release or two after that and then
   make a new QGIS roll-out for the organisation at that point.
   Superstition maybe ?

 * And some don't give a flying fig and just package the first LTR
   version and never bother to upgrade this.

So yes, the LTR point releases are used. Not all point releases will be 
installed every time, but some will.


Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 16-11-2021 kl. 17:50 skrev Jürgen E. Fischer:

Hi Bo,

On Tue, 16. Nov 2021 at 12:00:07 +0100, Bo Victor Thomsen wrote:

* In my experience, the 1 - year period for LTR is the shortest period
   acceptable for organisations. They don't want to repackage QGIS every 6
   months and certainly not every 4 months. You might even let the period be
   1.5- 2 years instead of 1 year.

Hm, but that contradicts the point of the LTR, doesn't it?

The LTR is about maintaining a branch for a year - and issuing a point release
every month with fixes - and not about getting the first release of the LTR
right (or the first after four month of the new LTR also beeing the current
release) and then sticking with that for a year.

If the point releases are not used anyway, there isn't any issue now.
Otherwise there should be repacking each month.

One point of the OSGeo4W update was also updating all dependencies - because
the previous one had some vulnerabilities - which also worries some
organizations - even if probably most - if not all - of them don't do any harm
if used from within QGIS.

Keeping the old versions, but still backporting fixes to everything those would
be another extra level of work.

Did we have any issues that were introduced by the actual new versions
themselves?  I guess most were "just" packaging issues.

BTW we're not relying on fixed version (number)s on other platforms than
Windows either.


Jürgen


___
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-psc] QGIS LTR releases -- is it time to pull the plug?

[Jürgen E . Fischer]

Hi Bo,

On Tue, 16. Nov 2021 at 12:00:07 +0100, Bo Victor Thomsen wrote:
> * In my experience, the 1 - year period for LTR is the shortest period
>   acceptable for organisations. They don't want to repackage QGIS every 6
>   months and certainly not every 4 months. You might even let the period be
>   1.5- 2 years instead of 1 year.

Hm, but that contradicts the point of the LTR, doesn't it?

The LTR is about maintaining a branch for a year - and issuing a point release
every month with fixes - and not about getting the first release of the LTR
right (or the first after four month of the new LTR also beeing the current
release) and then sticking with that for a year.

If the point releases are not used anyway, there isn't any issue now.
Otherwise there should be repacking each month.

One point of the OSGeo4W update was also updating all dependencies - because
the previous one had some vulnerabilities - which also worries some
organizations - even if probably most - if not all - of them don't do any harm
if used from within QGIS.

Keeping the old versions, but still backporting fixes to everything those would
be another extra level of work.

Did we have any issues that were introduced by the actual new versions
themselves?  I guess most were "just" packaging issues.

BTW we're not relying on fixed version (number)s on other platforms than
Windows either.


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-psc] QGIS LTR releases -- is it time to pull the plug?

[C Hamilton]

Hi Everyone,

For the US Federal government, we normally use the LTR version and IT does
not like us updating more than about twice a year. There are a few of us
such as myself who are testing and trying out the new features so we
install the latest version. For the LTR version we usually install around
3.x.8 and then around the end before the next version bump. It is very
important that the LTR version remains stable because if not it adds fuel
to those who only want a certain vendor as a reason to not use QGIS.
Analysts are also not happy if the software crashes and they lose their
work. We try to keep them happy. When it is getting time to update our
versions of QGIS, I usually wait two or three week after a release before I
recommend the new version. This helps to avoid problems like this. I also
never have 3.x.0 versions for the latest QGIS installed for this same
reason. I want to make sure there is some stability.

We normally only use the stand alone versions of the software - not the
network installer.

Anyway the LTR is important but it should only be updated with bug fixes.
The dependent libraries shouldn't be updated unless there is a bug in the
library. We do not need monthly updates to the software, but others may
want those monthly updates in case they are affected by some bug.

Thank you for all you do for the QGIS community!

Calvin



On Tue, Nov 16, 2021 at 7:10 AM Andreas Neumann  wrote:

> Hi all,
>
> Thank you Bo for this extensive summary of reasons why we should keep the
> LTR version.
>
> I can only second that - from the perspective of being employed at a
> public organization myself - and from the perspective of I believe the
> majority of the Swiss QGIS users. The LTR version is certainly a success in
> general and it is what most users want.
>
> Let's rather fix the issues in the LTR release process rather than killing
> it off because we sometimes run into troubles with it.
>
> We should also think about all the good things that the LTR version
> provided to the QGIS users (in general it brought a lot of stability and
> increased reliability). Shit happens sometimes (like now) - and from every
> problem we should take the opportunity to potentially improve our project.
>
> Andreas
>
> On 2021-11-16 12:00, Bo Victor Thomsen wrote:
>
> Hi all -
>
> I have a few comments  regarding the possible removal of the "QGIS LTR
> versions" ( as one of the original proponents for having a LTR version ) :
>
>- The LTR version is the version that almost *all* QGIS-using
>*organisations* in Denmark is using. That means 40 - 50 % of all
>municipalities, regions (counties) and a number of state departments. And a
>lot of private companies too.  They use it mostly in conjunction with some
>kind of "Web GIS" and have QGIS for the hard and complex stuff. This market
>penetration is on par with ESRI and better than MapInfo. As a treasurer of
>the QGIS Denmark User group I've registered 85 Danish organisational
>members out of 260 members. And this number is growing. So there is a large
>and growing number of QGIS users, that prefer the  LTR version (actually
>the vast majority if you count the individual users in the organisations) .
>The yearly fee from these organisational members is in large part the
>reason why QGIS Denmark has a Gold sponsorship of QGIS.
>
>I don't know about other countries, but I *guess, *that preferences in
>organisations is roughly the same: They prefer stability and as few errors
>as possible. And thirdly new glitzy features
>
>- I we ditch the LTR versions,  I fear that an old nemesis will
>resurface: That there is not *any *version of QGIS that is really
>stable:  A small irritating bug in ver. x will be solved in ver. x+1.
>However ver. x+1 contains another small irritating bug, that will be solved
>in version x+2 
>
>I know that the development process for QGIS has evolved tremendously
>the last couple of years. However, I still remember the "bad old days" with
>"no responsibility" for killing bugs in existing code caused by
>introduction of new code.
>
>- In my experience, the 1 - year period for LTR is the shortest period
>acceptable for organisations. They don't want to repackage QGIS every 6
>months and certainly not every 4 months. You might even let the period be
>1.5- 2 years instead of 1 year.
>
>- The quagmire of ver. 3.16... Isn't it a combination of a relatively
>old version of QGIS fine tuned to a set of support libraries, where the
>support libraries gets upgraded "an masse" because OsGeo4W gets upgraded
>from v1 to v2.; SIP gets upgraded from v4 to v6. And the proj library goes
>through several upgrades from v4 to v8 ? I my perspective that's a receipt
>for "The perfect storm". If it can't be fixed, then freeze it at 3.16.11
>and fast-promote ver. 3.22 as LTR, perhaps with a big warning sign on it.
>This it n

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Jürgen E . Fischer]

Hi Matthias,

On Tue, 16. Nov 2021 at 12:02:36 +0100, Matthias Kuhn wrote:
> I am very much in favor of evaluating what went wrong and drafting possible
> next steps to improve the situation.

Well, from my point of view there were a few updates late in the release that
started it.

OSGeo4W was using SIP 5 what was capabable of building the releases and master
- as long as both were using SIP's old build build system.  But that was
discontinued with SIP 6.

So for distributions that only have SIP 6 QGIS's support of that had to added -
and was (thanks Sandro).   But that broke the master build in OSGeo4W.   To
address that I updated OSGeo4W to SIP 6 - which in turn - but not unexpectedly
- broke the LTR build.

But there was still enough time to work on that before the release.  And I did
so by backporting the QGIS' SIP6 support of 3.22 to 3.16 - which apparently
worked as good as it was in 3.22.  What I didn't know was that it wasn't
working well on 3.22 either.  And it took a week after the release to become
clear.  Still there were only few - if any -windows nightlies right before the
release to test.

In the week before the release there also was another big change in master's
SIP, that wasn't working on (the native MSVC) windows build at all and took
some discussion to resolve and revert.   That took away more preparation time.
But still not enough to make the release impossible.

Meanwhile PROJ 8.2 was released and GDAL 3.4 was in sight.   After the release
I started working on those updates.

When the SIP issues became apparent after the release, I applied the quick fix
(thanks Sandro) to the OSGeo4W qgis packages and quickly made a new MSI of
3.16.12.

After some more discussion we decided to better do a 3.16.13 release.  Not sure
if it also already applied to the 3.16.12-2 MSI, but the 3.16.13 MSI was
already built with PROJ 8.2 although the rest of OSGeo4W was still using 8.1.
Not sure how that happened, but it did.

That is the apparent source of the new issue.   Those issues were resolved last
week in OSGeo4W - by rebuilding their reverse dependencies against PROJ 8.2 and
GDAL 3.4.  The MSI was not yet updated yet - mainly because the next release is
due friday anyway.

There were also issues with polish characters in the MSI, new GRASS packages
(7.8.6) somewhere in between (reintroducing the "untangle grass" issue) and new
GRASS packages in old OSGeo4W with a wrong set of VC libraries (also breaking 
the
old OSGeo4W LTR builds on release).  On Linux there was an issue with ubuntu
impish having SIP6 only and using a different compression (zstd) in the
packages - one that debian does (not yet?) use - so the build system there had
to be adapted to that.  Some taking several build iterations to unfold.

And there's also a subtle poppler/GDAL issue where some PDFs are not displayed
- which I also tried to figure out.  That's still there - everything will
hopefully solve itself with 3.16.14 (as it should be fine in OSGeo4W already).

So all in all many more unfortunate events than usual.



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
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher 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] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Andreas Neumann]

Hi all,

Thank you Bo for this extensive summary of reasons why we should keep 
the LTR version.


I can only second that - from the perspective of being employed at a 
public organization myself - and from the perspective of I believe the 
majority of the Swiss QGIS users. The LTR version is certainly a success 
in general and it is what most users want.


Let's rather fix the issues in the LTR release process rather than 
killing it off because we sometimes run into troubles with it.


We should also think about all the good things that the LTR version 
provided to the QGIS users (in general it brought a lot of stability and 
increased reliability). Shit happens sometimes (like now) - and from 
every problem we should take the opportunity to potentially improve our 
project.


Andreas

On 2021-11-16 12:00, Bo Victor Thomsen wrote:


Hi all -

I have a few comments  regarding the possible removal of the "QGIS LTR 
versions" ( as one of the original proponents for having a LTR version 
) :


* The LTR version is the version that almost _all_ QGIS-using 
_organisations_ in Denmark is using. That means 40 - 50 % of all 
municipalities, regions (counties) and a number of state departments. 
And a lot of private companies too.  They use it mostly in conjunction 
with some kind of "Web GIS" and have QGIS for the hard and complex 
stuff. This market penetration is on par with ESRI and better than 
MapInfo. As a treasurer of the QGIS Denmark User group I've registered 
85 Danish organisational members out of 260 members. And this number is 
growing. So there is a large and growing number of QGIS users, that 
prefer the  LTR version (actually the vast majority if you count the 
individual users in the organisations) .
The yearly fee from these organisational members is in large part the 
reason why QGIS Denmark has a Gold sponsorship of QGIS.


I don't know about other countries, but I _guess, _that preferences in 
organisations is roughly the same: They prefer stability and as few 
errors as possible. And thirdly new glitzy features


* I we ditch the LTR versions,  I fear that an old nemesis will 
resurface: That there is not _any _version of QGIS that is really 
stable:  A small irritating bug in ver. x will be solved in ver. x+1. 
However ver. x+1 contains another small irritating bug, that will be 
solved in version x+2 


I know that the development process for QGIS has evolved tremendously 
the last couple of years. However, I still remember the "bad old days" 
with "no responsibility" for killing bugs in existing code caused by 
introduction of new code.


* In my experience, the 1 - year period for LTR is the shortest period 
acceptable for organisations. They don't want to repackage QGIS every 6 
months and certainly not every 4 months. You might even let the period 
be 1.5- 2 years instead of 1 year.


* The quagmire of ver. 3.16... Isn't it a combination of a relatively 
old version of QGIS fine tuned to a set of support libraries, where the 
support libraries gets upgraded "an masse" because OsGeo4W gets 
upgraded from v1 to v2.; SIP gets upgraded from v4 to v6. And the proj 
library goes through several upgrades from v4 to v8 ? I my perspective 
that's a receipt for "The perfect storm". If it can't be fixed, then 
freeze it at 3.16.11 and fast-promote ver. 3.22 as LTR, perhaps with a 
big warning sign on it.
This it not a critique of the upgrade process. Every piece of software, 
including supporting libraries has to be upgraded from time to time. 
However I count 3 major upgrades of libraries on the same time
NB! Just read Jürgen's posting on ver. 3.16.14 being released on  
friday. If it works, then that's solves the ver. 3.16 issues for me.


* I know, bug squashing is nobody's favourite programming discipline. 
Especially if you not are paid for doing it. Hence the need for bug 
squashin by payment. So what about trying to reach out to the large (or 
small) sponsors and ask them if they could put some extra coins in the 
pot earmarked for LTR ? I can't solely speak for QGIS Denmark User 
group, but I would certainly discuss this problem with other members of 
the board and eventually the general assembly. And we have some 
contacts with the other QGIS usergroups i Scandinavia. The Swiss 
usergroup could for example talk with the german usergroup (I know the 
problem is not based on language, but sometimes it's easier to promote 
an idea with people talking roughly the same language)


So how much money are we talking about ?

Whatever that's decided regarding the LTR, I personally still will be a 
staunch supporter of QGIS. But please don't throw the baby out with the 
bathwater without due consideration and without trying alternative 
solutions.


Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 16-11-2021 kl. 09:22 skrev Alessandro Pasotti:

On Tue, Nov 16, 2021 at 8:50 AM Marco Bernasocchi  
wrote:

Hi Anita, Hi Nyall, Hi All
I think that it is a good idea to allocate the first ha

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Nick Bearman]

+1 To everything Bo Victor says, thanks for covering everything I wanted 
to say!


In training / education / teaching (in my experience) materials are 
usually written for the latest LTR versions, so they don't need to be 
updated too frequently.


Best wishes,
Nick.

On 16/11/2021 11:00, Bo Victor Thomsen wrote:


Hi all -

I have a few comments  regarding the possible removal of the "QGIS LTR 
versions" ( as one of the original proponents for having a LTR version ) :


  * The LTR version is the version that almost /all/ QGIS-using
/organisations/ in Denmark is using. That means 40 - 50 % of all
municipalities, regions (counties) and a number of state
departments. And a lot of private companies too.  They use it
mostly in conjunction with some kind of "Web GIS" and have QGIS
for the hard and complex stuff. This market penetration is on par
with ESRI and better than MapInfo. As a treasurer of the QGIS
Denmark User group I've registered 85 Danish organisational
members out of 260 members. And this number is growing. So there
is a large and growing number of QGIS users, that prefer the  LTR
version (actually the vast majority if you count the individual
users in the organisations) .
The yearly fee from these organisational members is in large part
the reason why QGIS Denmark has a Gold sponsorship of QGIS.

I don't know about other countries, but I /guess, /that
preferences in organisations is roughly the same: They prefer
stability and as few errors as possible. And thirdly new glitzy
features

  * I we ditch the LTR versions,  I fear that an old nemesis will
resurface: That there is not /any /version of QGIS that is really
stable:  A small irritating bug in ver. x will be solved in ver.
x+1. However ver. x+1 contains another small irritating bug, that
will be solved in version x+2 

I know that the development process for QGIS has evolved
tremendously the last couple of years. However, I still remember
the "bad old days" with "no responsibility" for killing bugs in
existing code caused by introduction of new code.

  * In my experience, the 1 - year period for LTR is the shortest
period acceptable for organisations. They don't want to repackage
QGIS every 6 months and certainly not every 4 months. You might
even let the period be 1.5- 2 years instead of 1 year.

  * The quagmire of ver. 3.16... Isn't it a combination of a
relatively old version of QGIS fine tuned to a set of support
libraries, where the support libraries gets upgraded "an masse"
because OsGeo4W gets upgraded from v1 to v2.; SIP gets upgraded
from v4 to v6. And the proj library goes through several upgrades
from v4 to v8 ? I my perspective that's a receipt for "The perfect
storm". If it can't be fixed, then freeze it at 3.16.11 and
fast-promote ver. 3.22 as LTR, perhaps with a big warning sign on it.
This it not a critique of the upgrade process. Every piece of
software, including supporting libraries has to be upgraded from
time to time. However I count 3 major upgrades of libraries on the
same time
NB! Just read Jürgen's posting on ver. 3.16.14 being released on 
friday. If it works, then that's solves the ver. 3.16 issues for me.

  * I know, bug squashing is nobody's favourite programming
discipline. Especially if you not are paid for doing it. Hence the
need for bug squashin by payment. So what about trying to reach
out to the large (or small) sponsors and ask them if they could
put some extra coins in the pot earmarked for LTR ? I can't solely
speak for QGIS Denmark User group, but I would certainly discuss
this problem with other members of the board and eventually the
general assembly. And we have some contacts with the other QGIS
usergroups i Scandinavia. The Swiss usergroup could for example
talk with the german usergroup (I know the problem is not based on
language, but sometimes it's easier to promote an idea with people
talking roughly the same language)

So how much money are we talking about ?

Whatever that's decided regarding the LTR, I personally still will be 
a staunch supporter of QGIS. But please don't throw the baby out with 
the bathwater without due consideration and without trying alternative 
solutions.


Med venlig hilsen / Kind regards

Bo Victor Thomsen
Den 16-11-2021 kl. 09:22 skrev Alessandro Pasotti:


On Tue, Nov 16, 2021 at 8:50 AM Marco Bernasocchi  wrote:

Hi Anita, Hi Nyall, Hi All
I think that it is a good idea to allocate the first half hour
(and more if needed) in tonight's budget meeting to this very
pressing subject.
Nyall, thanks a lot for your analysis, we'll use it as discussion
base.

I extended the meeting invitation from 18:00 to 19:30.

See you later
Marco



Hi,

thinking about how to possibly prevent this to happen again I think 
that the m

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Matthias Kuhn]

Hi all,

I am very much in favor of evaluating what went wrong and drafting possible
next steps to improve the situation.

Thank you Nyall for starting the discussion and insisting to get things
done. And thanks to the PSC and Marco for sending the information mail.

Some very good points have been made already. With respect to *testing*,
looking at the product as *source code plus the bundled libraries*, and
asserting that the LTR is something that we produce as *a service for
larger organizations that can and should take responsibility for its
maintenance*.

Best regards
Matthias

On Tue, Nov 16, 2021 at 11:03 AM Alexandre Neto 
wrote:

> Hello all,
>
> On Mon, Nov 15, 2021 at 9:09 PM Andreas Neumann  wrote:
>
>> - strictly separate the build systems and libraries of LTR and regular
>> releases. Parts of the problem stem from the fact that during the lifetime
>> of an LTR underlying libraries are updated. Ideally, the libraries of the
>> LT releases only receive bug fixes, but no new features
>> - put more resources into manual testing
>> - put more resources into packaging in general
>> - let every release be checked manually by a couple of dedicates power
>> users (at least the LTR ones) before it goes out to the public
>>
>> I know - all of these need personal/financial resources.
>>
>> Andreas
>>
>
> Since resources are limited, another thing we may consider is to reduce
> the number of releases per year.
> If on top of that, we could add a packaging freeze period, it would be
> possible to run installers' manual tests before they are released to the
> general public.
>
> Here are some test plans we prepared for QEP 180:
>
> https://qgis.tenant.kiwitcms.org/plan/search/
>
> These are only examples, we can think about more tests, especially things
> that can't be caught by CI.
>
> Best regards,
>
> Alexandre Neto
>
>
>
>> On Mon, 15 Nov 2021 at 20:57, Nyall Dawson 
>> wrote:
>>
>>> Hi lists,
>>>
>>> I'd like to start some conversation about the dire condition of the
>>> QGIS LTR release and what we can do to remedy/avoid this in future.
>>>
>>> If you've missed the conversation, our QGIS 3.16 windows releases have
>>> been completely broken for nearly a month now. 3.16.12 had a critical
>>> issue which caused lockups in Python code, and now 3.16.13 has
>>> completely broken projection handling (resulting in loss of CRS,
>>> hangups when opening projects, etc).
>>>
>>> So what do we do? I can think of a few responses we could make:
>>>
>>> - Kill 3.16.13 with fire. It needs to be removed from the website and
>>> all traces of the internet ASAP. Rollback to only offering 3.16.11,
>>> which is the last good Windows 3.16 release.
>>>
>>> - Put out a massive apology (and ask users to step up their funding to
>>> better maintain QGIS releases in future ;)
>>>
>>> - Mark 3.16 as an early EOL. (I can't see anyone interested in
>>> resolving the actual issue, so we've no way forward here in releasing
>>> a "good" 3.16 release again.)
>>>
>>> - Write the LTR releases off as a failed concept. (i.e. if we don't
>>> have the resources to maintain them properly, we shouldn't be offering
>>> them at all and should resort back to the single maintained release at
>>> any one time situation.)
>>>
>>> - Lower the supported period of a LTR release to 6 months?
>>>
>>> - Offer "theoretical" LTR releases ONLY as source code, but leave it
>>> to users to compile themselves and accept responsibility for their own
>>> packaging of this release.
>>>
>>> - Go on a funding drive so that QGIS can **pay** a developer and
>>> packager so that we actually CAN say we have stable LTR releases
>>> again?
>>>
>>> - ...something else...?
>>>
>>> Suffice to say, these are big issues, with big responses. But we're
>>> also under extreme time pressure here -- 3.16 is broken beyond belief,
>>> and we DO need to make some public responses asap (i.e. TODAY)
>>>
>>> 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-psc mailing list
>> qgis-...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
> ___
> 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] QGIS LTR releases -- is it time to pull the plug?

[Bo Victor Thomsen]

Hi all -

I have a few comments  regarding the possible removal of the "QGIS LTR 
versions" ( as one of the original proponents for having a LTR version ) :


 * The LTR version is the version that almost /all/ QGIS-using
   /organisations/ in Denmark is using. That means 40 - 50 % of all
   municipalities, regions (counties) and a number of state
   departments. And a lot of private companies too.  They use it mostly
   in conjunction with some kind of "Web GIS" and have QGIS for the
   hard and complex stuff. This market penetration is on par with ESRI
   and better than MapInfo. As a treasurer of the QGIS Denmark User
   group I've registered 85 Danish organisational members out of 260
   members. And this number is growing. So there is a large and growing
   number of QGIS users, that prefer the  LTR version (actually the
   vast majority if you count the individual users in the organisations) .
   The yearly fee from these organisational members is in large part
   the reason why QGIS Denmark has a Gold sponsorship of QGIS.

   I don't know about other countries, but I /guess, /that preferences
   in organisations is roughly the same: They prefer stability and as
   few errors as possible. And thirdly new glitzy features

 * I we ditch the LTR versions,  I fear that an old nemesis will
   resurface: That there is not /any /version of QGIS that is really
   stable:  A small irritating bug in ver. x will be solved in ver.
   x+1. However ver. x+1 contains another small irritating bug, that
   will be solved in version x+2 

   I know that the development process for QGIS has evolved
   tremendously the last couple of years. However, I still remember the
   "bad old days" with "no responsibility" for killing bugs in existing
   code caused by introduction of new code.

 * In my experience, the 1 - year period for LTR is the shortest period
   acceptable for organisations. They don't want to repackage QGIS
   every 6 months and certainly not every 4 months. You might even let
   the period be 1.5- 2 years instead of 1 year.

 * The quagmire of ver. 3.16... Isn't it a combination of a relatively
   old version of QGIS fine tuned to a set of support libraries, where
   the support libraries gets upgraded "an masse" because OsGeo4W gets
   upgraded from v1 to v2.; SIP gets upgraded from v4 to v6. And the
   proj library goes through several upgrades from v4 to v8 ? I my
   perspective that's a receipt for "The perfect storm". If it can't be
   fixed, then freeze it at 3.16.11 and fast-promote ver. 3.22 as LTR,
   perhaps with a big warning sign on it.
   This it not a critique of the upgrade process. Every piece of
   software, including supporting libraries has to be upgraded from
   time to time. However I count 3 major upgrades of libraries on the
   same time
   NB! Just read Jürgen's posting on ver. 3.16.14 being released on 
   friday. If it works, then that's solves the ver. 3.16 issues for me.

 * I know, bug squashing is nobody's favourite programming discipline.
   Especially if you not are paid for doing it. Hence the need for bug
   squashin by payment. So what about trying to reach out to the large
   (or small) sponsors and ask them if they could put some extra coins
   in the pot earmarked for LTR ? I can't solely speak for QGIS Denmark
   User group, but I would certainly discuss this problem with other
   members of the board and eventually the general assembly. And we
   have some contacts with the other QGIS usergroups i Scandinavia. The
   Swiss usergroup could for example talk with the german usergroup (I
   know the problem is not based on language, but sometimes it's easier
   to promote an idea with people talking roughly the same language)

   So how much money are we talking about ?

Whatever that's decided regarding the LTR, I personally still will be a 
staunch supporter of QGIS. But please don't throw the baby out with the 
bathwater without due consideration and without trying alternative 
solutions.


Med venlig hilsen / Kind regards

Bo Victor Thomsen

Den 16-11-2021 kl. 09:22 skrev Alessandro Pasotti:


On Tue, Nov 16, 2021 at 8:50 AM Marco Bernasocchi  wrote:

Hi Anita, Hi Nyall, Hi All
I think that it is a good idea to allocate the first half hour
(and more if needed) in tonight's budget meeting to this very
pressing subject.
Nyall, thanks a lot for your analysis, we'll use it as discussion
base.

I extended the meeting invitation from 18:00 to 19:30.

See you later
Marco



Hi,

thinking about how to possibly prevent this to happen again I think 
that the manual testing cycles as proposed with 
https://lists.osgeo.org/pipermail/qgis-psc/2020-December/009186.html 
could help in identifying biggest issues before a release.


I think we should consider the possibility of investing in that direction.

Kind regards.

--
Alessandro Pasotti
QCooperative: www.qcooperative.net 
ItOpen: www.itopen.it 

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Alexandre Neto]

Hello all,

On Mon, Nov 15, 2021 at 9:09 PM Andreas Neumann  wrote:

> - strictly separate the build systems and libraries of LTR and regular
> releases. Parts of the problem stem from the fact that during the lifetime
> of an LTR underlying libraries are updated. Ideally, the libraries of the
> LT releases only receive bug fixes, but no new features
> - put more resources into manual testing
> - put more resources into packaging in general
> - let every release be checked manually by a couple of dedicates power
> users (at least the LTR ones) before it goes out to the public
>
> I know - all of these need personal/financial resources.
>
> Andreas
>

Since resources are limited, another thing we may consider is to reduce the
number of releases per year.
If on top of that, we could add a packaging freeze period, it would be
possible to run installers' manual tests before they are released to the
general public.

Here are some test plans we prepared for QEP 180:

https://qgis.tenant.kiwitcms.org/plan/search/

These are only examples, we can think about more tests, especially things
that can't be caught by CI.

Best regards,

Alexandre Neto



> On Mon, 15 Nov 2021 at 20:57, Nyall Dawson  wrote:
>
>> Hi lists,
>>
>> I'd like to start some conversation about the dire condition of the
>> QGIS LTR release and what we can do to remedy/avoid this in future.
>>
>> If you've missed the conversation, our QGIS 3.16 windows releases have
>> been completely broken for nearly a month now. 3.16.12 had a critical
>> issue which caused lockups in Python code, and now 3.16.13 has
>> completely broken projection handling (resulting in loss of CRS,
>> hangups when opening projects, etc).
>>
>> So what do we do? I can think of a few responses we could make:
>>
>> - Kill 3.16.13 with fire. It needs to be removed from the website and
>> all traces of the internet ASAP. Rollback to only offering 3.16.11,
>> which is the last good Windows 3.16 release.
>>
>> - Put out a massive apology (and ask users to step up their funding to
>> better maintain QGIS releases in future ;)
>>
>> - Mark 3.16 as an early EOL. (I can't see anyone interested in
>> resolving the actual issue, so we've no way forward here in releasing
>> a "good" 3.16 release again.)
>>
>> - Write the LTR releases off as a failed concept. (i.e. if we don't
>> have the resources to maintain them properly, we shouldn't be offering
>> them at all and should resort back to the single maintained release at
>> any one time situation.)
>>
>> - Lower the supported period of a LTR release to 6 months?
>>
>> - Offer "theoretical" LTR releases ONLY as source code, but leave it
>> to users to compile themselves and accept responsibility for their own
>> packaging of this release.
>>
>> - Go on a funding drive so that QGIS can **pay** a developer and
>> packager so that we actually CAN say we have stable LTR releases
>> again?
>>
>> - ...something else...?
>>
>> Suffice to say, these are big issues, with big responses. But we're
>> also under extreme time pressure here -- 3.16 is broken beyond belief,
>> and we DO need to make some public responses asap (i.e. TODAY)
>>
>> 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-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] QGIS LTR releases -- is it time to pull the plug?

[Jürgen E . Fischer]

Hi,

On Tue, 16. Nov 2021 at 05:57:09 +1000, Nyall Dawson wrote:
> I'd like to start some conversation about the dire condition of the
> QGIS LTR release and what we can do to remedy/avoid this in future.
> 
> If you've missed the conversation, our QGIS 3.16 windows releases have
> been completely broken for nearly a month now. 3.16.12 had a critical
> issue which caused lockups in Python code, and now 3.16.13 has
> completely broken projection handling (resulting in loss of CRS,
> hangups when opening projects, etc).

Only the 3.16.13 MSI is broken (not sure if 3.16.12-2 is affected).   OSGeo4W
v2 was meanwhile fixed.   All other platforms are not affected at all.  The
next release is on friday and will also produce a fresh MSI.

I 'downgraded' the website to 3.16.11 and the website rebuild is ongoing.

Doing another MSI of 3.16.13 would be an option, but I guess as the 3.16.14 is
due on friday - it's probably good enough to just do that and sort it out
that way.

bbl.  Heading to the office now… 


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
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher 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] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Alessandro Pasotti]

On Tue, Nov 16, 2021 at 8:50 AM Marco Bernasocchi  wrote:

> Hi Anita, Hi Nyall, Hi All
> I think that it is a good idea to allocate the first half hour (and more
> if needed) in tonight's budget meeting to this very pressing subject.
> Nyall, thanks a lot for your analysis, we'll use it as discussion base.
>
> I extended the meeting invitation from 18:00 to 19:30.
>
> See you later
> Marco
>
>
>
Hi,

thinking about how to possibly prevent this to happen again I think that
the manual testing cycles as proposed with
https://lists.osgeo.org/pipermail/qgis-psc/2020-December/009186.html could
help in identifying biggest issues before a release.

I think we should consider the possibility of investing in that direction.

Kind regards.

-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Marco Bernasocchi]

Hi Anita, Hi Nyall, Hi All
I think that it is a good idea to allocate the first half hour (and more if
needed) in tonight's budget meeting to this very pressing subject.
Nyall, thanks a lot for your analysis, we'll use it as discussion base.

I extended the meeting invitation from 18:00 to 19:30.

See you later
Marco


On Mon, 15 Nov 2021 at 21:37, Anita Graser  wrote:

> Thank you Nyall for the candid assessment.
> I'm ready to help wherever I can, which most likely comes down to writing
> announcements.
> We had the budget meeting scheduled for Tuesday evening but it sounds like
> we should get on top of this issue asap.
>
> Regards
> Anita
>
> 15 Nov 2021 20:57:36 Nyall Dawson :
>
> > Hi lists,
> >
> > I'd like to start some conversation about the dire condition of the
> > QGIS LTR release and what we can do to remedy/avoid this in future.
> >
> > If you've missed the conversation, our QGIS 3.16 windows releases have
> > been completely broken for nearly a month now. 3.16.12 had a critical
> > issue which caused lockups in Python code, and now 3.16.13 has
> > completely broken projection handling (resulting in loss of CRS,
> > hangups when opening projects, etc).
> >
> > So what do we do? I can think of a few responses we could make:
> >
> > - Kill 3.16.13 with fire. It needs to be removed from the website and
> > all traces of the internet ASAP. Rollback to only offering 3.16.11,
> > which is the last good Windows 3.16 release.
> >
> > - Put out a massive apology (and ask users to step up their funding to
> > better maintain QGIS releases in future ;)
> >
> > - Mark 3.16 as an early EOL. (I can't see anyone interested in
> > resolving the actual issue, so we've no way forward here in releasing
> > a "good" 3.16 release again.)
> >
> > - Write the LTR releases off as a failed concept. (i.e. if we don't
> > have the resources to maintain them properly, we shouldn't be offering
> > them at all and should resort back to the single maintained release at
> > any one time situation.)
> >
> > - Lower the supported period of a LTR release to 6 months?
> >
> > - Offer "theoretical" LTR releases ONLY as source code, but leave it
> > to users to compile themselves and accept responsibility for their own
> > packaging of this release.
> >
> > - Go on a funding drive so that QGIS can **pay** a developer and
> > packager so that we actually CAN say we have stable LTR releases
> > again?
> >
> > - ...something else...?
> >
> > Suffice to say, these are big issues, with big responses. But we're
> > also under extreme time pressure here -- 3.16 is broken beyond belief,
> > and we DO need to make some public responses asap (i.e. TODAY)
> >
> > Nyall
> > ___
> > Qgis-psc mailing list
> > qgis-...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/qgis-psc
> ___
> Qgis-psc mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>


-- 
Marco Bernasocchi

QGIS.org Chair
OPENGIS.ch CEO
http://berna.io
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Marco Bernasocchi]

Hi All, I think the first and immediate action to take is to remove 3.16.13
from the website and create a blog post stating the rollback and an apology.

After that, we can analyse, think and communicate about the next action.

@Richard Duivenvoorde   if you want you can create a
PR and assign it to Jürgen and Me.

Cheers
Marco



On Tue, 16 Nov 2021 at 08:12, Anita Graser  wrote:

>
> On 16.11.2021 06:46, Richard Duivenvoorde wrote:
> > On 11/16/21 5:19 AM, Mathieu Pellerin wrote:
> >> Most urgently: we _absolutely_ need to stop advertising 3.16.13 LTR on
> the website and fallback to 3.16.11 for now; can someone with access to the
> website do that ASAP within the next 24 hours?
> > That is if I am correct (Juergen?) editing this file:
> > https://github.com/qgis/QGIS-Website/blob/master/source/schedule.py
> > and rebuild the websites...
> >
> > But I do not want to do this, as I think PSC or the package manager
> should decide.
> > Please let me know...
>
> I'm not sure if editing schedule.py is sufficient.
>
> On our other media, I've taken down the update announcement on
> https://blog.qgis.org.
>
> Regards,
>
> Anita
>
>
> ___
> Qgis-psc mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>


-- 
Marco Bernasocchi

QGIS.org Chair
OPENGIS.ch CEO
http://berna.io
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Anita Graser]

On 16.11.2021 06:46, Richard Duivenvoorde wrote:

On 11/16/21 5:19 AM, Mathieu Pellerin wrote:

Most urgently: we _absolutely_ need to stop advertising 3.16.13 LTR on the 
website and fallback to 3.16.11 for now; can someone with access to the website 
do that ASAP within the next 24 hours?

That is if I am correct (Juergen?) editing this file:
https://github.com/qgis/QGIS-Website/blob/master/source/schedule.py
and rebuild the websites...

But I do not want to do this, as I think PSC or the package manager should 
decide.
Please let me know...


I'm not sure if editing schedule.py is sufficient.

On our other media, I've taken down the update announcement on
https://blog.qgis.org.

Regards,

Anita


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Richard Duivenvoorde]

On 11/16/21 5:19 AM, Mathieu Pellerin wrote:
> Most urgently: we _absolutely_ need to stop advertising 3.16.13 LTR on the 
> website and fallback to 3.16.11 for now; can someone with access to the 
> website do that ASAP within the next 24 hours?

That is if I am correct (Juergen?) editing this file:
https://github.com/qgis/QGIS-Website/blob/master/source/schedule.py
and rebuild the websites...

But I do not want to do this, as I think PSC or the package manager should 
decide.
Please let me know...

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] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Mathieu Pellerin]

Big supportive +1 on looking back at what happened during this last month
with the LTR, draw some lessons and take remedial actions.

Most urgently: we _absolutely_ need to stop advertising 3.16.13 LTR on the
website and fallback to 3.16.11 for now; can someone with access to the
website do that ASAP within the next 24 hours?

Once that's done, we should prioritize time fixing the underlying issue,
and discuss how we as a project can avoid failing into this situation
again.

There areI IMHO two crucial points to look into:
- On the technical side, how can we strengthen the process around LTR
releases to avoid _as much as possible_ shipping "broken" releases.
- On the project management side, how can we avoid the perceived lack of
speedy, immediate response to a very serious issue. Shipping problematic
releases is something we obviously should aim at avoiding, but even with
improvements in place, it is bound to happen again. At bare minimum,
whenever a "black swan" incident happens, we should have mechanisms in
place to take bad releases off the website as soon as possible.





On Tue, Nov 16, 2021 at 2:57 AM Nyall Dawson  wrote:

> Hi lists,
>
> I'd like to start some conversation about the dire condition of the
> QGIS LTR release and what we can do to remedy/avoid this in future.
>
> If you've missed the conversation, our QGIS 3.16 windows releases have
> been completely broken for nearly a month now. 3.16.12 had a critical
> issue which caused lockups in Python code, and now 3.16.13 has
> completely broken projection handling (resulting in loss of CRS,
> hangups when opening projects, etc).
>
> So what do we do? I can think of a few responses we could make:
>
> - Kill 3.16.13 with fire. It needs to be removed from the website and
> all traces of the internet ASAP. Rollback to only offering 3.16.11,
> which is the last good Windows 3.16 release.
>
> - Put out a massive apology (and ask users to step up their funding to
> better maintain QGIS releases in future ;)
>
> - Mark 3.16 as an early EOL. (I can't see anyone interested in
> resolving the actual issue, so we've no way forward here in releasing
> a "good" 3.16 release again.)
>
> - Write the LTR releases off as a failed concept. (i.e. if we don't
> have the resources to maintain them properly, we shouldn't be offering
> them at all and should resort back to the single maintained release at
> any one time situation.)
>
> - Lower the supported period of a LTR release to 6 months?
>
> - Offer "theoretical" LTR releases ONLY as source code, but leave it
> to users to compile themselves and accept responsibility for their own
> packaging of this release.
>
> - Go on a funding drive so that QGIS can **pay** a developer and
> packager so that we actually CAN say we have stable LTR releases
> again?
>
> - ...something else...?
>
> Suffice to say, these are big issues, with big responses. But we're
> also under extreme time pressure here -- 3.16 is broken beyond belief,
> and we DO need to make some public responses asap (i.e. TODAY)
>
> Nyall
> ___
> 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] QGIS LTR releases -- is it time to pull the plug?

[Andreas Neumann]

Hi Nyall,

Thank you for the discussion.

Here are some additional ideas/options:

- strictly separate the build systems and libraries of LTR and regular
releases. Parts of the problem stem from the fact that during the lifetime
of an LTR underlying libraries are updated. Ideally, the libraries of the
LT releases only receive bug fixes, but no new features
- put more resources into manual testing
- put more resources into packaging in general
- let every release be checked manually by a couple of dedicates power
users (at least the LTR ones) before it goes out to the public

I know - all of these need personal/financial resources.

Andreas

On Mon, 15 Nov 2021 at 20:57, Nyall Dawson  wrote:

> Hi lists,
>
> I'd like to start some conversation about the dire condition of the
> QGIS LTR release and what we can do to remedy/avoid this in future.
>
> If you've missed the conversation, our QGIS 3.16 windows releases have
> been completely broken for nearly a month now. 3.16.12 had a critical
> issue which caused lockups in Python code, and now 3.16.13 has
> completely broken projection handling (resulting in loss of CRS,
> hangups when opening projects, etc).
>
> So what do we do? I can think of a few responses we could make:
>
> - Kill 3.16.13 with fire. It needs to be removed from the website and
> all traces of the internet ASAP. Rollback to only offering 3.16.11,
> which is the last good Windows 3.16 release.
>
> - Put out a massive apology (and ask users to step up their funding to
> better maintain QGIS releases in future ;)
>
> - Mark 3.16 as an early EOL. (I can't see anyone interested in
> resolving the actual issue, so we've no way forward here in releasing
> a "good" 3.16 release again.)
>
> - Write the LTR releases off as a failed concept. (i.e. if we don't
> have the resources to maintain them properly, we shouldn't be offering
> them at all and should resort back to the single maintained release at
> any one time situation.)
>
> - Lower the supported period of a LTR release to 6 months?
>
> - Offer "theoretical" LTR releases ONLY as source code, but leave it
> to users to compile themselves and accept responsibility for their own
> packaging of this release.
>
> - Go on a funding drive so that QGIS can **pay** a developer and
> packager so that we actually CAN say we have stable LTR releases
> again?
>
> - ...something else...?
>
> Suffice to say, these are big issues, with big responses. But we're
> also under extreme time pressure here -- 3.16 is broken beyond belief,
> and we DO need to make some public responses asap (i.e. TODAY)
>
> 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] [Qgis-psc] QGIS LTR releases -- is it time to pull the plug?

[Anita Graser]

Thank you Nyall for the candid assessment.
I'm ready to help wherever I can, which most likely comes down to writing 
announcements.
We had the budget meeting scheduled for Tuesday evening but it sounds like we 
should get on top of this issue asap.

Regards
Anita

15 Nov 2021 20:57:36 Nyall Dawson :

> Hi lists,
>
> I'd like to start some conversation about the dire condition of the
> QGIS LTR release and what we can do to remedy/avoid this in future.
>
> If you've missed the conversation, our QGIS 3.16 windows releases have
> been completely broken for nearly a month now. 3.16.12 had a critical
> issue which caused lockups in Python code, and now 3.16.13 has
> completely broken projection handling (resulting in loss of CRS,
> hangups when opening projects, etc).
>
> So what do we do? I can think of a few responses we could make:
>
> - Kill 3.16.13 with fire. It needs to be removed from the website and
> all traces of the internet ASAP. Rollback to only offering 3.16.11,
> which is the last good Windows 3.16 release.
>
> - Put out a massive apology (and ask users to step up their funding to
> better maintain QGIS releases in future ;)
>
> - Mark 3.16 as an early EOL. (I can't see anyone interested in
> resolving the actual issue, so we've no way forward here in releasing
> a "good" 3.16 release again.)
>
> - Write the LTR releases off as a failed concept. (i.e. if we don't
> have the resources to maintain them properly, we shouldn't be offering
> them at all and should resort back to the single maintained release at
> any one time situation.)
>
> - Lower the supported period of a LTR release to 6 months?
>
> - Offer "theoretical" LTR releases ONLY as source code, but leave it
> to users to compile themselves and accept responsibility for their own
> packaging of this release.
>
> - Go on a funding drive so that QGIS can **pay** a developer and
> packager so that we actually CAN say we have stable LTR releases
> again?
>
> - ...something else...?
>
> Suffice to say, these are big issues, with big responses. But we're
> also under extreme time pressure here -- 3.16 is broken beyond belief,
> and we DO need to make some public responses asap (i.e. TODAY)
>
> Nyall
> ___
> 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