[QGIS-Developer] Some thought on LTR

[Nyall Dawson]

On Wed, 2 Oct 2019 at 15:58, Alessandro Pasotti <apasotti at gmail.com> wrote:
>
>
> Hi,
>
> was this thread the more recent discussion/decision about what to backport in LTS?
>
> If I understand correctly, the judgment is left to the individual core developer who by chance happens to approve the backport PR.

Correct.

> I'm asking because I feel that we developers do not always agree about what to backport and what not, IMO if the backport
> 1. is a bugfix
> 2. it has a low risk [1] of side effects
> 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.
>
> 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"?

No..... BUT.... recently I've been pushing this view hard. I'm of the
firm belief that EVERY backport, regardless how trivial it appears,
brings with it risk. And at this stage in the life of the LTR I just
don't see the risks of regressions outweighing anything but
crash/corruption fixes.

To use an example, take https://github.com/qgis/QGIS/pull/32068
"Disappearing Null representation in Range Widget on
QgsDoubleSpinBox". Tests aside, it's a one line, trival fix. But at
the same time, given the age of 3.4, users are well and truely used to
the current behavior (even if it's not ideal) and have learnt to live
with it. And if that 1 line change causes an unintended regression in
say... entering values in a spin box on non-english locales on
macos... the the consequence is disastrous.

So it's not a matter of just looking at the fix in isolation. It's a
risk management game of weighing up the (ever present) risk of
regression vs the severity of the original bug.

> 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"

Possibly, but it's very different early in the life of the LTR
release. It's only when we close in on the final rounds of patches for
a mature LTR release that I think the pace of chances should slow to a
trickle.

Nyall

> 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).
>
> Thank you for your opinions!
>
> [1] Yes, I know it's fuzzy but you get the point, examples are: good test coverage, UI only insulated change etc.
>
>
> On Fri, Aug 16, 2019 at 10:00 AM Paolo Cavallini <cavallini at faunalia.it> wrote:
>>
>> H
>> i all,
>>
>> On 07/08/19 12:05, Marco Bernasocchi wrote:
>>
>> > - there is a sort of "regression obsession", IMO bugs are bugs, and they
>> > should ideally be fixed whenever possible (also see Jürgen's answer on
>> > another tread [1])
>>
>> I agree 50% here. Of course obsessions are bad. However, breaking an
>> existing functionality scares people away from upgrading, and undermines
>> the credibility of the project. Having people using older version has
>> always been an issue for the project.
>>
>> > - assessing a "low chance of regression" is a gray area and as Nyall
>> > said before "...every bug fix, regardless of how trivial it seems,
>> > brings with it the increased chances of regressions into the stable LTR
>> > release..."
>>
>> fully agreed, this is obviously the main problem here.
>>
>> > - on the economical point of view,  limiting the bugs that can be fixed
>> > in an LTR will make it very difficult to actually get larger users to
>> > pay for bug-fixing, they are the target group for the LTR and slowly
>> > they are understanding that fixing bugs needs resources. To me limiting
>> > the amount of bugs that can be fixed in an LTR would be a very unwise
>> > move since it would also reduce the number of bugs that get fixed in non
>> > LTR releases.
>>
>> this is also a good point. of course clearcut solutions are impossible,
>> so I think it's just a matter of personal judgment. The only practical
>> alternative I see is the one below.
>>
>> >>  I don't see a way to decide other than relying on the
>> >> developer's assessment. The only (costly) improvement I'd see is having
>> >> another independent core dev to check any bugfix before accepting it.
>>
>> All the best.
>>
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS.ORG Chair:
>> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it