<div dir="ltr"><div dir="ltr">Jumping in the discussion to offer thoughts on the bigger picture here: while we have a few dozen regressions filed against 3.4 LTR, it's also true that 3.4 LTR has _countless_ fixes and refinements - not referring to new features here - when compared to 2.18 which adds a big amount of positive in the balance here.<br><br>Big +1 to using the near EOL of 2.X to advocate for some funding to address the remaining regressions, and a huge -1 to the idea of extending the lifespan of 2.18 LTR.<br><br>Beyond the feasibility issues of a zero regression target, IMHO we would simply make ourselves and our users a disservice. Beyond the platform improvements of (Qt5, Python3, etc.) and the above-mentioned fixes and refinements 3.X, which users can safely embrace as of 3.4.3, the reality of the 2.18.X branch is that the code is so divergent from master that it's essentially "retired" code. Most of the fixes committed to master / 3.4 LTR can't be straightforwardly backported to 2.18.X anymore. EOL for 2.18 is simply mirroring a code reality as of the end of 2018. <br><br>Math<br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 28, 2018 at 4:58 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">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">On Thu, 27 Dec 2018 at 18:42, Paolo Cavallini <<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>> wrote:<br>
<br>
> From another standpoint, we still have 102 Q3 regressions:<br>
> <a href="https://issues.qgis.org/projects/qgis/issues?query_id=27" rel="noreferrer" target="_blank">https://issues.qgis.org/projects/qgis/issues?query_id=27</a><br>
> From a quick scroll, I suspect at least some of them are not<br>
> particularly relevant, but a thorough analysis is needed.<br>
<br>
Yeah, a quick flick through revealed a very mixed lot -- many sound<br>
familiar and likely have already been fixed, some I know are still<br>
outstanding, and many waiting feedback for too long and should be just<br>
closed.<br>
<br>
I guess my question is (if we do delay the 2.x EOL as a result of<br>
these) is how many regressions are "acceptable" before EOL? We'll<br>
never get this to 0 -- there's been too many "by design" changes to<br>
make a zero regression target feasible (See obligatory xkcd ref:<br>
<a href="https://xkcd.com/1172/" rel="noreferrer" target="_blank">https://xkcd.com/1172/</a>).<br>
<br>
> I'm not sure whether it will be acceptable for our users to release an<br>
> LTR with these regression, but this could be a way of putting pressure<br>
> on donors to help us fix them.<br>
<br>
Big +1 to this. If I'm being blunt, I think if a bug is a blocker to<br>
an organisation moving to 3.4, it's ultimately going to sit with them<br>
to get it fixed (or to sponsor QGIS and support the funded bug hunts).<br>
(Or, perhaps, in the case of regressions in features an organisation<br>
originally funded -- it's their responsibility to put pressure on the<br>
original developer they paid for the feature to fix it and protect it<br>
with suitable unit tests -- but that's between them and their original<br>
developer).<br>
<br>
Nyall<br>
<br>
> A big +1 for the blog post.<br>
> All the best.<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>