On Tuesday, 26 May 2026 11:26:52 Pacific Daylight Time Ville Voutilainen wrote: > Maybe. But considering that we can't guarantee that, prudence dictates > avoiding nonsense like suggestions that we should "always" cherry-pick > refactorings.
Refactorings are seldom done in isolation. It's almost always part of a larger change, either a bugfix or a new feature/capability that prompted that. In ideal cases, the refactoring is done ahead of the new feature or expansion of the capability, so it could be picked back. But then the rest of the change is probably going to change the code anyway and obviate the benefit we'd get on having the refactor picked back. We would end up with code changed for the sake of change, in a configuration that was never tested in newer branches. At best, it's a no-op; at worst, we did miss something that introduces a regression. So I agree with Ville: it's not-always. -- Thiago Macieira - thiago.macieira (AT) intel.com Principal Engineer - Intel DCG - Platform & Sys. Eng.
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
