<div dir="ltr"><div dir="ltr"><br></div><div>Hi, <br></div><div><br></div><div>was this thread the more recent discussion/decision about what to backport in LTS?</div><div><br></div><div>If I understand correctly, the judgment is left to the individual core developer who by chance happens to approve the backport PR.<br></div><div><br></div><div>I'm asking because I feel that we developers do not always agree about what to backport and what not, IMO if the backport</div><div>1. is a bugfix <br></div><div>2. it has a low risk [1] of side effects <br></div><div>I don't see a valid reason for not doing the backport while I see a few advantages for the LTS users if the bugfix landed into LTS.<br></div><div><br></div><div>In other word, and more importantly: do we have a strict policy that states that "ONLY PATCHES THAT FIX CRASHES OR DATA LOSS ARE ADMISSIBLE FOR BACKPORTING TO LTS"?</div><div><br></div><div>If this is the case, I would recommend that we write it down in the developers docs and we start to label/close the LTS issues with "WON'T FIX"<br></div><div><br></div><div>Final note: I really don't have a strong opinion here, but I thinks it's a shame if we waste developer's time on backports that are not admissible and I think we should have a clear(er) policy (unless it's just for me that it's not clear).<br></div><div><br></div><div>Thank you for your opinions!<br></div><div><br></div><div>[1] Yes, I know it's fuzzy but you get the point, examples are: good test coverage, UI only insulated change etc.<br></div><div dir="ltr"></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 16, 2019 at 10:00 AM 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">H<br>
i all,<br>
<br>
On 07/08/19 12:05, Marco Bernasocchi wrote:<br>
<br>
> - there is a sort of "regression obsession", IMO bugs are bugs, and they<br>
> should ideally be fixed whenever possible (also see Jürgen's answer on<br>
> another tread [1])<br>
<br>
I agree 50% here. Of course obsessions are bad. However, breaking an<br>
existing functionality scares people away from upgrading, and undermines<br>
the credibility of the project. Having people using older version has<br>
always been an issue for the project.<br>
<br>
> - assessing a "low chance of regression" is a gray area and as Nyall<br>
> said before "...every bug fix, regardless of how trivial it seems,<br>
> brings with it the increased chances of regressions into the stable LTR<br>
> release..."<br>
<br>
fully agreed, this is obviously the main problem here.<br>
<br>
> - on the economical point of view,  limiting the bugs that can be fixed<br>
> in an LTR will make it very difficult to actually get larger users to<br>
> pay for bug-fixing, they are the target group for the LTR and slowly<br>
> they are understanding that fixing bugs needs resources. To me limiting<br>
> the amount of bugs that can be fixed in an LTR would be a very unwise<br>
> move since it would also reduce the number of bugs that get fixed in non<br>
> LTR releases.<br>
<br>
this is also a good point. of course clearcut solutions are impossible,<br>
so I think it's just a matter of personal judgment. The only practical<br>
alternative I see is the one below.<br>
<br>
>>  I don't see a way to decide other than relying on the<br>
>> developer's assessment. The only (costly) improvement I'd see is having<br>
>> another independent core dev to check any bugfix before accepting it.<br>
<br>
All the best.<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-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Alessandro Pasotti<br>w3:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>