<div dir="ltr"><div>Hello all,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 15, 2021 at 9:09 PM Andreas Neumann <<a href="mailto:andreas@qgis.org" target="_blank">andreas@qgis.org</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"><div dir="ltr"><div></div><div>- strictly separate the build systems and libraries of LTR and regular releases. Parts of the problem stem from the fact that during the lifetime of an LTR underlying libraries are updated. Ideally, the libraries of the LT releases only receive bug fixes, but no new features</div><div>- put more resources into manual testing</div><div>- put more resources into packaging in general</div><div>- let every release be checked manually by a couple of dedicates power users (at least the LTR ones) before it goes out to the public</div><br><div>I know - all of these need personal/financial resources.</div><div><br></div><div>Andreas<br></div></div></blockquote><div><br></div><div>Since resources are limited, another thing we may consider is to reduce the number of releases per year.</div><div>If on top of that, we could add a packaging freeze period, it would be possible to run installers' manual tests before they are released to the general public.</div><div><br></div><div>Here are some test plans we prepared for QEP 180:<br></div><div><br></div><div><a href="https://qgis.tenant.kiwitcms.org/plan/search/">https://qgis.tenant.kiwitcms.org/plan/search/</a></div><div><br></div><div>These are only examples, we can think about more tests, especially things that can't be caught by CI.<br></div><div><br></div><div>Best regards,</div><div><br></div><div>Alexandre Neto<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 15 Nov 2021 at 20:57, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</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 lists,<br>
<br>
I'd like to start some conversation about the dire condition of the<br>
QGIS LTR release and what we can do to remedy/avoid this in future.<br>
<br>
If you've missed the conversation, our QGIS 3.16 windows releases have<br>
been completely broken for nearly a month now. 3.16.12 had a critical<br>
issue which caused lockups in Python code, and now 3.16.13 has<br>
completely broken projection handling (resulting in loss of CRS,<br>
hangups when opening projects, etc).<br>
<br>
So what do we do? I can think of a few responses we could make:<br>
<br>
- Kill 3.16.13 with fire. It needs to be removed from the website and<br>
all traces of the internet ASAP. Rollback to only offering 3.16.11,<br>
which is the last good Windows 3.16 release.<br>
<br>
- Put out a massive apology (and ask users to step up their funding to<br>
better maintain QGIS releases in future ;)<br>
<br>
- Mark 3.16 as an early EOL. (I can't see anyone interested in<br>
resolving the actual issue, so we've no way forward here in releasing<br>
a "good" 3.16 release again.)<br>
<br>
- Write the LTR releases off as a failed concept. (i.e. if we don't<br>
have the resources to maintain them properly, we shouldn't be offering<br>
them at all and should resort back to the single maintained release at<br>
any one time situation.)<br>
<br>
- Lower the supported period of a LTR release to 6 months?<br>
<br>
- Offer "theoretical" LTR releases ONLY as source code, but leave it<br>
to users to compile themselves and accept responsibility for their own<br>
packaging of this release.<br>
<br>
- Go on a funding drive so that QGIS can **pay** a developer and<br>
packager so that we actually CAN say we have stable LTR releases<br>
again?<br>
<br>
- ...something else...?<br>
<br>
Suffice to say, these are big issues, with big responses. But we're<br>
also under extreme time pressure here -- 3.16 is broken beyond belief,<br>
and we DO need to make some public responses asap (i.e. TODAY!!!!)<br>
<br>
Nyall<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><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><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>
_______________________________________________<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><br>
</blockquote></div></div>