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

[Andreas Neumann]

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 <cavallini at faunalia.it> 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
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc



-- 

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200207/8954e1b0/attachment.html>