On 26.05.26 13:52, Ville Voutilainen wrote: On Tue, 26 May 2026 at 10:55, Marc Mutz via Development <[email protected]><mailto:[email protected]> wrote:
To me, this issue reinforces what I have known to be true for years, to wit: - the compiler is more clever than you, you MUST NOT fall into UB, regardless of whether _you_ think it's benign (even if you think you can prove it) This part is correct, and non-controversial. At the same time, what I have known to be true for years, with evidence, is that (after the parenthetical).. - only features shouldn't be picked back, in particular - test changes should always be picked back, with a XFAIL, if necessary (I don't know what this is trying to say. What sort of test changes? Are there examples of this? If there's no functionality being backported, why would test changes be backported?) Anything under tests/: cleanups, test extensions prior to src/ refactorings, bugfixes, etc, xfail bug reproducers, ... You would be surprised how many cherry-picks conflict in tests/ and not src/ - refactorings should always be picked back (or not done at all) ..this is completely false, and at best depends on the refactoring. And that's at best, and there's absolutely certainly no "always" in any of it, and even less so if the refactorings are large. Refactoring, even huge ones, are completely safe and never change behaviour. If they do, they're not refactorings, but something else. - bugfixes should always be picked back ..and this depends on the nature and severity of the bug. Does it, now? Which customer wants to sit on a version of Qt with a known, unfixed bug? Just because it hasn't hit them, yet, doesn't mean it won't hit them in the future, or, worse, hit a customer of theirs. I think if we could guarantee "no regressions", customers would very much prefer to have _all_ bugfixes. So that's just conflating two orthogonal issues, IMHO. None of the story illustrated in the original convinces me an inch to the suggested direction of aggressive picking. The alternative is to produce less churn, iow accept that braces are placed wrong, and _not_ reformat the whole file ;) Sometimes (brace placement), that's the correct thing to do. Over the long run, reversing the natural order of refactor-then-fix to fix-then-refactor will accrue more technical debt, and not just of the "divergent code in branches" kind. 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
