> > >> - 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. >
Absolutely agree to that. Please keep in mind, that the Extended Security Maintenance (ESM) are designed to _only_ contain fixes for actively identified security vulnerabilities. As such, this is beyond the super-strict mode that the LTS releases are at that point. Even within LTS there is only a limited amount of allowed changes, to avoid any regression caused as users of LTS (especially in strict and beyond mode) need to have high guarantees on the quality. BR, Maurice Confidential -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
