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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
