[Development] Which changes are suitable for 5.6?

[Olivier Goffart]

On Freitag, 12. August 2016 10:52:52 CEST Marc Mutz wrote:
> Hi,
> 
> I'd like to know what the rules are supposed to for submitting to 5.6 (LTS).
> 
> Should we enforce the strict rules of other minor releases (only regressions
> and P2+)?
> 
> IMHO, 5.6 is not like 5.5. So with another 2+ years of 5.6 lifetime, more
> relaxed rules should apply.

In my interpretation, LTS means it's just a stable branch, but that will stay 
maintained longer, with the same criterias as normal stable branches.
[https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change.3F]
That is, we make sure it works longer with more recent compiler/platform and 
keep security patches or crashes patches.

> I'd like all bug-fixes to go to 5.6 first, even if the priority is not high,
> and regressions cannot be ruled out (they never can, anyway).

I think that's not a good definition of a stable branch. Bugfixes are risky as 
they touch working code.
Why not also add all features? Features are less risky to break stuff as they 
add new code and are often not affecting the existing users.

> I also think that dead code elimination should be in-scope for 5.6, to not
> construct unessesary diffs between 5.6 and dev.

Is the code really dead? Is that patch not going to cause even more merge 
conflicts as we merge through the branches? 
 
> And last, some authors target optimisations at 5.6, some at 5.7 and others
> (me included, even though I sympathise with submitting to 5.6) at dev/5.8.
> What's the stance on this?

Optimisations are usually quite dangerous, and may cause regressions.

-- 
Olivier

Woboq - Qt services and support - https://woboq.com - https://code.woboq.org