[Development] Which changes are suitable for 5.6?

[Lars Knoll]

> On 12 Aug 2016, at 12:01, Olivier Goffart <olivier at woboq.com> wrote:
> 
> 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.

Yes, same criteria as normal stable branches apply. The difference is that we might (but don't have to) do some additional work to ensure 5.6 works on newer OS versions if they come out during the lifetime of 5.6.
> 
>> 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.

Agree. Bug fixes go in if they are regressions or critical issues that can't be worked around easily.
> 
>> 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? 

We'll have enough diff between the branches anyway. Dead code removal and other cleanups should always happen in dev, never in stable branches. If the code is dead, nobody will touch it in 5.6 anyway, so it most likely won't cause merge conflicts neither.
> 
>> 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.

Those go to dev. There can be exceptions, if e.g. a certain algorithm is showing exponential behaviour (thus rendering Qt unusable with large sets of data), but not for a patch that just makes something a couple of percent faster or reduces memory consumption by some bytes.

Cheers,
Lars

> 
> -- 
> Olivier
> 
> Woboq - Qt services and support - https://woboq.com - https://code.woboq.org
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development