On Tue, 26 May 2026 at 18:06, Marc Mutz via Development <[email protected]> wrote: > - 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, ...
In other words, a very clear not-always case, here, too. > 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. Spare me the theoretical ideals. > > - bugfixes should always be picked back > > ..and this depends on the nature and severity of the bug. > > Does it, now? Yes, it does. > Which customer wants to sit on a version of Qt with a known, unfixed bug? Every customer who is not affected by such a bug and wants to avoid large changes that might cause regression bugs that would actually impact them. > 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. Maybe. But considering that we can't guarantee that, prudence dictates avoiding nonsense like suggestions that we should "always" cherry-pick refactorings. -- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
