On 26.05.26 12:06, Tim Blechmann via Development wrote: - 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 This sparks many threads in my head. In no particular order: * Getting up out of bed in the morning has risks. That's not the point. The question is (and I don't know the quantitative answer, but I have a qualitative hunch) what has _more_ risk: combining "random" commit sets in older, less-actively tested branches, or having such older branches always be a properly-ordered topological subset of patches from younger branches, as god^Wgit decreed? * A question that must be raised: what is more important? Regression-free stable branches, or TTM for security fixes? That's above my pay grade, but at least in the run-up to the "no security issues because Mythos found them all" nirvana, I guess TTM of security fixes _might_ be more important. By now, all security problems must be considered public knowledge, after all. Not even closed source is safe when they run AI on the executable instead. * I would also like to see explained why it's ok for 3rd-party components to be updated completely, but not for Qt components themselves. After all, we have control over the latter, but little to no control over the former. * As for refactorings: no, refactorings cannot have regressions. If a change causes regressions, then by definition it wasn't a refactoring. That the term is used to mean arbitrary rewrites instead of actual refactorings is part of the problem, though. From refactoring.com: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. Its heart is a series of small behavior preserving transformations. * As for bug-fixes: they ought to be clearly communicated to users via [ChangeLog], so users know what will come with the next update instead of showing up as regressions in their projects. In the age of AI, there's no excuse for consumers of our products to not run the ChangeLog (or even the diff between releases) and their code past some AI to find potential regressions, it not outright fix the code, before upgrading. Finally, for security-critical code, regressions should really, really not occur. At least not unknown ones: when we decide to make a user-visible change, like a deprecation, that could regress someone out there, that's more like a bugfix (hopefully). If we have a problem with regressions in security-critical code, then we need to look no further than in the mirror and have an honest talk with ourselves about why the usual safe-guards: code review, unit tests, integration tests, keep failing to catch regressions. Thanks, Marc -- Marc Mutz <[email protected]><mailto:[email protected]> (he/his) Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io<http://www.qt.io> Geschäftsführer: Mika Pälsi, Juha Varelius, Juha Puputti Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Public
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
