[QGIS-Developer] Some thought on LTR

[Alessandro Pasotti]

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.

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

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"

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20191002/4c755907/attachment.html>