Formal request to extend LTR life span to two years

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Formal request to extend LTR life span to two years

Andreas Neumann-3
Hi PSC,

My current employer, Kanton of Solothurn, gave me the task to submit a formal request to PSC for the extension of the life span of the LTR version from one year to two years.

Hence I am submitting this request now and would like to open the discussion (again). I know we had this discussion before and it was rejected due to limited resources.

A little bit of background: Kanton of Solothurn was one of the first customers of Sourcepole and back then, way before there was an LTR version, was one of the reasons why QGIS enterprise was introduced, because QGIS did not offer and LTR version back then and Kanton Solothurn needed longer life spans of QGIS versions and more stability and long-term support. Meanwhile, and mainly because QGIS now has an LTR version, Kanton Solothurn migrated back to QGIS 3.4 on the Desktop, with the plan to introduce QGIS 3.10 plus/minus around summer 2020. The other reason why we moved back from QGIS Enterprise to QGIS community version, was the fact that QGIS enterprise wasn't able to catch up feature wise (of course) but also bug fix wise with the main QGIS version. Again, the decision of QGIS.ORG to regularly run funded bug-fix efforts with each QGIS release, re-introduced a lot of confidence towards returning to the QGIS main community version.

The reality is, that by the time we introduce a new LTR version, half of the life-span of said version is already gone, which leaves us with half a year of support when we change to a new LT version.

Now, I'd like to find out under which circumstances QGIS.ORG would be willing to officially support QGIS LTR version for 2 years. I know that the last time I brought up this topic, it was rejected with the argument of limited resources of QGIS.ORG. But what if QGIS.ORG would have more resources? Would you still reject that request?

Follow up question: if QGIS.ORG would support an extension of the life span of an LTR for 2 years, would QGIS have to maintain overlapping LT versions in parallel, because we release a new LTR version every year, or would we rather also release fewer LTR versions, e.g. an LTR only every second year?

Thank you - again - for discussing this issue with us.

Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer)

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Tim Sutton-6
Hi



On 6 Feb 2020, at 10:23, Andreas Neumann <[hidden email]> wrote:

Hi PSC,

My current employer, Kanton of Solothurn, gave me the task to submit a formal request to PSC for the extension of the life span of the LTR version from one year to two years.

Hence I am submitting this request now and would like to open the discussion (again). I know we had this discussion before and it was rejected due to limited resources.

A little bit of background: Kanton of Solothurn was one of the first customers of Sourcepole and back then, way before there was an LTR version, was one of the reasons why QGIS enterprise was introduced, because QGIS did not offer and LTR version back then and Kanton Solothurn needed longer life spans of QGIS versions and more stability and long-term support. Meanwhile, and mainly because QGIS now has an LTR version, Kanton Solothurn migrated back to QGIS 3.4 on the Desktop, with the plan to introduce QGIS 3.10 plus/minus around summer 2020. The other reason why we moved back from QGIS Enterprise to QGIS community version, was the fact that QGIS enterprise wasn't able to catch up feature wise (of course) but also bug fix wise with the main QGIS version. Again, the decision of QGIS.ORG to regularly run funded bug-fix efforts with each QGIS release, re-introduced a lot of confidence towards returning to the QGIS main community version.

The reality is, that by the time we introduce a new LTR version, half of the life-span of said version is already gone, which leaves us with half a year of support when we change to a new LT version.

Now, I'd like to find out under which circumstances QGIS.ORG would be willing to officially support QGIS LTR version for 2 years. I know that the last time I brought up this topic, it was rejected with the argument of limited resources of QGIS.ORG. But what if QGIS.ORG would have more resources? Would you still reject that request?

Follow up question: if QGIS.ORG would support an extension of the life span of an LTR for 2 years, would QGIS have to maintain overlapping LT versions in parallel, because we release a new LTR version every year, or would we rather also release fewer LTR versions, e.g. an LTR only every second year?


I would rather propose to release a new LTR every 2 years, I think users will be confused having overlapping LTR versions and managing workflows for all the different ‘in the wild’ will be arduous. I’m also +1 for making the LTR’s last two years.

Regards

Tim


Thank you - again - for discussing this issue with us.

Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer)
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

 




---

Tim Sutton





_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Tim Sutton-6
Hi


On 6 Feb 2020, at 14:13, Tim Sutton <[hidden email]> wrote:

Hi

Follow up question: if QGIS.ORG would support an extension of the life span of an LTR for 2 years, would QGIS have to maintain overlapping LT versions in parallel, because we release a new LTR version every year, or would we rather also release fewer LTR versions, e.g. an LTR only every second year?


I would rather propose to release a new LTR every 2 years, I think users will be confused having overlapping LTR versions and managing workflows for all the different ‘in the wild’ will be arduous. I’m also +1 for making the LTR’s last two years.


By ‘rather' I meant I agree with your proposal of only having an LTR released every 2 years.


Regards

Tim


Thank you - again - for discussing this issue with us.

Andreas

--
Andreas Neumann
QGIS.ORG board member (treasurer)
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

 <qgis-icon-60x60.png>




---

Tim Sutton









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

I'd love to connect. Here's my calendar link to make finding time easy.


_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Sandro Santilli-4
In reply to this post by Andreas Neumann-3
On Thu, Feb 06, 2020 at 11:23:37AM +0100, Andreas Neumann wrote:

> Now, I'd like to find out under which circumstances QGIS.ORG would be
> willing to officially support QGIS LTR version for 2 years. I know that the
> last time I brought up this topic, it was rejected with the argument of
> limited resources of QGIS.ORG. But what if QGIS.ORG would have more
> resources? Would you still reject that request?
>
> Follow up question: if QGIS.ORG would support an extension of the life span
> of an LTR for 2 years, would QGIS have to maintain overlapping LT versions
> in parallel, because we release a new LTR version every year, or would we
> rather also release fewer LTR versions, e.g. an LTR only every second year?

I think having an LTR release every 2 years and supporting it for 2
years is a good idea. Note I'm still having 3.4.12 on my system and
wondering how can we already be at 3.12 ! Time flies...

--strk;
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Even Rouault-2
In reply to this post by Andreas Neumann-3
> Now, I'd like to find out under which circumstances QGIS.ORG would be
> willing to officially support QGIS LTR version for 2 years.

A few thoughts:

One aspect to take into account is how you organize the time for this 2 year
lifespan. Some weeks ago I floated around the idea of having 2 phases in the
LTR: a first phase where rather "aggressive" backports are allowed to be able
to potentially fix design issues in new features, and a second one where just
critical bugfixes are allowed given a risk/advantage assessment: a one-liner
fix to avoid a crashing bug is OK, but a 1000 line code change to fix a
crashing bug in a odd case scenario not. Of course with a number of grey
situations in between... With a 2 year lifespan, anyway this will probably
become more obvious as the difficulty to backport fixes will increase over
time.

There's also a packaging point of view to take into account (thinking to
OSGeo4W in particular). For a 2 year LTR, you likely need to make sure that
the dependencies of the LTR are controlled independently of the ones of QGIS
master. You might want to decide to update one of the dependencies in the LTR
(like upgrading to a new patch release of a dependency), but this must be a
choice, not a mechanical consequence of an upgrade of QGIS master.

Another thought is that some dependencies of QGIS (thinking to GDAL & PROJ)
don't have a 2 year life span for a given release, but more a 1 year one.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Andreas Neumann-4

Hi Even and others,

Thanks for your valuable feedback. I agree with the different phases of an LTR, from being more aggressive with bug fixing to being more conservative later on.

About the situation with dependencies (gdal, proj, geos): I wonder how other software packages do that who have a longer supported life span? I am pretty sure that most commercial GIS software packages offer support >1 year for. Do they typically freeze the dependencies? And maybe backport critical (e.g. security related) issues when necessary?

Would the gdal / proj / geos projects be open to discuss overlapping support of the latest versions in their projects? I am talking about critical issues, not new providers or features.

Of course, as always, I would also be interested in Jürgen's opinion, as his work would be affected by this decision.

Greetings,

Andreas

On 2020-02-06 16:03, Even Rouault wrote:

Now, I'd like to find out under which circumstances QGIS.ORG would be
willing to officially support QGIS LTR version for 2 years.

A few thoughts:

One aspect to take into account is how you organize the time for this 2 year
lifespan. Some weeks ago I floated around the idea of having 2 phases in the
LTR: a first phase where rather "aggressive" backports are allowed to be able
to potentially fix design issues in new features, and a second one where just
critical bugfixes are allowed given a risk/advantage assessment: a one-liner
fix to avoid a crashing bug is OK, but a 1000 line code change to fix a
crashing bug in a odd case scenario not. Of course with a number of grey
situations in between... With a 2 year lifespan, anyway this will probably
become more obvious as the difficulty to backport fixes will increase over
time.

There's also a packaging point of view to take into account (thinking to
OSGeo4W in particular). For a 2 year LTR, you likely need to make sure that
the dependencies of the LTR are controlled independently of the ones of QGIS
master. You might want to decide to update one of the dependencies in the LTR
(like upgrading to a new patch release of a dependency), but this must be a
choice, not a mechanical consequence of an upgrade of QGIS master.

Another thought is that some dependencies of QGIS (thinking to GDAL & PROJ)
don't have a 2 year life span for a given release, but more a 1 year one.

Even



_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

pcav
Hi all,

Il 06/02/20 16:24, Andreas Neumann ha scritto:

> Hi Even and others,
>
> Thanks for your valuable feedback. I agree with the different phases of
> an LTR, from being more aggressive with bug fixing to being more
> conservative later on.
>
> About the situation with dependencies (gdal, proj, geos): I wonder how
> other software packages do that who have a longer supported life span? I
> am pretty sure that most commercial GIS software packages offer support
>>1 year for. Do they typically freeze the dependencies? And maybe
> backport critical (e.g. security related) issues when necessary?
>
> Would the gdal / proj / geos projects be open to discuss overlapping
> support of the latest versions in their projects? I am talking about
> critical issues, not new providers or features.
>
> Of course, as always, I would also be interested in Jürgen's opinion, as
> his work would be affected by this decision.

I agree, dependencies will be an issue. For some platform we have full
control over the installers, but on cleaner systems (think Debian and
other Linuxes) this can be more difficult.
Cheers.

--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Even Rouault-2
In reply to this post by Andreas Neumann-4
> About the situation with dependencies (gdal, proj, geos): I wonder how
> other software packages do that who have a longer supported life span? I
> am pretty sure that most commercial GIS software packages offer support
> >1 year for. Do they typically freeze the dependencies? And maybe backport
> >critical (e.g. security related) issues when necessary?

Good question. For GDAL, a bit hard to have definitive answers given the
permissive nature of the license. I can think of at least a couple commercial
GIS editors who do have their own fork of GDAL, into which they probably merge
GDAL master regularly (sometimes to get bugfixes they commissionned) and also
commit their own (often application specific / dirty) bug fixes. Not sure how
much maintainance they do in their dependencies once they've cut a release.
Probably a function of
bug_severity x customer_importance_in_sales / cost_of_backport
I don't think they depend on official GDAL bugfix releases.
At least, that's for those who actively track GDAL. I'm pretty sure a number
of other editors only update their GDAL versions every few years and have a
passive attitude (can think of at least one who funnily claimed "we have no
control over" as a convenient excuse)

> Would the gdal / proj / geos projects be open to discuss overlapping
> support of the latest versions in their projects? I am talking about
> critical issues, not new providers or features.

To be discussed with each project.

Thinking about PROJ, there's someting that's between a feature and a bugfix:
upgrades of the EPSG database. Part of those upgrades are new CRS/
transformations (features), and parly bug fixes (deprecating a buggy entry and
replacing it by a corrected one). Those upgrades can be challenging to deal
with. For example the recent upgrade from EPSG 9.8.4 to 9.8.6 required code
changes in PROJ (interestingly due to the bugfixing part of the upgrade. A
transformation method that was found to lack a parameter was replaced by a new
extended method). Besides that, EPSG doesn't maintain LTR versions. The next
release might perhaps be the long awaited (or feared) EPSG 10.0 which will be
a big jump in the data model that will require non trivial code changes in
PROJ, much likely unsuitable for backport. (someone particularly motivated
could likely manually "backport" select changes from the new to the old data
model)
The above is not to kill the idea of a longer LTR, but just to point some
limits.

Nothing new here, but there's a cost per each commit you backport + a cost for
the release itself (for GDAL, ~0.5 day for a typical bugfix release). Thinking
about GDAL where we have an extensive number of continuous integration setups
(perhaps too many), maintaining them working over time could be super time
consuming (the CI environment changes over time, you depend on PPA that might
break etc etc). For extended lifetime, I guess we should probably cut them to
a reduced number of setups in the LTR branch.


Answering to Paolo:

> For some platform we have full control over the installers, but on cleaner
> > systems (think Debian and other Linuxes) this can be more difficult.

The closest equivalent to the Windows style of packaging I can think of would
be Snap (caveat: I've no practical experience with it). Seeing some past
discussion about it in https://issues.qgis.org/issues/17710
The upside would be that a single snap package could be installed on several
Linux distros.
The downside of it is that you'd have to track yourself all dependencies if
you want to ensure maintainance on the whole dependency chain. Another
downside apparently is that the launching time may be slower due to each Snap
package having its own libraries, and thus they aren't shared among
applications.
Not saying this is a replacement for .deb / .rpm style of packaging, but might
be something to consider for some uses.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Jürgen E. Fischer
In reply to this post by Andreas Neumann-4
Hi Andreas,

On Thu, 06. Feb 2020 at 16:24:40 +0100, Andreas Neumann wrote:
> Thanks for your valuable feedback. I agree with the different phases of
> an LTR, from being more aggressive with bug fixing to being more
> conservative later on.
 
> About the situation with dependencies (gdal, proj, geos): I wonder how
> other software packages do that who have a longer supported life span? I
> am pretty sure that most commercial GIS software packages offer support
> > 1 year for. Do they typically freeze the dependencies? And maybe
> > backport critical (e.g. security related) issues when necessary?
 
> Would the gdal / proj / geos projects be open to discuss overlapping
> support of the latest versions in their projects? I am talking about
> critical issues, not new providers or features.
 
> Of course, as always, I would also be interested in Jürgen's opinion, as
> his work would be affected by this decision.

IIRC my main concern was the time it takes feature to land in an LTR release,
which might be an obstacle when LTR users are also the ones that contract for
new features.

Of course keeping the dependencies alive can also become tricky.  But that has
been done before (py2 & py3, Qt4 & Qt5, GDAL2 & 3, PROJ4 & 5, x86 and x86_64).

Having a second OSGeo4W repo with old version shouldn't be an issue.  Switching
between two OSGeo4W installs on the build machine shouldn't be an big issue
either.

Actually separating stuff into two repos could make it easier in some aspects
(eg. same package names for different version lines, instead of different names
for different versions of the same software - eg. gdal instead of gdal &
gdal2).  But there will probably be need for more updates as there are more
different versions to track - with interdependencies between them and all with
different release cycles.

Another point was backporting that will get trickier the longer the LTR and LR
can diverge.


Jürgen


PS: Personally I don't find longer^W LTRs appealing.

--
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 FreeNode

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc

signature.asc (844 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Nyall Dawson
In reply to this post by Even Rouault-2
On Fri, 7 Feb 2020 at 01:03, Even Rouault <[hidden email]> wrote:

>
> > Now, I'd like to find out under which circumstances QGIS.ORG would be
> > willing to officially support QGIS LTR version for 2 years.
>
> A few thoughts:
>
> One aspect to take into account is how you organize the time for this 2 year
> lifespan. Some weeks ago I floated around the idea of having 2 phases in the
> LTR: a first phase where rather "aggressive" backports are allowed to be able
> to potentially fix design issues in new features, and a second one where just
> critical bugfixes are allowed given a risk/advantage assessment: a one-liner
> fix to avoid a crashing bug is OK, but a 1000 line code change to fix a
> crashing bug in a odd case scenario not. Of course with a number of grey
> situations in between... With a 2 year lifespan, anyway this will probably
> become more obvious as the difficulty to backport fixes will increase over
> time.

Big +1 to this. Before any decision is made I'd like to see us make a
proper definition of what an "LTR" release actually means. Is it just
that we continue to provide working installers for it for 2 years? Are
we pledging to fix high risk issues only, or any easily backportable
fixes (no matter how important the bug)? Where do we draw the line?

Personally, I stopped backporting fixes to 3.4 late last year. The
effort and trickiness involved in porting them was too high, and I
deemed the risk of doing this to greatly outweigh the benefit of
having a bug fixed in 3.4. In the absence of an official policy here,
I've been suggesting the same for backports others have submitted.

I'll run with whatever policy PSC sets for this, but it needs to be
very well defined in order to avoid any misunderstandings by either
developers or users...

> There's also a packaging point of view to take into account (thinking to
> OSGeo4W in particular). For a 2 year LTR, you likely need to make sure that
> the dependencies of the LTR are controlled independently of the ones of QGIS
> master. You might want to decide to update one of the dependencies in the LTR
> (like upgrading to a new patch release of a dependency), but this must be a
> choice, not a mechanical consequence of an upgrade of QGIS master.
>
> Another thought is that some dependencies of QGIS (thinking to GDAL & PROJ)
> don't have a 2 year life span for a given release, but more a 1 year one

Right -- as an example as soon as proj 7 rolls out without the older
api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
to do so). So when distros update to this that's the definite EOL for
3.4 support on those distros...

Nyall

>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> Qgis-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

G

Kristian Evers-2


There's also a packaging point of view to take into account (thinking to
OSGeo4W in particular). For a 2 year LTR, you likely need to make sure that
the dependencies of the LTR are controlled independently of the ones of QGIS
master. You might want to decide to update one of the dependencies in the LTR
(like upgrading to a new patch release of a dependency), but this must be a
choice, not a mechanical consequence of an upgrade of QGIS master.

Another thought is that some dependencies of QGIS (thinking to GDAL & PROJ)
don't have a 2 year life span for a given release, but more a 1 year one

Right -- as an example as soon as proj 7 rolls out without the older
api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
to do so). So when distros update to this that's the definite EOL for
3.4 support on those distros…

We’ve decided to extend the lifetime of the old API for the PROJ 7 release cycle [0]. So it will not
be PROJ that gives QGIS 3.4 the kiss of death. The decision was made to avoid situations like
this.

Even and Nyalls point above of course still stands. With the many dependencies QGIS has this situation
will come up sooner or later.

/Kristian



_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Kristian Evers-2
I mistakenly erased the title in the last email. Here’s my response below added to the correct thread.

Sorry for the noise.

/Kristian

On 7 Feb 2020, at 07:39, Kristian Evers <[hidden email]> wrote:



There's also a packaging point of view to take into account (thinking to
OSGeo4W in particular). For a 2 year LTR, you likely need to make sure that
the dependencies of the LTR are controlled independently of the ones of QGIS
master. You might want to decide to update one of the dependencies in the LTR
(like upgrading to a new patch release of a dependency), but this must be a
choice, not a mechanical consequence of an upgrade of QGIS master.

Another thought is that some dependencies of QGIS (thinking to GDAL & PROJ)
don't have a 2 year life span for a given release, but more a 1 year one

Right -- as an example as soon as proj 7 rolls out without the older
api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
to do so). So when distros update to this that's the definite EOL for
3.4 support on those distros…

We’ve decided to extend the lifetime of the old API for the PROJ 7 release cycle [0]. So it will not
be PROJ that gives QGIS 3.4 the kiss of death. The decision was made to avoid situations like
this.

Even and Nyalls point above of course still stands. With the many dependencies QGIS has this situation
will come up sooner or later.

/Kristian


_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc


_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Even Rouault-2
In reply to this post by Nyall Dawson
> I'll run with whatever policy PSC sets for this, but it needs to be
> very well defined in order to avoid any misunderstandings by either
> developers or users...

We cannot require developers to backport things, but just suggest. Even for
the bug-fixing program sponsored by QGIS.ORG, I don't think it would be
reasonable to spend a lot of time backporting a hard-to-backport bug fix
(perhaps some guidelines to be provided. "if it takes more than X hours, drop
the ball"). I'd expect such non-trivial efforts to be directly funded by the
organization interested in having the bug fixed in the LTR they use.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

pcav
In reply to this post by Nyall Dawson
Hi Nyall,

Il 07/02/20 07:00, Nyall Dawson ha scritto:

> Personally, I stopped backporting fixes to 3.4 late last year. The
> effort and trickiness involved in porting them was too high, and I
> deemed the risk of doing this to greatly outweigh the benefit of
> having a bug fixed in 3.4. In the absence of an official policy here,
> I've been suggesting the same for backports others have submitted.

I miss your point here: what is the usefulkness in having LTR without
bugfixing? It is just a downloadable static installer?

> I'll run with whatever policy PSC sets for this, but it needs to be
> very well defined in order to avoid any misunderstandings by either
> developers or users...

fully agreed

> Right -- as an example as soon as proj 7 rolls out without the older
> api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
> to do so). So when distros update to this that's the definite EOL for
> 3.4 support on those distros...

this is what scares me most. calling anything LTR and being unable to
use it in the OS of choice because of dependenciaes will increase
fragmentation.
IMHO we should try not to have too many versions around, as this will
increase noise, especially for bug reports (one of the crucial
priorities for our users).

Cheers.

--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Andreas Neumann-3
Hi,

Perhaps I need to better explain, why 1 year of LTR is not long enough for us:

- If you introduce a new QGIS version to approx 100 users, you cannot afford to use a .1, .2 or not even a .3 release that might contain serious issues.
- update processes in a very restricted environment with an IT department that is only moderately flexible, needs another 2-3 month to get the newly installed QGIS version into production. First we have to install the new QGIS on our testing environment. That window is open for one months and QGIS will be tested by some limited power users. Then it goes into integration environment - another month is gone. Finally, it reaches the production desktop environment.
- by the time, our users see the new LTR, about 8 months are in between
- then the first bugs arrive from live use in the field. We report these issues to our QGIS support provider. It can take some weeks to fix issues and we'll have to wait for the next dot release.

The result is: the window where we can really effectively get bug fixing into QGIS is really very short: maybe 2-4 months of a year, then the LTR version is abandoned by QGIS.

The above may sound quite inflexible and clumsy, but I think that many governmental institutions and larger corporations work similar. These environments are so restrictive that we simply can't install new versions really fast, like a small company or organization would do.

And of course you can say: such organizations should ask their support provider to provide further builds after the LTR was abandoned by QGIS.ORG. But that totally misses the collaborative spirit we have in Open Source and FOSSGIS. If individual customers would have to pay in parallel several support companies, to do build work in parallel, because QGIS.ORG has no interest in supporting the LTR version longer.

Maybe, the LTR version is also mainly a Windows issue. Linux and Mac users typically don't work in such restrictive environments.

One solution might be: QGIS.ORG does not actively fund bug fixing, for LTR older than one year, but it keeps the release branch open in Github for companies to commit to this branch. AND - and this is the important bit: it continues to provide packages for the second year. That way, one can offload the financial burden to the customers who really need longer LTR availability, but QGIS.ORG would also contribute by providing more and for longer time regular builds/packages. Perhaps, the two year LTR could also be limited to Windows only, as Linux/Mac users don't have the same problems or have other issues, with library dependencies ...

Thanks,
Andreas

On Fri, 7 Feb 2020 at 12:59, Paolo Cavallini <[hidden email]> wrote:
Hi Nyall,

Il 07/02/20 07:00, Nyall Dawson ha scritto:

> Personally, I stopped backporting fixes to 3.4 late last year. The
> effort and trickiness involved in porting them was too high, and I
> deemed the risk of doing this to greatly outweigh the benefit of
> having a bug fixed in 3.4. In the absence of an official policy here,
> I've been suggesting the same for backports others have submitted.

I miss your point here: what is the usefulkness in having LTR without
bugfixing? It is just a downloadable static installer?

> I'll run with whatever policy PSC sets for this, but it needs to be
> very well defined in order to avoid any misunderstandings by either
> developers or users...

fully agreed

> Right -- as an example as soon as proj 7 rolls out without the older
> api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
> to do so). So when distros update to this that's the definite EOL for
> 3.4 support on those distros...

this is what scares me most. calling anything LTR and being unable to
use it in the OS of choice because of dependenciaes will increase
fragmentation.
IMHO we should try not to have too many versions around, as this will
increase noise, especially for bug reports (one of the crucial
priorities for our users).

Cheers.

--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc


--

--
Andreas Neumann
QGIS.ORG board member (treasurer)

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Nyall Dawson
In reply to this post by pcav
On Fri, 7 Feb 2020 at 21:59, Paolo Cavallini <[hidden email]> wrote:

>
> Hi Nyall,
>
> Il 07/02/20 07:00, Nyall Dawson ha scritto:
>
> > Personally, I stopped backporting fixes to 3.4 late last year. The
> > effort and trickiness involved in porting them was too high, and I
> > deemed the risk of doing this to greatly outweigh the benefit of
> > having a bug fixed in 3.4. In the absence of an official policy here,
> > I've been suggesting the same for backports others have submitted.
>
> I miss your point here: what is the usefulkness in having LTR without
> bugfixing? It is just a downloadable static installer?

Pretty much, yes -- it argue that after a certain release stage it
would become a basically static branch, expecting at most 1-2 critical
(crashing or data corruption) fixes only per patch release (and
hopefully not even that!).

Nyall

>
> > I'll run with whatever policy PSC sets for this, but it needs to be
> > very well defined in order to avoid any misunderstandings by either
> > developers or users...
>
> fully agreed
>
> > Right -- as an example as soon as proj 7 rolls out without the older
> > api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
> > to do so). So when distros update to this that's the definite EOL for
> > 3.4 support on those distros...
>
> this is what scares me most. calling anything LTR and being unable to
> use it in the OS of choice because of dependenciaes will increase
> fragmentation.
> IMHO we should try not to have too many versions around, as this will
> increase noise, especially for bug reports (one of the crucial
> priorities for our users).
>
> Cheers.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> _______________________________________________
> Qgis-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Nyall Dawson
In reply to this post by Andreas Neumann-3
On Fri, 7 Feb 2020 at 22:36, Andreas Neumann <[hidden email]> wrote:

>
> Hi,
>
> Perhaps I need to better explain, why 1 year of LTR is not long enough for us:
>
> - If you introduce a new QGIS version to approx 100 users, you cannot afford to use a .1, .2 or not even a .3 release that might contain serious issues.
> - update processes in a very restricted environment with an IT department that is only moderately flexible, needs another 2-3 month to get the newly installed QGIS version into production. First we have to install the new QGIS on our testing environment. That window is open for one months and QGIS will be tested by some limited power users. Then it goes into integration environment - another month is gone. Finally, it reaches the production desktop environment.
> - by the time, our users see the new LTR, about 8 months are in between
> - then the first bugs arrive from live use in the field. We report these issues to our QGIS support provider. It can take some weeks to fix issues and we'll have to wait for the next dot release.
>
> The result is: the window where we can really effectively get bug fixing into QGIS is really very short: maybe 2-4 months of a year, then the LTR version is abandoned by QGIS.

Andreas -- let me preface my reply by saying that I fully understand
this situation, and the constraints which lead to it. It's a valid
external constraint which we **can't** change, and which we should (as
a project) adapt to satisfy.

That said... reading the above does slightly worry me. My
interpretation of this situation is that it's only 8 months after
initial LTR release (so at a 0.8 patch release) before this
organisation will start identifying and (hopefully) contributing fixes
to the LTR branch. At that stage in an LTR's life we should already
have a rock-solid version (or we are already doing something
wrong...!), so it's likely that the kind of issues identified will be
minor corner cases (**fully acknowledging that these minor corner
cases can be blockers for individual organisations**). I mean the kind
of issue we are seeing reported more and more these days: "when using
a relation reference widget with a postgis database with external
triggers connected to a FDW and using a json map for a foreign key the
relation widget doesn't show null values when run under
comma-as-decimal locales" ;) . That kind of thing. And these are the
kind of fixes which I personally **don't** like seeing pushed to a
stable, mature LTR branch. They are notoriously complex changes to
understand, difficult to test for and always seem to result in
regressions to other corner use cases. (In contrast to "when I load
this project QGIS crashes" type bugs, where the fix is usually just a
couple of lines of easily-verifiable changes).

So we end up with two classes of LTR users:
- those who are conservative, upgraded to the LTR only after a 0.4
patch release, and who expect that at that stage the release will be
stable and only seeing absolutely critical fixes
- those who are can only jump to the LTR release at a later (0.8 patch
release) stage, and who at that time require riskier changes to flow
into the LTR release.

Both are valid requirements, yet are potentially mutually exclusive.
We need to keep these both in mind when developing policy about
user/project handling of LTR releases.

Good discussion though, I'm glad to see we are working through this one!!

Nyall

>
> The above may sound quite inflexible and clumsy, but I think that many governmental institutions and larger corporations work similar. These environments are so restrictive that we simply can't install new versions really fast, like a small company or organization would do.
>
> And of course you can say: such organizations should ask their support provider to provide further builds after the LTR was abandoned by QGIS.ORG. But that totally misses the collaborative spirit we have in Open Source and FOSSGIS. If individual customers would have to pay in parallel several support companies, to do build work in parallel, because QGIS.ORG has no interest in supporting the LTR version longer.
>
> Maybe, the LTR version is also mainly a Windows issue. Linux and Mac users typically don't work in such restrictive environments.
>
> One solution might be: QGIS.ORG does not actively fund bug fixing, for LTR older than one year, but it keeps the release branch open in Github for companies to commit to this branch. AND - and this is the important bit: it continues to provide packages for the second year. That way, one can offload the financial burden to the customers who really need longer LTR availability, but QGIS.ORG would also contribute by providing more and for longer time regular builds/packages. Perhaps, the two year LTR could also be limited to Windows only, as Linux/Mac users don't have the same problems or have other issues, with library dependencies ...
>
> Thanks,
> Andreas
>
> On Fri, 7 Feb 2020 at 12:59, Paolo Cavallini <[hidden email]> wrote:
>>
>> Hi Nyall,
>>
>> Il 07/02/20 07:00, Nyall Dawson ha scritto:
>>
>> > Personally, I stopped backporting fixes to 3.4 late last year. The
>> > effort and trickiness involved in porting them was too high, and I
>> > deemed the risk of doing this to greatly outweigh the benefit of
>> > having a bug fixed in 3.4. In the absence of an official policy here,
>> > I've been suggesting the same for backports others have submitted.
>>
>> I miss your point here: what is the usefulkness in having LTR without
>> bugfixing? It is just a downloadable static installer?
>>
>> > I'll run with whatever policy PSC sets for this, but it needs to be
>> > very well defined in order to avoid any misunderstandings by either
>> > developers or users...
>>
>> fully agreed
>>
>> > Right -- as an example as soon as proj 7 rolls out without the older
>> > api compatibility, 3.4 will no longer build (and **CANNOT** be fixed
>> > to do so). So when distros update to this that's the definite EOL for
>> > 3.4 support on those distros...
>>
>> this is what scares me most. calling anything LTR and being unable to
>> use it in the OS of choice because of dependenciaes will increase
>> fragmentation.
>> IMHO we should try not to have too many versions around, as this will
>> increase noise, especially for bug reports (one of the crucial
>> priorities for our users).
>>
>> Cheers.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS.ORG Chair:
>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>> _______________________________________________
>> Qgis-psc mailing list
>> [hidden email]
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
> --
>
> --
> Andreas Neumann
> QGIS.ORG board member (treasurer)
> _______________________________________________
> Qgis-psc mailing list
> [hidden email]
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

pcav
In reply to this post by Nyall Dawson
Hi Nyall,

Il 08/02/20 03:06, Nyall Dawson ha scritto:
> Pretty much, yes -- it argue that after a certain release stage it
> would become a basically static branch, expecting at most 1-2 critical
> (crashing or data corruption) fixes only per patch release (and
> hopefully not even that!).

thanks for the clarification. This closely parallels the long standing
Debian approach:

Debian QGIS
unstable nightly
testing regular release
stable LTR
oldstable VLTR, as proposed by Andreas

This make sense to me, I'd be in favour.
Cheers.
--
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Matthias Kuhn 🌍
In reply to this post by Nyall Dawson
Hi

A very good discussion. Thank you for bringing it to the attention, Andreas.

On 2/8/20 3:19 AM, Nyall Dawson wrote:

>
> So we end up with two classes of LTR users:
> - those who are conservative, upgraded to the LTR only after a 0.4
> patch release, and who expect that at that stage the release will be
> stable and only seeing absolutely critical fixes
> - those who are can only jump to the LTR release at a later (0.8 patch
> release) stage, and who at that time require riskier changes to flow
> into the LTR release.
>
> Both are valid requirements, yet are potentially mutually exclusive.
> We need to keep these both in mind when developing policy about
> user/project handling of LTR releases.

We will need to find a balance between the two here. I think for a
prolonged lifetime we can also justify to increase the duration of the
first stage. On the other hand it would also be good to be able to
deliver a product for testing earlier in the life cycle for example by
releasing a (bi-)weekly "beta" version during feature freeze. If we can
convince the QGIS responsible application managers in organisations to
test earlier this way we can deliver a higher quality .0 final release
and allow them to migrate earlier. As a nice side-effect I can imagine
many "hey, did you see what's coming up in the next QGIS version" blog
posts from power users which would help to bring more people to testing
the beta versions.

As mentioned earlier, libraries that are used as a basis for the LTR are
just as important for stability. Key libraries being gdal, Qt, python
and proj where we will also need to define a "best served with" major
release that doesn't introduce breaking changes. I am sure we will
sometimes be in a situation where we cannot fix issues because
underlying issues are only fixed in new major versions of libraries -
most likely in Qt. In this case we will need to take the harder route
and stick to stability and stick to earlier versions - and if it's
important enough, we will need to work on a closer collaboration with Qt
to have backports to Qt LTS versions.

For reference, I planned to trigger a survey to get a better idea of our
users later this year which could help us having a better decision base
regarding release management. I thought to push this forward in summer
(when people have experience in migrating from 3.4 to 3.10 and we don't
have many effects from a 2 to 3 upgrade in the stats anymore), but we
can as well do it sooner.


- Which QGIS version are you currently using (3.4, 3.10, another LR)

- How often do you upgrade patch versions (monthly, sometimes, never)

- When do you plan to upgrade to the next version

- Size of organisation / installations

- What is the main reason for not upgrading patch releases more often
(Why should I if everyting just works; Internal testing takes too long;
Internal application deployment is complicated/expensive; I already
update every patch release; Patch releases tend to break things; I
didn't know there are patch releases; Other)

- What is the main reason for not upgrading the main QGIS version
earlier (Internal testing takes time; Never change a running system - I
do not trust new releases; Plugins are incompatible; I always wait for x
patch releases before upgrading out of habit; Other)

- In an ideal world, how often would you prefer to have new LTR versions
(1y, 2y, 5y, I use every release regardless if LTR or not)

- Do you have a support agreement with a core developer / company to fix
blocker issues before upgrading


Feedback on it very welcome.


I suspect we will have a good community of people and organisations who
would be happy if the QGIS release schedule would offer a stable product
series at a slower pace.

Matthias

_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
Reply | Threaded
Open this post in threaded view
|

Re: Formal request to extend LTR life span to two years

Thomas_Baumann
In reply to this post by Andreas Neumann-3
On Fri, 7 Feb 2020 at 22:36, Andreas Neumann <[hidden email]> wrote:
> - If you introduce a new QGIS version to approx 100 users, you cannot afford to use a .1, .2 or not even a .3 release that might contain serious issues.
...
> The result is: the window where we can really effectively get bug fixing into QGIS is really very short: maybe 2-4 months of a year, then the LTR version is abandoned by QGIS.


Thanks Andreas for  bringing this up.

At my workplace it is pretty much the same. I have to make sure the QGIS version is stable enough before I roll it out to the production environment. The first month after the first QGIS3 release it was just not stable enough for our needs.  The last month we had two showstoppers in QGIS3: (bug while selecting oracle features ( https://github.com/qgis/QGIS/pull/32965 )  and missing bwta-grid support in QGIS ( https://github.com/OSGeo/proj-datumgrid/issues/22#issuecomment-560004559 ) so we plan the rollout not to be done before March 2020.

From my point of view a longer life span of the LTR would also be highly appreciated but I can understand that it will increase the effords in maintaining the LTR releases.


I wonder if it would have been possible for us to have helped speeding up the time needed until QGIS3 got stable enough. We have support agreements with core developers and if we find a bug which affects us we pay for the bugfix.
But for opening a ticket at your QGIS service provider  I guess you need to be able to reproduce the crash. We had several crashes when closing QGIS for example where we did not really know what exactly caused the crash so we could not open a ticket.

In the past (with QGIS2)  we collected crash dumps and error messages to send it to our service provider but  this never really helped to find the reason of this crashes so we gave it up to try to fix not reproducible bugs.

regards,
Thomas


_______________________________________________
Qgis-psc mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/qgis-psc
12