Does a request of having qtquickcontrols2 and qtvirtualkeyboard 2.1 backported to 5.6. x have chance?
Actually I managed to do this myself, but an upstream solutuion is preferrable. The problem is that some important OS is no longer supported in 5.7.
Regards,
Gunnar
Gesendet: Freitag, 12. August 2016 um 13:18 Uhr
Von: "Lars Knoll" <lars.kn...@qt.io>
An: "Olivier Goffart" <oliv...@woboq.com>
Cc: "Qt development mailing list" <development@qt-project.org>
Betreff: Re: [Development] Which changes are suitable for 5.6?
Von: "Lars Knoll" <lars.kn...@qt.io>
An: "Olivier Goffart" <oliv...@woboq.com>
Cc: "Qt development mailing list" <development@qt-project.org>
Betreff: Re: [Development] Which changes are suitable for 5.6?
> On 12 Aug 2016, at 12:01, Olivier Goffart <oliv...@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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
