From googleersatz at oliverniebuhr.de Wed Feb 1 11:07:47 2017 From: googleersatz at oliverniebuhr.de (Google Ersatz) Date: Wed, 01 Feb 2017 11:07:47 +0100 Subject: [Releasing] Why Not at least Chromium 56 for Qt 5.9? Message-ID: <20170201100747.7086163.68660.12988@oliverniebuhr.de> An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Wed Feb 1 21:13:25 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 1 Feb 2017 21:13:25 +0100 Subject: [Releasing] [Development] HEADS-UP: Branching from 'dev' to '5.9' completed Message-ID: <20170201201324.GA28779@ugly> On Thu, Jan 26, 2017 at 05:28:23AM +0000, Jani Heikkinen wrote: > We have now soft branched '5.9' from 'dev'. Target is to have final downmerge from 'dev' to '5.9' and Qt 5.9 Feature Freeze 1st of February. > > Please finalize ongoing changes in 'dev' and start using '5.9' for new changes targeted to Qt 5.9.0 release. > > Make sure all Qt 5.9.0 new features are ready in 'dev' latest Tuesday 31st January (see feature freeze checklist from https://wiki.qt.io/Qt_5_Feature_Freeze). At this time we really want to respect the feature freeze so if your feature isn't ready early enough please postpone it to 5.10 instead. So no new feature development in '5.9'; just stabilization and bug fixing. Remember also update new features page (https://wiki.qt.io/New_Features_in_Qt_5.9) > the downmerge is complete. 5.9 is in feature freeze now, while dev is 5.10 material. continue sending re-targeting requests as needed. From Kai.Koehne at qt.io Thu Feb 2 10:45:26 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 2 Feb 2017 09:45:26 +0000 Subject: [Releasing] Why Not at least Chromium 56 for Qt 5.9? In-Reply-To: <20170201100747.7086163.68660.12988@oliverniebuhr.de> References: <20170201100747.7086163.68660.12988@oliverniebuhr.de> Message-ID: > -----Original Message----- > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Google Ersatz > Sent: Wednesday, February 01, 2017 11:08 AM > To: releasing at qt-project.org > Subject: [Releasing] Why Not at least Chromium 56 for Qt 5.9? > > [...] > As Chromium 56 is already Stable and released, why are you staying with > Chromium 55? Are there some technical Issues, not enough manpower or > purely lack of time? All of the above ;) We want to get 55 update in first, which has been proven difficult,also because we need to switch to a new build system (gn). We'll try to switch to 56 or even 57 afterwards. Regards Kai From edward.welbourne at qt.io Thu Feb 2 11:02:23 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 2 Feb 2017 10:02:23 +0000 Subject: [Releasing] [Development] HEADS-UP: Branching from 'dev' to '5.9' completed In-Reply-To: <20170201201324.GA28779@ugly> References: <20170201201324.GA28779@ugly> Message-ID: On Thu, Jan 26, 2017 at 05:28:23AM +0000, Jani Heikkinen wrote: >> We have now soft branched '5.9' from 'dev'. Target is to have final >> downmerge from 'dev' to '5.9' and Qt 5.9 Feature Freeze 1st of >> February. >> >> Please finalize ongoing changes in 'dev' and start using '5.9' for >> new changes targeted to Qt 5.9.0 release. >> >> Make sure all Qt 5.9.0 new features are ready in 'dev' latest Tuesday >> 31st January (see feature freeze checklist from >> https://wiki.qt.io/Qt_5_Feature_Freeze). At this time we really want >> to respect the feature freeze so if your feature isn't ready early >> enough please postpone it to 5.10 instead. So no new feature >> development in '5.9'; just stabilization and bug fixing. Remember >> also update new features page >> (https://wiki.qt.io/New_Features_in_Qt_5.9) Oswald Buddenhagen (1 February 2017 21:13) added: > the downmerge is complete. 5.9 is in feature freeze now, while dev is > 5.10 material. continue sending re-targeting requests as needed. I see no 5.9 branch in qtnetworkauth, although qt5/.gitmodules says to use 5.9 for it. I shall prepare an initial API review, for the modules that have a 5.9 and a v5.8.0 tag, comparing the two. Then I shall get back to the vast flood of code-review that's been coming in all week ... Eddy. From edward.welbourne at qt.io Thu Feb 2 15:21:01 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 2 Feb 2017 14:21:01 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 31.1.2017 In-Reply-To: References: , , Message-ID: Jani Heikkinen reported an action item of the release team meeting: >>> * API review to be started immediately after final downmerge. I replied with (January 31, 2017 6:52 PM): >> Let me know as soon as that down-merge is done. >> Speaking of API review, review of >> https://codereview.qt-project.org/157299 >> would be welcome. If we can get it integrated - who knows - maybe some >> day someone *else* can run the scripts ... Jani Heikkinen (2 February 2017 06:17) told me: > It is done now. and so today I've duly produced initial API reviews for 5.9 (with a minor delay while I tried to get s/QtPrivete::QEnableIf<...>::Type/std::enable_if<...>::type/ ignored; but there were too many complications in that "..."): https://codereview.qt-project.org/184384 qtbase https://codereview.qt-project.org/184385 qtsvg https://codereview.qt-project.org/184386 qtdeclarative https://codereview.qt-project.org/184387 qtactiveqt https://codereview.qt-project.org/184388 qtlocation https://codereview.qt-project.org/184389 qtsensors https://codereview.qt-project.org/184390 qtconnectivity https://codereview.qt-project.org/184391 qtwayland https://codereview.qt-project.org/184392 qt3d https://codereview.qt-project.org/184393 qtserialbus https://codereview.qt-project.org/184394 qtwebsockets https://codereview.qt-project.org/184395 qtwebengine https://codereview.qt-project.org/184396 qtquickcontrols2 https://codereview.qt-project.org/184397 qtcharts https://codereview.qt-project.org/184398 qtdatavis3d https://codereview.qt-project.org/184399 qtgamepad https://codereview.qt-project.org/184400 qtscxml Please study the changes to modules you care about, Eddy. From jani.heikkinen at qt.io Wed Feb 8 11:37:01 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 8 Feb 2017 10:37:01 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 7.2.2017 In-Reply-To: References: Message-ID: Meeting minutes from Qt Release Team meeting 7th February 2017 Qt 5.9.0 Alpha status: - we aren't in the alpha yet * We haven't been able to integrate latest changes in qt5.git (in '5.9') yet * Alpha blocker list here: https://bugreports.qt.io/issues/?jql=filter%3D18348%20 - Target to get Alpha out as soon as possible * We will have Chromium 53 based qtwebengine in alpha & update it between alpha and beta Qt 5.9.0 beta & rc: - We will use new release work flow proposed by Tuukka T (http://lists.qt-project.org/pipermail/releasing/2017-January/004407.html) * No changes to old work flow before beta release * The main idea is that we will release Beta2/Preview/XYZ (naming is still a bit unclear) immediately after branching from '5.9' to '5.9.0' Coming patch level releases: - We should release 5.6.3 and 5.8.1 (in addition to Qt 5.9.0) during H1/2017 * As seen with with 5.6.2, 5.7.1 & 5.8.0 this will be challenging: doing parallel releases requires too many hardware resources & needs lots of manual testing effort * Jani to check resourcing etc for the next meeting Next meeting Tue 14th February16:00 CET br, Jani Heikkinen Release Manager irc log below: [17:00:40] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: joaijala: ping [17:00:44] jaheikki3: pong [17:01:23] jaheikki3: pong [17:01:45] Time to start qt release team meeting [17:01:51] On agenda today: [17:02:02] Qt 5.9.0 Alpha status [17:02:10] Any additional item to the agenda? [17:02:20] 5.8.1 timelime [17:02:25] 5.6.3 timeline [17:03:43] thiago: I haven't discussed those internally yet, Ok to check those in the next meeting? [17:04:16] we can discuss now [17:04:38] at least which one we'd like to get out first, etc. [17:04:45] thiago: I would like to check our RnD mgmt opinion before that [17:04:48] I'd say Alpha is not there yet, we have QML crashes pending 5.8 merge and unclear font issues [17:05:45] I think we can have an opinion too [17:05:56] R&D and others can comment after we emit an opinion [17:06:07] you don't have to have one, but this group can [17:06:30] or even then, your not having an opinion is not a reason to skip the dsicussion [17:06:45] Ok, fair enough ;) [17:06:59] Let's shortly discuss those as well [17:07:28] But first Qt 5.9 Alpha status: [17:07:53] As fkleint wrote we aren't in the alpha yet [17:08:15] yeah [17:08:35] We haven't been able to integrate latest changes in qt5.git (in '5.9') yet [17:09:21] QTBUG-58683 & QTBUG-58556 is preventing that at the moment [17:10:18] first one is under work by lars, second one we have a fix in '5.8' & waiting for merge [17:11:30] There is also some other blockers in alpha blocker list (https://bugreports.qt.io/issues/?jql=filter%3D18348%20) but to be honest I haven't checked if all those are really alpha blockers or not [17:11:56] doesn't look like I can help with either [17:11:58] API review is also ongoing, thanks to eddy. See http://lists.qt-project.org/pipermail/development/2017-February/028639.html [17:13:19] And first we need to get latest changes in qt5.git to see where we are with alpha. But we should be quite close because at alpha we will release only src packages as usual [17:13:34] Any comments / questions ? [17:14:34] note the timing of qtwebengine alpha is interesting. It is probably better to do it with the current 53-based branch, once the 55-based goes in, a few things are going to be disabled while they stabalize, and having Windows builds disable probably doesn't make sense in the alpha [17:14:55] so before packaging just ping me and ask for a sha :D [17:15:25] carewolf: ok, I'll try to remember that ;) [17:15:42] Ok, it was all about 5.9 at this time [17:16:05] Then those patch level releases: 5.8.1 & 5.6.3 [17:16:07] carewolf: what are the chances of getting 55 before the alpha? [17:16:40] before we move on, is there anything we change in our workflow based on what Tuukka requested? [17:16:44] depends on the timing of the alpha. It is mostly ready, but a number of tests and build configurations are always going to take time to ensure works [17:16:49] do we do a beta 1 and 2? [17:17:15] carewolf: are there any feature changes in the module with the update? [17:17:33] sort-of but ofcourse not api visible [17:18:23] it is mainly web API features, and very few and minor ones of those [17:18:58] thiago: i think we should try that. For me it seems there weren't any objections for that, it was just naming which caused discussion [17:20:23] ok [17:20:37] but no changes at least until 5.9.0 branching time? [17:20:44] when do we branch? [17:21:12] carewolf: I'd say it's mostly ok to get it in for beta, but please make sure it happens early so it doesn't disrupt package generation [17:21:45] well hopefully next week, which is why I was afraid to conflict with alpha [17:22:16] yes, no changes until 5.9.0 branching time. That should be ~ mid/end of April [17:24:52] carewolf: we are trying to get alpha out as soon as possible so I propose to have that 53 based WE in alpha & update it between alpha and beta as you proposed [17:25:20] I agree [17:25:54] sounds reasonable [17:26:28] Ok, something else related to 5.9? [17:28:02] Ok now those patch level releases: 5.8.1 & 5.6.3 [17:28:41] thiago: did you have something on your mind related to those? [17:28:45] I think we should do 5.6.3 first [17:28:56] how difficult was it to do 5.6.2 last time? [17:29:34] thiago: actually it was quite hard to do it at same time whit Qt 5.8.0 [17:30:03] and there were 5.7.1 as well [17:30:18] what was the difficulty? Running both at the same time? [17:30:24] or were there problems? [17:30:24] Biggest challenges were with resources, both human and HW [17:31:22] doing paraller releases takes so much hw resources & needs lot's of manual testing effort as wekk [17:31:55] then I propose we do 5.6.3 builds first, and only after the release do we start 5.8.1 (or 5.9.0 beta1, TBD) [17:32:09] since 5.9.0 alpha does not require builds, we could get started soon [17:34:13] well, even we don't release binaries our ci system is doing builds for alpha as well. But it is true that there isn't that much packaging & RTA at alpha phase [17:35:00] But on the other hand we need to do builds for 5.9 not to be able to start offering binary snapshots as soon as possible. That is essential for keeping the schedules [17:35:59] So that's why I wouldn't start 5.6.3 yet, maybe after we have first binary snapshot available for qt 5.9.0 [17:37:42] but if that means no 5.8.1 either, we have to be very clear in out messaging that 5.9.0 is a bug-fix release, or we will be giving the impression we are not doing bug-fix releases anymore [17:38:24] I'd like to get the 5.6.3 release out as soon as we can [17:38:33] before 5.9.0 beta if possible [17:38:44] thiago: any reason for that? [17:38:45] thiago: may I ask why such hurry with 5.6.3 release? [17:38:54] it's been 3 months since we released 5.6.2 [17:39:00] also after 5.9.0 wouldn't that be summer-break? [17:39:51] that makes 5.9.0 quite late, actually [17:40:10] isn't the timing of 5.9.0 for last day of may? [17:40:14] I'd hope to release it by mid-May, so we have one more month before the break [17:40:31] but still, we need to release 5.6.3 and 5.8.1 before the break [17:40:36] Well: for me the most important thing is to get 5.9 out as planned. And then it is 31st May [17:40:53] not arguing with that priority [17:40:58] but we need the other releases too [17:41:51] we may skip 5.8.2 (yes, 5.8), but we can't skip 5.8.1 [17:43:56] i think there isn't that hurry with 5.6.3, at least I don't know any that urgent fixed. But 5.8.1 is hard: At the moment 5.8.0 seems to be quite good but as you wrote we most probably have to do it. but doing 3 releases during this spring will be really hard... [17:44:13] fixed==fixes [17:45:09] I know, but I don't think we have an option [17:45:26] we're not in a hurry for 5.6.3, but I think it takes priority over 5.8.1. We can discuss that [17:45:36] but as I said, we need both out by the end of June [17:46:53] true, otherwise it will be end of august or even beginning of september... [17:47:16] ok, so I think we need you to take a look at resourcing and R&D now [17:47:31] can you check what is feasible, for next week? [17:47:48] yes I can [17:48:11] I'll do that & let's discuss more in next weeks meeting [17:49:12] Ok, I think this was all at this time [17:49:17] thanks [17:49:42] Let's have new meeting Tue 14th February 16:00 CET [17:49:47] Thanks & bye! [17:49:58] bye From tuukka.turunen at qt.io Fri Feb 10 11:59:56 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 10 Feb 2017 10:59:56 +0000 Subject: [Releasing] Focusing bug fixes to 5.9 branch and patch releases during H1/17 Message-ID: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Hi, Short summary: The Qt Company has decided to focus development effort to 5.9 and dev branches in order to reach the planned timeline for Qt 5.9 release and make improvements in the CI system. Next scheduled patch level release would be Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with just the security fix(es) added. Qt 5.8.0 looks to be a good and successful release. It has already been downloaded 150.000 times even though it was released just two weeks ago. The reception has been good overall and there are no blockers reported based on the release. Qt 5.9 and subsequent releases will leverage the new configuration system and other major improvements introduced with it, as well as add new functionality to make Qt even better. It took us a more time than planned to get Qt 5.8 out and because of that we are already past Qt 5.9 feature freeze and approaching the alpha release soon. Looking into the reasons why Qt 5.8.0 was delayed there are 3 items that had a significant effect: 1. We did not keep the feature freeze properly as there were some items we wanted to get in – doing so we should have replanned the whole release time, but we tried to keep schedule and failed. 2. We were not able to focus enough to Qt 5.8 finalization as there was quite a lot of effort going still to Qt 5.6.x and 5.7.x patch releases in parallel – and our systems and processes are not yet good enough for this. 3. We have had some issues in the CI system that cause integrations to fail and thus increase system load – these are now being addressed (getting new HW in place, change to a better virtualization platform, use local disks instead of central disk, reduce number of flaky tests, etc). We believe it will be possible to significantly reduce the time from feature freeze to release. To reach this we need to improve the items that have been problematic with Qt 5.8 and other releases. After we have done the improvements, it will be easier to keep the timelines and also be more productive. We absolutely do not want to rush a new release out with severe bugs in it – not now and not in the future – for this reason we want to focus into the processes and systems part and allow more efficient release creation. First we want to be able to reach the current 17 weeks timeline from FF to release with Qt 5.9. After that we want to reduce it gradually to 10-12 weeks (for a new minor release of Qt). Increased productivity will allow us to make more patch releases than before. In the CI system side we have major improvements happening during this year. We will be purchasing more blades and other HW during H1/17, which will add capacity, so we will be able to run more parallel integrations. We are also looking into changing the system architecture away from central disk into using local ssd for build machines. This is expected to bring improvements to both performance and reliability (especially now as we have had issues with disks failing despite the disk system still being in the mid of its life-cycle). Third item we are looking into is change of the virtualization platform, which we hope will bring improvements in stability as well as new capabilities. Arranging enough time to implement the improvements in our systems as well as keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately means that we can’t make any scheduled patch releases until June, after Qt 5.9 is out. We will keep the ability to release patch release for urgent security vulnerabilities, as always. Such release would be on top of the previous patch release and not include all other changes in the corresponding branch. Even with a lot more help from community than before, making a scheduled Qt 5.8.1 release parallel with Qt 5.9 has impact to the system load as well as to the work needed from the release team and others. I am well aware that a Qt 5.8.1 release would be beneficial, but making one now would impact Qt 5.9 schedule and our capability to improve CI system stability. Qt 5.6.3 LTS patch release is done straight after Qt 5.9 release, but not before. After the Qt 5.9.0 in May we should then focus into making Qt 5.9.1 release instead of making Qt 5.8.1 any more as Qt 5.9.0 is already out. With the CI improvements in place, we should definitely be able to make more than one patch release for Qt 5.9. As a scheduled Qt 5.8.1 release is not planned, should we start pushing fixes directly to 5.9 branch now? It would reduce the workload as we do not need to first integrate changes into 5.8 and then merge upwards to 5.9. It would also reduce the time it takes to get fixes into to 5.9 and dev as well as reduce the load to the CI system as less integrations are needed. We can keep 5.8 branch open for a while still similarly as 5.6 is in case there is some fix that must be in the 5.8 branch. Let’s discuss in the next release team meeting (Tuesday 14th Feb 16.00 CET) if pushing fixes to 5.9 branch directly would be good approach. Yours, Tuukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Fri Feb 10 16:21:26 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 10 Feb 2017 15:21:26 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08>, Message-ID: Hi, To sum the discussion here and also on gerrit up : There's no consensus on making [ChangeLog] entries mandatory, or making the [ChangeLog] field enabled by default. Anyhow, Ossi had an interesting third suggestion on https://codereview.qt-project.org/#/c/183244/: > how about this for an idea: we add a new gerrit category "ChangeLog" which needs a +1. it would be auto-set by the bot if a changelog file is touched, otherwise a reviewer needs to set it. easy to implement, reliable (well, as much as the reviewers), and adds no noise to the commit messages. I understand that this would not be hard to do. This way nobody is forced to write changelog entries, but it requires a conscious click from the reviewer to say 'Yes, this does _not_ use a ChangeLog'. Any strong opinion against this? Kai > -----Original Message----- > From: Schumann, Spencer [mailto:Spencer.Schumann at echostar.com] > Sent: Thursday, January 26, 2017 5:11 PM > To: Kai Koehne ; Oswald Buddenhagen > ; development at qt-project.org; > releasing at qt-project.org > Subject: Re: [Releasing] [Development] Change file process & improvement > proposal > > > > For the sanity bot, either we decide that _every_ change has a > > [ChangeLog], or we try to make the bot intelligent > > > enough to decide whether a commit needs a change log, or not. Parts of > > the discussion so far makes me think > > > that this will be an uphill battle though. > > > > So, any strong opinion against enforcing a [ChangeLog] line, with > "[ChangeLog] -" for commits that don't need one? > > I doubt the decision on whether a changelog is needed could be adequately > automated. Sometimes, even a one character change might need a detailed > changelog. > > Isn't this something that could and should be enforced via the code review > process? If reviewers see that the changelog is missing or inadequate, they > can reject the change. > > > > > > - Spencer > > > ________________________________ > > From: Releasing project.org> on behalf of Kai Koehne > Sent: Thursday, January 26, 2017 5:28:30 AM > To: Oswald Buddenhagen; development at qt-project.org; releasing at qt- > project.org > Subject: Re: [Releasing] [Development] Change file process & improvement > proposal > > > > > -----Original Message----- > > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Oswald Buddenhagen > > Sent: Thursday, January 26, 2017 12:52 PM > > To: development at qt-project.org; releasing at qt-project.org > > Subject: Re: [Releasing] [Development] Change file process & > > improvement proposal > > > > On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote: > > > I don't know what you're saying, much less why it's supposed to be > > > the obvious interpretation. A "tagged commit" is presumably v5.7.0 > > > or similar; why should a commit without an amends line be assumed to > > > relate to one of these ? > > > > > i used "tagged commit" as a shorthand for "a commit which is reachable > > from a tag", which should be fairly clear from the context. i.e., "git > > tag --contains " returns something. > > Well, I had a hard time deciphering this, too. > > > > Anyway, this all feels like we get side-tracked in details. To reiterate: > > - We do (still) have a problem with our ChangeLog files > * The quality of the entries, and the scope, greatly differs (between > modules) > * We do have a problem getting them in place on time for a release > > Jani's proposal is to fix parts of this is to encourage committers and reviewers > to write [ChangeLog] entries as part of the commit. This could be encouraged > by > * Enabling the [ChangeLog] line by default in the commit template > * Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx) > > For the sanity bot, either we decide that _every_ change has a [ChangeLog], > or we try to make the bot intelligent enough to decide whether a commit > needs a change log, or not. Parts of the discussion so far makes me think that > this will be an uphill battle though. > > So, any strong opinion against enforcing a [ChangeLog] line, with > "[ChangeLog] -" for commits that don't need one? > > Regards > > Kai > > > _______________________________________________ > > Releasing mailing list > > Releasing at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/releasing > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing > From charleyb123 at gmail.com Sat Feb 11 15:08:18 2017 From: charleyb123 at gmail.com (charleyb123 .) Date: Sat, 11 Feb 2017 07:08:18 -0700 Subject: [Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Message-ID: On Fri, Feb 10, 2017 at 3:59 AM, Tuukka Turunen wrote: > Short summary: The Qt Company has decided to focus development effort to 5.9 > and dev branches in order to reach the planned timeline for Qt 5.9 release > and make improvements in the CI system. , > In the CI system side we have major improvements happening during this year. > We will be purchasing more blades and other HW during H1/17, which will add > capacity, so we will be able to run more parallel integrations. Perhaps related, I think it might be a good idea to target more closely new compiler releases from Microsoft. In the past several years they have shifted to an early-and-frequent update model, and organizations are adapting to more aggressively take advantage of new C++ language features, and to target platform technology changes. For example MSVC++2017 (version 15) was previewed in March-2016; has had three major updates; went to RC in Nov-2016; and is announced for launch in March-2017 (see: http://www.zdnet.com/article/microsoft-to-release-visual-studio-2017-on-march-7/). That tool chain was actually at very high quality since its launch a year ago (this is their new release model), and I'm aware of companies that have relied on that version for commercial development since its preview access. IMHO, not providing binaries for that platform is a hindrance to Qt adoption. Intel provides chips to OEMs before launch, and companies regularly provide pre-release technology access to allow OEMs time to integrate with their products, and I'm suggesting Qt should similarly support this type of early-access (we can call it "pre-release" access if we want). Yes, developers can build their own Qt binaries; but this is a non-trivial point of friction, and you need to install Python, and become familiar with config, etc. The "experts" have success here, but we continue to see email threads on stumped non-experts unable to get working Qt binaries. If we want friction-less Qt adoption (perhaps even for casual and accidental developer exposure), we should just provide the binaries. Yes, I'm very aware that some companies are on the slow-stable upgrade model and need long support for older compilers. I'm talking about another market where requirements and competitive advantage demand access to new tooling, (consistent with the fast pace of web technology advances and the need for security patches and updates). Under this proposal, Qt binaries would be available for MSVC++2018 when it is previewed, or at least most certainly when it goes to RC. Waiting for it to deploy is *way* too late, as the new Microsoft release model suggests that developers have been integrating the compiler into their tooling for a year before Qt "shows up". --charley From torben at dannhauer.info Sun Feb 12 20:00:38 2017 From: torben at dannhauer.info (Torben Dannhauer) Date: Sun, 12 Feb 2017 20:00:38 +0100 Subject: [Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Message-ID: <008201d28562$4cdb10c0$e6913240$@dannhauer.info> Charley, Thanks for the input. I totally agree with you. I proposed some years ago an Preview/RC based adoption of Qt, but this was refused. I think Qt need to adopt as early as possible to new VS releases to be ready once it is released as final. "*way* to late" is eactly the wording I would use to describe the current adoption speed. Best regards, Torben -----Ursprüngliche Nachricht----- Von: Releasing [mailto:releasing-bounces+torben=dannhauer.info at qt-project.org] Im Auftrag von charleyb123 . Gesendet: Samstag, 11. Februar 2017 15:08 An: Tuukka Turunen Cc: development at qt-project.org; releasing at qt-project.org Betreff: Re: [Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 On Fri, Feb 10, 2017 at 3:59 AM, Tuukka Turunen wrote: > Short summary: The Qt Company has decided to focus development effort > to 5.9 and dev branches in order to reach the planned timeline for Qt > 5.9 release and make improvements in the CI system. , > In the CI system side we have major improvements happening during this year. > We will be purchasing more blades and other HW during H1/17, which > will add capacity, so we will be able to run more parallel > integrations. Perhaps related, I think it might be a good idea to target more closely new compiler releases from Microsoft. In the past several years they have shifted to an early-and-frequent update model, and organizations are adapting to more aggressively take advantage of new C++ language features, and to target platform technology changes. For example MSVC++2017 (version 15) was previewed in March-2016; has had three major updates; went to RC in Nov-2016; and is announced for launch in March-2017 (see: http://www.zdnet.com/article/microsoft-to-release-visual-studio-2017-on-marc h-7/). That tool chain was actually at very high quality since its launch a year ago (this is their new release model), and I'm aware of companies that have relied on that version for commercial development since its preview access. IMHO, not providing binaries for that platform is a hindrance to Qt adoption. Intel provides chips to OEMs before launch, and companies regularly provide pre-release technology access to allow OEMs time to integrate with their products, and I'm suggesting Qt should similarly support this type of early-access (we can call it "pre-release" access if we want). Yes, developers can build their own Qt binaries; but this is a non-trivial point of friction, and you need to install Python, and become familiar with config, etc. The "experts" have success here, but we continue to see email threads on stumped non-experts unable to get working Qt binaries. If we want friction-less Qt adoption (perhaps even for casual and accidental developer exposure), we should just provide the binaries. Yes, I'm very aware that some companies are on the slow-stable upgrade model and need long support for older compilers. I'm talking about another market where requirements and competitive advantage demand access to new tooling, (consistent with the fast pace of web technology advances and the need for security patches and updates). Under this proposal, Qt binaries would be available for MSVC++2018 when it is previewed, or at least most certainly when it goes to RC. Waiting for it to deploy is *way* too late, as the new Microsoft release model suggests that developers have been integrating the compiler into their tooling for a year before Qt "shows up". --charley _______________________________________________ Releasing mailing list Releasing at qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing From edward.welbourne at qt.io Mon Feb 13 11:02:36 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 13 Feb 2017 10:02:36 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08>, , Message-ID: Kai Koehne (10 February 2017 16:21) wrote: > To sum the discussion here and also on gerrit up : There's no > consensus on making [ChangeLog] entries mandatory, or making the > [ChangeLog] field enabled by default. Indeed. > Anyhow, Ossi had an interesting third suggestion on > https://codereview.qt-project.org/#/c/183244/: >> how about this for an idea: we add a new gerrit category "ChangeLog" >> which needs a +1. it would be auto-set by the bot if a changelog file >> is touched, otherwise a reviewer needs to set it. easy to implement, >> reliable (well, as much as the reviewers), and adds no noise to the >> commit messages. Note that this speaks of "a changelog file" rather than tags in commits; I do think this is a better approach, although I do also exhort everyone to keep your changelog files organised on some *other* model than "make each addition at the end" - e.g. sort by category, like the existing ChangeLog tags, and put related changes near each other - since any model that makes all additions at the same place *will* get conflicts all the time. Anything to ensure contemporary changes happen in different places is better than always conflicting. > I understand that this would not be hard to do. This way nobody is > forced to write changelog entries, but it requires a conscious click > from the reviewer to say 'Yes, this does _not_ use a ChangeLog'. > > Any strong opinion against this? Not from this quarter; if Ossi can teach Gerrit to remind me to think about whether each change, that lacks one, wants a change log; that sounds like a good solution to me. Be sure to include a link to the wiki page that says what tags to use and what should be in the change log. Eddy. From sean.harmer at kdab.com Wed Feb 15 10:36:33 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 15 Feb 2017 09:36:33 +0000 Subject: [Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Message-ID: <1827326.MVTkkocP57@cartman> First of all, apologies for not being able to make the release meeting yesterday. I was in a workshop all day. For the record I think skipping 5.8.1 is a big mistake. I would much rather delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and try for a quick 5.9.0. Why would releasing 5.8.1 take as long as a .0 release if nothing much has changed in the packaging and build system? I think our users, your paying customers, would rather have a .1 release than another .0. In our experience, many customers explicitly do not use .0 releases. So for these we are condemning them to wait 3/4 of a year or so to be able to go from 5.7.1 to 5.9.1. Imho, a bug fix release should take priority over a feature release. Also, the number of downloads is no measure of the quality of a release. There are plenty of fixes available on the 5.8 branch across pretty much all modules ready to go now. I appreciate the packages will still need testing, but surely this is mainly functional testing for 5.8.1 given the packaging should not have changed since 5.8.0. We could branch 5.8.1 now and be generating the first set of test packages before the 5.9 beta. The reason of not wanting to do a bug fix release in conjunction with a feature release due to limited resources is particularly galling when we read yesterday that TQC have decided to release an *old* 5.5.1 release for Vx Works. Those resources could have been used towards a Qt 5.8.1 over the last month. There is still a very real risk that we will be late with the 5.9.0 release given the large changes to the configuration system in 5.9. Having a 5.8.1 release is a way to mitigate that risk too. It wasn't so long ago Tuukka, that you wanted to do a quick 5.8.1 release after there had been such a huge delay between 5.7.0 and 5.7.1. Please do not go back on this and let the users have a bug fix release. Are there really features in 5.9 that customers cannot live without for an extra 4-6 weeks whilst we prepare a 5.8.1 release? I very much doubt it. Kind regards, Sean On Friday 10 February 2017 10:59:56 Tuukka Turunen wrote: > Hi, > > Short summary: The Qt Company has decided to focus development effort to 5.9 > and dev branches in order to reach the planned timeline for Qt 5.9 release > and make improvements in the CI system. Next scheduled patch level release > would be Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security > vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with just the > security fix(es) added. > Qt 5.8.0 looks to be a good and successful release. It has already been > downloaded 150.000 times even though it was released just two weeks ago. > The reception has been good overall and there are no blockers reported > based on the release. Qt 5.9 and subsequent releases will leverage the new > configuration system and other major improvements introduced with it, as > well as add new functionality to make Qt even better. > It took us a more time than planned to get Qt 5.8 out and because of that we > are already past Qt 5.9 feature freeze and approaching the alpha release > soon. Looking into the reasons why Qt 5.8.0 was delayed there are 3 items > that had a significant effect: 1. We did not keep the feature freeze > properly as there were some items we wanted to get in – doing so we should > have replanned the whole release time, but we tried to keep schedule and > failed. 2. We were not able to focus enough to Qt 5.8 finalization as there > was quite a lot of effort going still to Qt 5.6.x and 5.7.x patch releases > in parallel – and our systems and processes are not yet good enough for > this. 3. We have had some issues in the CI system that cause integrations > to fail and thus increase system load – these are now being addressed > (getting new HW in place, change to a better virtualization platform, use > local disks instead of central disk, reduce number of flaky tests, etc). > We believe it will be possible to significantly reduce the time from feature > freeze to release. To reach this we need to improve the items that have > been problematic with Qt 5.8 and other releases. After we have done the > improvements, it will be easier to keep the timelines and also be more > productive. We absolutely do not want to rush a new release out with severe > bugs in it – not now and not in the future – for this reason we want to > focus into the processes and systems part and allow more efficient release > creation. First we want to be able to reach the current 17 weeks timeline > from FF to release with Qt 5.9. After that we want to reduce it gradually > to 10-12 weeks (for a new minor release of Qt). Increased productivity will > allow us to make more patch releases than before. > In the CI system side we have major improvements happening during this year. > We will be purchasing more blades and other HW during H1/17, which will add > capacity, so we will be able to run more parallel integrations. We are also > looking into changing the system architecture away from central disk into > using local ssd for build machines. This is expected to bring improvements > to both performance and reliability (especially now as we have had issues > with disks failing despite the disk system still being in the mid of its > life-cycle). Third item we are looking into is change of the virtualization > platform, which we hope will bring improvements in stability as well as new > capabilities. > Arranging enough time to implement the improvements in our systems as well > as keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately > means that we can’t make any scheduled patch releases until June, after Qt > 5.9 is out. We will keep the ability to release patch release for urgent > security vulnerabilities, as always. Such release would be on top of the > previous patch release and not include all other changes in the > corresponding branch. Even with a lot more help from community than before, > making a scheduled Qt 5.8.1 release parallel with Qt 5.9 has impact to the > system load as well as to the work needed from the release team and > others. > I am well aware that a Qt 5.8.1 release would be beneficial, but making one > now would impact Qt 5.9 schedule and our capability to improve CI system > stability. Qt 5.6.3 LTS patch release is done straight after Qt 5.9 > release, but not before. After the Qt 5.9.0 in May we should then focus > into making Qt 5.9.1 release instead of making Qt 5.8.1 any more as Qt > 5.9.0 is already out. With the CI improvements in place, we should > definitely be able to make more than one patch release for Qt 5.9. > As a scheduled Qt 5.8.1 release is not planned, should we start pushing > fixes directly to 5.9 branch now? It would reduce the workload as we do not > need to first integrate changes into 5.8 and then merge upwards to 5.9. It > would also reduce the time it takes to get fixes into to 5.9 and dev as > well as reduce the load to the CI system as less integrations are needed. > We can keep 5.8 branch open for a while still similarly as 5.6 is in case > there is some fix that must be in the 5.8 branch. Let’s discuss in the next > release team meeting (Tuesday 14th Feb 16.00 CET) if pushing fixes to 5.9 > branch directly would be good approach. > Yours, > > Tuukka > > > > > -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From me at the-compiler.org Wed Feb 15 11:00:37 2017 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 15 Feb 2017 11:00:37 +0100 Subject: [Releasing] [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1827326.MVTkkocP57@cartman> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <1827326.MVTkkocP57@cartman> Message-ID: <20170215100037.bvzve4pfcrbijlz2@tonks> * Sean Harmer [2017-02-15 09:36:33 +0000]: > For the record I think skipping 5.8.1 is a big mistake. I would much rather > delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and try for > a quick 5.9.0. FWIW at least QtWebEngine does have a lot of regressions in 5.8: https://bugreports.qt.io/browse/QTBUG-58779 (P1) https://bugreports.qt.io/browse/QTBUG-58362 (P1) https://bugreports.qt.io/browse/QTBUG-58748 (P2) https://bugreports.qt.io/browse/QTBUG-58381 (P1) https://bugreports.qt.io/browse/QTBUG-58333 (P2) https://bugreports.qt.io/browse/QTBUG-58544 (P2, but makes