<div dir="ltr"><div>Hi,</div><div><br></div><div>Perhaps I need to better explain, why 1 year of LTR is not long enough for us:</div><div><br></div><div>- 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.</div><div>- 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.</div><div>- by the time, our users see the new LTR, about 8 months are in between</div><div>- 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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>And of course you can say: such organizations should ask their support provider to provide further builds after the LTR was abandoned by <a href="http://QGIS.ORG">QGIS.ORG</a>. 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 <a href="http://QGIS.ORG">QGIS.ORG</a> has no interest in supporting the LTR version longer.</div><div><br></div><div>Maybe, the LTR version is also mainly a Windows issue. Linux and Mac users typically don't work in such restrictive environments.</div><div><br></div><div>One solution might be: <a href="http://QGIS.ORG">QGIS.ORG</a> 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 <a href="http://QGIS.ORG">QGIS.ORG</a> 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 ...</div><div><br></div><div>Thanks,</div><div>Andreas<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 7 Feb 2020 at 12:59, Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Nyall,<br>
<br>
Il 07/02/20 07:00, Nyall Dawson ha scritto:<br>
<br>
> Personally, I stopped backporting fixes to 3.4 late last year. The<br>
> effort and trickiness involved in porting them was too high, and I<br>
> deemed the risk of doing this to greatly outweigh the benefit of<br>
> having a bug fixed in 3.4. In the absence of an official policy here,<br>
> I've been suggesting the same for backports others have submitted.<br>
<br>
I miss your point here: what is the usefulkness in having LTR without<br>
bugfixing? It is just a downloadable static installer?<br>
<br>
> I'll run with whatever policy PSC sets for this, but it needs to be<br>
> very well defined in order to avoid any misunderstandings by either<br>
> developers or users...<br>
<br>
fully agreed<br>
<br>
> Right -- as an example as soon as proj 7 rolls out without the older<br>
> api compatibility, 3.4 will no longer build (and **CANNOT** be fixed<br>
> to do so). So when distros update to this that's the definite EOL for<br>
> 3.4 support on those distros...<br>
<br>
this is what scares me most. calling anything LTR and being unable to<br>
use it in the OS of choice because of dependenciaes will increase<br>
fragmentation.<br>
IMHO we should try not to have too many versions around, as this will<br>
increase noise, especially for bug reports (one of the crucial<br>
priorities for our users).<br>
<br>
Cheers.<br>
<br>
-- <br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
<a href="http://QGIS.ORG" rel="noreferrer" target="_blank">QGIS.ORG</a> Chair:<br>
<a href="http://planet.qgis.org/planet/user/28/tag/qgis%20board/" rel="noreferrer" target="_blank">http://planet.qgis.org/planet/user/28/tag/qgis%20board/</a><br>
_______________________________________________<br>
Qgis-psc mailing list<br>
<a href="mailto:Qgis-psc@lists.osgeo.org" target="_blank">Qgis-psc@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br>--<br>Andreas Neumann<br></div><a href="http://QGIS.ORG" target="_blank">QGIS.ORG</a> board member (treasurer)<br></div></div>