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

[Nyall Dawson]

On Fri, 7 Feb 2020 at 22:36, Andreas Neumann <andreas at qgis.org> 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 <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)
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc