- only features shouldn't be picked back, in particular
- test changes should always be picked back, with a XFAIL, if
necessary
- refactorings should always be picked back (or not done at all)
- bugfixes should always be picked back
a word of caution: *every* change has the risk of regressions, bugfixes
have risks of regressions, refactorings have risks of regressions. the
more changes that are backported to stable / lts releases, the higher
the risk they will be released with regressions
On top of that, a regression can also be a security problem. The more we
pick non-essential changes back, the more likely we will pick new
security problems into stable branches.
I see that the desire to keep stable branches literally stable needs to
be balanced against the need to speedily and safely pick back fixes to
security problems. I can just give some handwaving and "experience"
arguments right now, but for me at least, this is not a settled issue.
If we want to change the rules, we should come up with some numbers on
how much time is wasted adapting security fixes for older branches (or
how often those adaptations actually fail), and how often we produce
regressions via refactorings and bug fixes.
best regards,
Ulf
--
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
