[Qgis-psc] Formal request to extend LTR life span to two years

[Even Rouault]

> 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