[Development] Qt 5.8 branching & Feature Freeze

Thu Jun 16 09:44:33 CEST 2016

"Currently we can’t put anything new in, since Coin setup is frozen."

Due to my limited knowledge with coin, I don't understand this.

Coin, the new CI, should not bind with any paticular branch of Qt, but some
options and scripts could.

For the listed new OSes, openSUSE 42.1, Ubuntu 16.04, RHEL 7.2, OS X 10.11,
if qt libs built failed, it should be P1 or P0 in current development
branches, from 5.6. And for autotest failures, most could be blacklisted or
skipped in the first step. The work for adding new untested platforms, need
to be done in 5.6, as lower as possible. Like now, working with dev, then a
fix need to be in 5.6, and a few more merges after that. I don't think it's
smart. tvOS is a different story.

For the integration of qt5.git dev branch was not a priority job before,
because it will not be a blocker of near future releases. After a new 5.x
branch out, it has more priority. And who is/are the integrator is also not
very clear. Perhaps the thing is changing now.

And recently 5.6, 5.6.1, 5.7, 5.7.0, dev, five branches and two releases
together, some critical issues were found in 5.6.1, then needed to be in
5.7.0 too... Not a very good experience, at least for me. Perhaps it's
because lacking of binaries for 5.6 snapshots, then not enough usage and
testing.

Best Regards,
Liang

On 16 June 2016 at 08:57, Tony Sarajärvi <tony.sarajarvi at qt.io> wrote:

> Hi,
>
>
>
> Our aim was to get new platforms in immediately after the previous
> platforms branched away from dev branch. Meaning, when 5.7 branch was
> created and it branched away from dev branch, all new platforms aiming for
> 5.8 should have been put into dev branch. However, in practice it didn’t
> quite go as expected. Not to blame anyone, but all focus was to get 5.6.x
> and 5.7.x out. Meaning, dev branch was left broken for several months. The
> individual submodules did pass in the CI, but the last time Qt5 has passed
> is 4 months ago.
>
>
>
> To tackle this we agreed that we can start inserting new platforms
> submodule by submodule, but right after that we froze Coin setup so that we
> don’t break 5.7.x by accident. And by having several branches, with alphas,
> betas, release candidates and releases themselves we have a lot of these
> freezes, which means that the time window, where we can put in any new
> platform, is very short. And if the submodule in dev don’t happen to have
> everything merged from earlier branches and finally work, an insertion
> won’t happen.
>
>
>
> This is why we’ve not been successful in bringing openSUSE 42.1, Ubuntu
> 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for
> months.
>
>
>
> So back to this day. Currently we can’t put anything new in, since Coin
> setup is frozen. We have holidays coming up and we have a skeleton crew
> working the entire summer. Right as we get back to work, we have 5.8 branch
> coming up and feature freeze right after that. When did you expect us to
> push in these new platforms? According to process, we shouldn’t put them
> into 5.8 after FF. If we bend this rule (as we usually do), we might get
> them in there as people focus on fixing issues there, or the same thing
> happens as happened with 5.7: the new platforms simply never passed
> autotests so that they could be brought in (we actually did try to get them
> into 5.7 early on, but not lately due to release being too close).
>
>
>
> Ok...perhaps I should propose something. Let’s postpone branching 5.8. As
> much as I like the motto of Blizzard Entertainment “done when it’s done” ,
> I’ve found that people like time schedules as well. Alas, I have to suggest
> that we postpone it as much as possible. I think that we can fix the things
> we want to fix in 5.8 in dev branch as well. When we get a more mature dev
> branch that actually works, we can generate the alpha package for 5.8 much
> faster after the branch, as 5.8 already worked right of the bat (because
> dev worked). Also, we’ll get a working dev branch as well simultaneously.
>
>
>
> Also, we’ve noticed that often when people fix problems found in
> autotests, being it a bug in the autotest itself or as it actually more
> often is, a problem in Qt sources themselves, people push the fix to the
> most mature branch available. In this case, when we report that we can’t
> get openSUSE 42.1 in, because this and that fails, the fix is pushed into
> 5.6 as it already appears there but haven’t been found or studied before.
> Then we have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7
> -> dev merge. With all the general flakiness in the system, that usually
> takes a fortnight at least.
>
>
>
> So by fixing dev, we can skip doing merges from 5.8 -> dev when we
> eventually find the problems for these new platforms.
>
>
>
> With regards,
>
> -Tony
>
>
>
> PS: The list with new platforms actually increases yet with OS X…ehm macOS
> Sierra (10.12) beta coming up, tvOS etc…
>
>
>
> *From:* Development [mailto:development-bounces+tony.sarajarvi=
> qt.io at qt-project.org] *On Behalf Of *Maurice Kalinowski
> *Sent:* 15. kesäkuuta 2016 16:51
> *To:* Tuukka Turunen <tuukka.turunen at qt.io>; Jake Petroules <
> Jake.Petroules at qt.io>; Mike Krus <mike.krus at kdab.com>
> *Cc:* development at qt-project.org
>
> *Subject:* Re: [Development] Qt 5.8 branching & Feature Freeze
>
>
>
> Hi,
>
>
>
> Another option might be to do it the same way like we do for UWP currently
> due to limited resources on the CI system. There we have at least a compile
> check every time qt5.git integration is supposed to happen.
>
>
>
> This is bare minimum, but at least guarantees that compilation will work
> for release. The rest still needs to be manually tested and/or is covered
> by Windows 8.1 WinRT test coverage (which isn’t too high either).
>
>
>
> BR,
>
> Maurice
>
>
>
> *Von:* Development [mailto:development-bounces+maurice.kalinowski=
> qt.io at qt-project.org] *Im Auftrag von *Tuukka Turunen
> *Gesendet:* Wednesday, June 15, 2016 11:59 AM
> *An:* Jake Petroules <Jake.Petroules at qt.io>; Mike Krus <mike.krus at kdab.com
> >
> *Cc:* development at qt-project.org
> *Betreff:* Re: [Development] Qt 5.8 branching & Feature Freeze
>
>
>
>
>
> Hi,
>
>
>
> Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when
> breakages happen. We are still quite stretched with the CI and adding tvOS
> increases the load of the CI and also risk of breakages for everyone. That
> of course is the role of CI, but since tvOS is not at the moment so
> critical, perhaps it is better to monitor it and fix afterwards when
> breakages do occur.
>
>
>
> Yours,
>
>
>
>                              Tuukka
>
>
>
>
>
> *From:* Jake Petroules
> *Sent:* keskiviikkona 15. kesäkuuta 2016 12.01
> *To:* Mike Krus <mike.krus at kdab.com>
> *Cc:* Tuukka Turunen <tuukka.turunen at qt.io>; development at qt-project.org
> *Subject:* Re: [Development] Qt 5.8 branching & Feature Freeze
>
>
>
> +1. I requested this earlier as well.
>
>
>
> On Jun 15, 2016, at 1:51 AM, Mike Krus <mike.krus at kdab.com> wrote:
>
>
>
> Hi
>
>
>
> would it be possible to have CI for tvOS in time for this too?
>
>
>
>
>
> Cheers,
>
>
>
> Mike
>
>
>
>
>
> On 15 Jun 2016, at 08:15, Tuukka Turunen <tuukka.turunen at qt.io> wrote:
>
>
>
>
>
> Hi,
>
>
>
> I would also like to have all new modules (if any) of Qt 5.8 as well as
> implement all (feasible) platform and compiler versions well before the
> feature freeze. Is it possible to agree that latest by 1.8. all these are
> completed? Preferably earlier, if possible.
>
>
>
> Yours,
>
>
>
>                              Tuukka
>
>
>
> *From:* Development [
> mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org
> <development-bounces+tuukka.turunen=qt.io at qt-project.org>] *On Behalf Of *Jani
> Heikkinen
> *Sent:* keskiviikkona 15. kesäkuuta 2016 9.27
> *To:* development at qt-project.org
> *Subject:* [Development] Qt 5.8 branching & Feature Freeze
>
>
>
> Hi all,
>
>
>
> It was agreed in yesterday's release team meeting to propose following
> schedule for Qt 5.8 branching and Feature Freeze:
>
>
>
> - Start branching '5.8' from 'dev': 2.8.2016
>
> - Feature Freeze (and finalize branching): 9.8.2016
>
>
>
> With that schedule we should be able to release Qt 5.8.0 before Christmas.
> Delaying these would cause Qt 5.8.0 release to be delayed to the beginning
> of next year. Any objections?
>
>
>
> br,
>
> Jani
>
>
>
>
>
> Jani Heikkinen
> Release Manager
>
> The Qt Company
> Elektroniikkatie 13
> 90590 Oulu Finland
> jani.heikkinen at qt.io
> +358 50 4873735
> http://qt.io
>
>
> [image: Image removed by sender.] <http://qt.io/>
>
> [image: Image removed by sender.] <http://www.facebook.com/Qt>
>
> [image: Image removed by sender.] <http://www.twitter.com/qtproject>
>
> [image: Image removed by sender.]
> <https://www.linkedin.com/company/the-qt-company/>
>
> [image: Image removed by sender.]
> <https://plus.google.com/104580575722059274792>
>
> [image: Image removed by sender.] <https://www.youtube.com/QtStudios>
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> --
> Mike Krus | mike.krus at kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company
> Tel: UK +44-1625-809908   Mobile: +44 7833 491941
> KDAB - The Qt Experts
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> --
> Jake Petroules - jake.petroules at qt.io
> Consulting Services Engineer - The Qt Company
>
> Qbs build system evangelist - qbs.io
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160616/f094ceb8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 347 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160616/f094ceb8/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 437 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160616/f094ceb8/attachment-0001.jpg>