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 <[email protected]> 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 > [email protected] > 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
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
