From nospam at vuorela.dk Mon Jan 2 21:32:24 2017 From: nospam at vuorela.dk (Sune Vuorela) Date: Mon, 2 Jan 2017 20:32:24 +0000 (UTC) Subject: [Releasing] Release blocker for 5.8.0 Message-ID: Hi It has just come to my attention that 5.8.0 has been made unpackageble by linux distributions. I do think this makes 5.8.0 still unfit for release. Unfortunately, the relevant subsystem maintainer has just said "meh. I don't care", so I'm now trying to appeal to the rest of the world that we either get a revert, or actually some kind of fix. The issue in question is https://bugreports.qt.io/browse/QTBUG-57803 So I'm hoping that the Qt project still wants to be a opensource community friendly project. and yes. we strip the binaries. /Sune From adamm at zombino.com Mon Jan 2 22:44:43 2017 From: adamm at zombino.com (Adam Majer) Date: Mon, 2 Jan 2017 22:44:43 +0100 Subject: [Releasing] Release blocker for 5.8.0 In-Reply-To: References: Message-ID: <2fd39dee-0f89-7a7f-9ac4-975199cd540a@zombino.com> On 02/01/17 09:32 PM, Sune Vuorela wrote: > Hi > > It has just come to my attention that 5.8.0 has been made unpackageble > by linux distributions. I do think this makes 5.8.0 still unfit for > release. > https://bugreports.qt.io/browse/QTBUG-57803 Yes, this needs to be fixed. The change is "lazy" and just throws current functionality away. Now it has to be patched so qt.conf can be shipped in some shared directory instead. :/ Not sure this belongs on this ML though. - Adam From tuukka.turunen at qt.io Tue Jan 3 09:02:21 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 3 Jan 2017 08:02:21 +0000 Subject: [Releasing] [Development] Proposal to adjust release candidate process In-Reply-To: References: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> , <2265621.Hc078j5Qty@tjmaciei-mobl1> Message-ID: Hi, Perhaps it is best to talk with marketing about the name of the "release done immediately after branching to the .0 release branch". Reading the discussion, it seems that other than the name we are well aligned. Our current process has "Release candidate" 2 weeks prior to the Final release (see: https://wiki.qt.io/Qt5Releasing). If we now have the beta2/preview/othername release 4 weeks before the final, our schedule is the following: Phase Timing Feature freeze T-17 weeks Alpha release T-13 weeks Beta release T-8 weeks Soft string freeze T-6 weeks Hard string freeze T-5 weeks Beta2/Preview/XYZ T-4 weeks Final release T In addition to the main phases, there will be snapshots regularly for testing. During the final weeks before the release these snapshots are then considered as possible final release unless testing reveals a need to change something. This part is unchanged. The main benefit for the change is providing a very close to final package for users to test earlier. During the 4 weeks after Beta there is always a lot of improvements, but after branching to the release branch we should focus only for the high-priority error corrections and polishing the documentation (if not already done earlier). PS. I would like to shorten the overall duration of the release creation to 12 weeks from FF to final. I think that being more strict about the FF and by having all the needed configurations done early enough, we should be able to cut the time between FF and Alpha as well as between Alpha and Beta. But that is something we can discuss later. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Simon Hausmann Sent: perjantaina 23. joulukuuta 2016 19.02 To: Thiago Macieira ; development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case the branch makes no difference and beta is a better name. Simon ________________________________ From: Development > on behalf of Thiago Macieira > Sent: Friday, December 23, 2016 4:42:12 PM To: development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann escreveu: > I find that the branch is relevant in this context, as it relates to the > amount of patches going in. The amount of patches going in is IMO related > to the probably of introducing regressions. The process around the release > branch, as opposed to the "minor branch", as proven to be a useful > mechanism for reducing the churn and making people ask themselves: Do I > really want this change in this release or can it wait? > > So from what I think is one metric of quality (not the only one of course), > the naming of release candidate is more meaningful. How about this, then? We release beta2 from the 5.n branch right before the 5.n.0 branch is created (or finally branches off). It accomplishes the same thing that Tuukka wanted: a release containing the code that is in the 5.n.0 branch at the moment it is created, not a few weeks after with some round of work. And I really mean "the code that is in the 5.n.0 branch". Since the two branches at the same at that point, it's only a semantic difference which one we created the beta2 release from. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Tue Jan 3 12:59:48 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 3 Jan 2017 11:59:48 +0000 Subject: [Releasing] Release blocker for 5.8.0 In-Reply-To: <2fd39dee-0f89-7a7f-9ac4-975199cd540a@zombino.com> References: <2fd39dee-0f89-7a7f-9ac4-975199cd540a@zombino.com> Message-ID: > -----Original Message----- > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Adam Majer > Sent: Monday, January 02, 2017 10:45 PM > To: releasing at qt-project.org > Subject: Re: [Releasing] Release blocker for 5.8.0 > > On 02/01/17 09:32 PM, Sune Vuorela wrote: > > Hi > > > > It has just come to my attention that 5.8.0 has been made unpackageble > > by linux distributions. I do think this makes 5.8.0 still unfit for > > release. > > > https://bugreports.qt.io/browse/QTBUG-57803 > > Yes, this needs to be fixed. The change is "lazy" and just throws current > functionality away. Now it has to be patched so qt.conf can be shipped in > some shared directory instead. :/ Note that the change in question mentioned in QTBUG-5803 is _not_ in 5.8.0, but in the 5.8 branch (possible 5.8.1). So this can't be a blocker for 5.8.0, unless the analysis of the root cause in QTBUG-57803 is wrong. Regards Kai From jani.heikkinen at qt.io Wed Jan 4 06:41:13 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 4 Jan 2017 05:41:13 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 3.1.2017 Message-ID: Meeting minutes from Qt Release Team meeting 3rd January 2017 Qt 5.8.0 status: - Qt 5.8.0 rc under testing. Bugs reported but nothing really alarming * Some new blockers in blocker list, see https://bugreports.qt.io/issues/?filter=18160 ** Most of those we have a fix already available, hoping we could get fixes for remaining ones during this week - Target to get new rc snapshot for testing at the beginning of next week - Target schedule: Final 17th January, see https://wiki.qt.io/Qt_5.8_Release Next meeting 10th January 16:00 CET br, Jani Heikkinen Release Manager irc log below: [17:00:42] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:00:56] jaheikki3: pong, with Happy New Year [17:01:39] jaheikki3: pong [17:02:27] Happy new year to all! It's time to start qt release team meeting [17:02:35] On agenda today: [17:02:42] Qt 5.8.0 status [17:02:50] Any additional item to the agenda? [17:04:14] pong [17:04:26] Ok, let's start [17:05:32] Qt 5.8.0 rc under testing. Bugs reported but nothing really alarming [17:06:00] Some new blockers in blocker list, see https://bugreports.qt.io/issues/?filter=18160# [17:06:48] Most of those we have a fix already available, hoping we could get fixes for remaining ones during this week [17:07:24] That way we could create new rc snapshot for testing at the beginning of next week [17:08:09] & be able to keep the official release schedule (final 17th January), see https://wiki.qt.io/Qt_5.8_Release [17:08:51] That is all about 5.8.0 status at the moment. Any comments/questions? [17:09:34] are there any plans for a 5.6.3? [17:10:16] fkleint: not at the moment. Let's focus to 5.8.0 & 5.9 FF now & check that a bit later [17:10:24] ok [17:12:08] Ok, that's all at this time. Let's have new meeting Tue 10 Jan as planned. Then we should know if we can keep the Qt 5.8.0 schedule [17:12:29] Thanks for your participation. Bye! [17:13:05] bye From edward.welbourne at qt.io Wed Jan 4 15:43:57 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 4 Jan 2017 14:43:57 +0000 Subject: [Releasing] Qt 5.8.0 API review In-Reply-To: References: , , , , , Message-ID: Back on the 7th of November 2016 I announced: > With the 5.8.0 release now close at hand, I've updated the API reviews: I've now updated these for the actual 5.8.0 branch (fetched this morning): https://codereview.qt-project.org/170634 - qtbase https://codereview.qt-project.org/170635 - qtdeclarative https://codereview.qt-project.org/170636 - qtactiveqt https://codereview.qt-project.org/170637 - qtmultimedia https://codereview.qt-project.org/170640 - qtconnectivity https://codereview.qt-project.org/170641 - qtwayland https://codereview.qt-project.org/170642 - qt3d https://codereview.qt-project.org/170643 - qtserialbus https://codereview.qt-project.org/170644 - qtserialport https://codereview.qt-project.org/170645 - qtandroidextras https://codereview.qt-project.org/170646 - qtwebsockets https://codereview.qt-project.org/170647 - qtwebengine https://codereview.qt-project.org/170648 - qtcanvas3d https://codereview.qt-project.org/170649 - qtcharts https://codereview.qt-project.org/170650 - qtdatavis3d https://codereview.qt-project.org/170652 - qtscxml https://codereview.qt-project.org/176059 - qtquickcontrols2 > Note that, although Gerrit thinks of these as proposals to change 5.8, > they are actually commits based on tag v5.7.0 showing what's changed in 5.8.0's > API, with lots of boring bits filtered out. As before, it would be nice if some of these did in fact get reviewed - and J-P Nurmi gets the prize for having done that before I even sent this - indeed, within a minute of the new push :-) Gerrit should make it easy to compare the new patch set to the previous, which should make review easy - if your module hasn't changed too drastically since the previous review in early November ... Eddy. From edward.welbourne at qt.io Wed Jan 4 16:03:57 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 4 Jan 2017 15:03:57 +0000 Subject: [Releasing] [Development] Proposal to adjust release candidate process In-Reply-To: References: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> , <2265621.Hc078j5Qty@tjmaciei-mobl1> , Message-ID: Since general churn while "stabilising" is a central part of the discussion, let's take a look at the change, since my early November API review push, in just the not-obviously-boring[*] changes to API-related headers. ([*] If you can see any changes in the reviews that a dumb script could be taught to recognise as boring, please do bring them to my attention.) These are the results of git diff | wc between November's patch sets and today's: lines words characters * qtbase 1696 7245 70274 * qtscxml 486 1455 19930 * qtwayland 451 1391 16252 * qtmultimedia 415 1103 14480 * qt3d 91 320 3263 * qtwebengine 41 181 1433 * qtconnectivity 33 158 1227 * qtdeclarative 32 108 1389 * qtquickcontrols2 20 125 786 * qtandroidextras 18 117 728 * qtactiveqt 18 106 663 * qtcanvas3d 18 98 621 * qtcharts 18 89 594 * qtdatavis3d 13 32 476 * qtwebsockets 13 32 225 * qtserialport 12 31 243 (with apologies to those whose mailers are too clever about spacing). Some of that is git diff's own over-head, of course; so most modules are quite sensible - but those first four, especially qtbase, should surely give folk pause for thought. It has been two months, but then again this is a limited API-related diff to begin with. Anyway - interpret how you will, here's some data, Eddy. From frederik.gladhorn at qt.io Wed Jan 4 16:25:52 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 04 Jan 2017 16:25:52 +0100 Subject: [Releasing] [Development] Proposal to adjust release candidate process In-Reply-To: References: Message-ID: <1618333.CLuHQRrLkn@frederik-thinkcentre-m93p> On tirsdag 3. januar 2017 08.02.21 CET Tuukka Turunen wrote: > Hi, > > Perhaps it is best to talk with marketing about the name of the "release > done immediately after branching to the .0 release branch". Reading the > discussion, it seems that other than the name we are well aligned. I'd try to follow standards, this is supposed to be primarily understood by developers. semver is the most sensible thing I know of when it comes to versions. #11 is pretty sensible: http://semver.org/#spec-item-11 I'll just copy their example and would like us to follow it: Example: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0- beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0. I agree with Robin in that we should make it easier to test, so for me the priority would be to get nightly builds out there and make it easy to install them through the online installer. Currently there is no sensible way for the community to help out since all the code and procedures are internal. We're cleaning many things up (one problem that The Qt Company has is that we have not stream-lined releasing and packaging the different products enough, Qt for Application Development and Device Creation for example are not packaged completely the same way...). Cheers, Frederik > > Our current process has "Release candidate" 2 weeks prior to the Final > release (see: https://wiki.qt.io/Qt5Releasing). > > If we now have the beta2/preview/othername release 4 weeks before the final, > our schedule is the following: > > Phase Timing > Feature freeze T-17 weeks > Alpha release T-13 weeks > Beta release T-8 weeks > Soft string freeze T-6 weeks > Hard string freeze T-5 weeks > Beta2/Preview/XYZ T-4 weeks > Final release T > > In addition to the main phases, there will be snapshots regularly for > testing. During the final weeks before the release these snapshots are then > considered as possible final release unless testing reveals a need to > change something. This part is unchanged. > > The main benefit for the change is providing a very close to final package > for users to test earlier. During the 4 weeks after Beta there is always a > lot of improvements, but after branching to the release branch we should > focus only for the high-priority error corrections and polishing the > documentation (if not already done earlier). > > PS. I would like to shorten the overall duration of the release creation to > 12 weeks from FF to final. I think that being more strict about the FF and > by having all the needed configurations done early enough, we should be > able to cut the time between FF and Alpha as well as between Alpha and > Beta. But that is something we can discuss later. > > Yours, > > Tuukka > > > From: Development > [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf > Of Simon Hausmann Sent: perjantaina 23. joulukuuta 2016 19.02 > To: Thiago Macieira ; development at qt-project.org > Subject: Re: [Development] Proposal to adjust release candidate process > > > > > Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case > the branch makes no difference and beta is a better name. > > > > > > Simon > > ________________________________ > From: Development > -bounces+simon.hausmann=qt.io at qt-project.org>> on behalf of Thiago Macieira > > Sent: Friday, > December 23, 2016 4:42:12 PM > To: development at qt-project.org > Subject: Re: [Development] Proposal to adjust release candidate process > > Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann > > escreveu: > > I find that the branch is relevant in this context, as it relates to the > > amount of patches going in. The amount of patches going in is IMO related > > to the probably of introducing regressions. The process around the release > > branch, as opposed to the "minor branch", as proven to be a useful > > mechanism for reducing the churn and making people ask themselves: Do I > > really want this change in this release or can it wait? > > > > So from what I think is one metric of quality (not the only one of > > course), > > the naming of release candidate is more meaningful. > > How about this, then? We release beta2 from the 5.n branch right before the > 5.n.0 branch is created (or finally branches off). It accomplishes the same > thing that Tuukka wanted: a release containing the code that is in the 5.n.0 > branch at the moment it is created, not a few weeks after with some round > of work. > > And I really mean "the code that is in the 5.n.0 branch". Since the two > branches at the same at that point, it's only a semantic difference which > one we created the beta2 release from. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tor.arne.vestbo at qt.io Thu Jan 5 16:45:34 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 5 Jan 2017 16:45:34 +0100 Subject: [Releasing] [Development] Proposal to adjust release candidate process In-Reply-To: <1618333.CLuHQRrLkn@frederik-thinkcentre-m93p> References: <1618333.CLuHQRrLkn@frederik-thinkcentre-m93p> Message-ID: <81adaf08-2cd8-befa-d327-b8165f35d48d@qt.io> On 04/01/2017 16:25, Frederik Gladhorn wrote: > On tirsdag 3. januar 2017 08.02.21 CET Tuukka Turunen wrote: >> Hi, >> >> Perhaps it is best to talk with marketing about the name of the "release >> done immediately after branching to the .0 release branch". Reading the >> discussion, it seems that other than the name we are well aligned. > > I'd try to follow standards, this is supposed to be primarily understood by > developers. semver is the most sensible thing I know of when it comes to > versions. #11 is pretty sensible: > http://semver.org/#spec-item-11 Yes a thousand times yes. tor arne From jani.heikkinen at qt.io Wed Jan 11 09:03:03 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 11 Jan 2017 08:03:03 +0000 Subject: [Releasing] New Qt 5.8 rc snapshot for testing Message-ID: Hi We have new Qt 5.8.0 rc snapshot for testing Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/720/ mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/726/ Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/622/ src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/ All known blockers should be fixed in these packages and we are targeting to release Qt 5.8.0 Tue 17th January if nothing really serious found during testing. So please inform me immediately if there is some new blocker in the packages. Please update known issues page (https://wiki.qt.io/Qt_5.8.0_Known_Issues) when needed as well br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Wed Jan 11 10:12:39 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 11 Jan 2017 09:12:39 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 10.1.2017 Message-ID: Meeting minutes from Qt Release Team meeting 10th January 2017 Qt 5.8.0 status: - Final content should be in place now - Packages are under testing - We will release current content as Qt 5.8.0 release Tue 17th January if nothing really serious found during testing Next meeting Tue 24th January 16:00 CET br, Jani Heikkinen irc log below: [17:06:42] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:07:00] jaheikki3: pong [17:07:06] jaheikki3: pong [17:07:09] Time to start qt release team meeting [17:07:16] on agenda today: [17:07:21] Qt 5.8.0 status [17:07:30] Any additional item to the agenda? [17:09:41] ok, let's browse through the status: [17:09:52] we should have final content in place [17:10:21] all blockers in https://bugreports.qt.io/issues/?filter=18160 should have a fix available & in packages [17:11:16] Packages are under testing at the moment ( LGPL manual testing request will be sent tomorrow when we have RTA smoke results available) [17:11:43] I don't see the configure.bat failure in the list [17:11:52] ? [17:12:11] And if nothing serious found we will release this content as Qt5.8.0 next Tue as planned [17:12:14] thiago: ? [17:12:31] https://bugreports.qt.io/browse/QTBUG-58019 [17:12:49] wait, affects 5.8.1 [17:12:55] it's 5.8 branch, not 5.8.0 [17:13:45] yeah, that one. The problem weren't in 5.8.0 at all [17:13:45] and has a commit listed... [17:14:54] huh, so all known blockers for 5.8.0 should be fixed ;) [17:16:02] So now final testing & if all ok just remove 'rc' from packages (& update final QtC 4.2.1 in the packages if needed) and we should be ready for the release [17:16:08] Any comments / questions? [17:16:46] sounds good [17:17:38] Great. That was all at this time. Let's skip next week's meeting if we get the release out as planned, ok? [17:18:25] ok [17:18:26] +1 [17:19:04] Great. Let's end the meeting now. Thanks your participation, bye! [17:19:27] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Fri Jan 13 13:23:47 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 13 Jan 2017 12:23:47 +0000 Subject: [Releasing] [Development] New Qt 5.8 rc snapshot for testing In-Reply-To: References: <7ca937d0-c2df-b939-5478-d787fafb8499@klingt.org>, Message-ID: Hi, While I agree that this (58133) is a bug, I would not classify it as a bug to halt the entire release. It's neither a regression or a particularly common scenario to run into, I would argue. That said, it's a crash, it needs fixing and I'll fix it. Simon ________________________________ From: Development on behalf of Ben Lau Sent: Friday, January 13, 2017 11:38:05 AM To: Tim Blechmann Cc: development at qt-project.org; releasing at qt-project.org Subject: Re: [Development] New Qt 5.8 rc snapshot for testing On 13 January 2017 at 14:15, Tim Blechmann > wrote: > All known blockers should be fixed in these packages and we are > targeting to release Qt 5.8.0 Tue 17^th January if nothing really > serious found during testing. So please inform me immediately if there > is some new blocker in the packages. QTBUG-56163 is the main blocker for me, which prevents me from migrating to qt-5.8. have already reported it 3 months ago and requested it via the commercial support. thanks a lot, tim I just submitted QTBUG-58133 on yesterday. It will make applications that use QuickFlux crash when passing a signal with QJSValue (isUndefined == true) via a C++ class to QML. https://bugreports.qt.io/browse/QTBUG-58133 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Fri Jan 13 13:31:18 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 13 Jan 2017 12:31:18 +0000 Subject: [Releasing] [Development] New Qt 5.8 rc snapshot for testing In-Reply-To: References: <7ca937d0-c2df-b939-5478-d787fafb8499@klingt.org>, , Message-ID: Hi, Slight correction: It's not a regression against 5.7, but it is still a regression [☹] . I'll fix it ASAP for 5.8.1 and back-port it also to the 5.6 branch. Simon ________________________________ From: Development on behalf of Simon Hausmann Sent: Friday, January 13, 2017 1:23:47 PM To: Ben Lau; Tim Blechmann Cc: development at qt-project.org; releasing at qt-project.org Subject: Re: [Development] New Qt 5.8 rc snapshot for testing Hi, While I agree that this (58133) is a bug, I would not classify it as a bug to halt the entire release. It's neither a regression or a particularly common scenario to run into, I would argue. That said, it's a crash, it needs fixing and I'll fix it. Simon ________________________________ From: Development on behalf of Ben Lau Sent: Friday, January 13, 2017 11:38:05 AM To: Tim Blechmann Cc: development at qt-project.org; releasing at qt-project.org Subject: Re: [Development] New Qt 5.8 rc snapshot for testing On 13 January 2017 at 14:15, Tim Blechmann > wrote: > All known blockers should be fixed in these packages and we are > targeting to release Qt 5.8.0 Tue 17^th January if nothing really > serious found during testing. So please inform me immediately if there > is some new blocker in the packages. QTBUG-56163 is the main blocker for me, which prevents me from migrating to qt-5.8. have already reported it 3 months ago and requested it via the commercial support. thanks a lot, tim I just submitted QTBUG-58133 on yesterday. It will make applications that use QuickFlux crash when passing a signal with QJSValue (isUndefined == true) via a C++ class to QML. https://bugreports.qt.io/browse/QTBUG-58133 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OutlookEmoji-☹.png Type: image/png Size: 506 bytes Desc: OutlookEmoji-☹.png URL: From frederik.gladhorn at qt.io Tue Jan 17 15:08:37 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 17 Jan 2017 15:08:37 +0100 Subject: [Releasing] Proposal to adjust release candidate process In-Reply-To: References: Message-ID: <2492902.h4cXBpu8N1@frederik-thinkcentre-m93p> On onsdag 21. desember 2016 07.58.32 CET Tuukka Turunen wrote: ... cutting away lots of text here ... > Name of the release can be in essence whatever that does not confuse users. > My gut feeling is that Beta 2 is not good name as we have already moved to > the next phase in going to the release branch. We have not released the > current process RC as final for any of the Qt 5 releases - there always > have been a couple of fixes between RC and final. I think that as long as > everyone is aware what the release is, it does not confuse users to call it > RC (or RC1). I think we don't get extensive testing, because by now everyone learned that there will be another round of testing - along with the RC. If we just stop doing so much testing around RC time and only ask to test the betas, we'd be much more likely to get releases out in a timely fashion with less trouble. It may take one release of all of us learning that only betas get proper testing, but hopefully we'll manage to communicate that. Assuming the beta is early enough before the release, we find big issues at that stage, get them fixed and then we assemble the release candidate shortly before release time. Assuming we do not find major issues after asking for a brief round of community testing, I'd suggest the release candidate goes out as releas a few days later without additional testing since it should be the same contents as beta plus the fixes for the very critical things found in beta testing. Cheers, Frederik > > Yours, > > Tuukka > > > Maurice > > _______________________________________________ > > 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 jani.heikkinen at qt.io Wed Jan 18 09:27:20 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 18 Jan 2017 08:27:20 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 17.1.2017 Message-ID: Meeting minutes from Qt Release Team meeting 17th January 2017 Qt 5.8.0 status: - Couple of new blockers reported * https://bugreports.qt.io/browse/QTBUG-58227 * https://bugreports.qt.io/browse/QTBUG-58225 - Target to re-create packages immediately when fixes in - Current target to get release out is Mon 23rd January br, Jani Heikkinen Release Manager irc log below: [17:01:23] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:01:35] jaheikki3: pong [17:01:55] jaheikki3: pong [17:02:34] Time to start qt release meeting [17:02:42] hello [17:02:49] jaheikki3: pong [17:03:05] on agenda today: [17:03:11] Qt 5.8.0 release status [17:03:16] jaheikki3: pong [17:03:21] Any additional item to the agenda? [17:04:41] ok, let's browse through the release status [17:04:54] New set of packages under testing [17:05:20] unfortunately couple of new blocker proposals reported :( [17:05:40] https://bugreports.qt.io/browse/QTBUG-58227 and https://bugreports.qt.io/browse/QTBUG-58225 [17:06:06] Discussion still ongoing if we need to fix those for 5.8.0 or not [17:06:39] Current target to get release out is Mon 23rd january [17:06:54] Should be possible even we need to fix the issues above [17:07:24] Any comments / questions? [17:07:43] both sound like minor regressions [17:07:53] I'm concerned about the font one that showed up after the RC [17:08:05] looks like a fix is known, so it should be applied [17:08:21] assuming it doesn't regress the issue that was fixed after the RC [17:08:22] for the winmax thing, yes, a simple fix [17:08:31] it needs a chinese windows to test though [17:09:12] Ah,ok , for fonts as well.. [17:10:07] Yeah, we have fixes available for both and I think we should take both in if we will update the packages once again [17:10:47] But then we should be ready for the release. hoping we can get font fix verified soon so that we can start re-creating the packages [17:11:04] yup [17:12:12] Ok, thats all at this time. Let's get the release finally out & skip next week's meeting & have new on Tue 31st January. Ok? [17:12:23] ok [17:12:36] ok [17:13:00] Great! Thanks for your participation. bye! [17:13:14] bye From Kai.Koehne at qt.io Tue Jan 24 13:00:40 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 24 Jan 2017 12:00:40 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <20161110142306.GC9877@troll08> References: <20161110142306.GC9877@troll08> Message-ID: Looks like this discussion got stuck before reaching a conclusion ... > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Thursday, November 10, 2016 3:23 PM > To: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Change file process & improvement proposal > [...] > > 1) Let's enable [ChangeLog] -tag by default in commit template. After > > that you must remove/comment out it by purpose if you don't want add > > it. > > > i really don't think this will make a positive difference. the problem is that > many people just don't have the right audience-oriented mindset. > we *already* have lots of garbage changelog entries, and this will just > worsen the S/N ratio. Actually looking through the commit logs e.g. in qtbase, I do think most [ChangeLog] entries are rather fine - surely some tweaking is sometimes necessary, but the quality of the ChangeLog entries we have is not all that bad. What is obvious though is that a lot of commits where I would have expected a [ChangeLog] do not have one. What's more, a well written [ChangeLog] entry will help also during the review, and can serve as a sanity check when it comes to the right branch being targeted etc. I therefore agree with Janne that we should encourage people to write them, and changing the default template is a very easy thing to do. > > And in addition to this update sanity bot so that it will give '-1' if > > change log entry isn't given in release branch. > > > this is probably not sensible. most last-minute fixes relate to recently > introduced problems, which means that they specifically *don't* need > changelog entries. That might be the case until the first .0 release from the branch is done, but surely not afterwards. Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 branched_. Is that easy to enable/disable? > here's what i think would actually make a difference (based on historical > evidence within trolltech): > https://bugreports.qt.io/browse/QTQAINFRA-933 Such a tool/infrastructure would be cool to have, indeed. It requires a lot more investment though than the incremental changes Jani proposed. I therefore suggest to implement Jani's suggestions for the time being. If we find out they're not effective, we can always come back and look into alternative processes. 1. Enable [ChangeLog] tag in commit template https://codereview.qt-project.org/183244 2. Add check in sanity bot to check for missing ChangeLog entries (potentially only in 5.x branches after 5.x.0 is out) (who could do this?) Regards Kai From frederik.gladhorn at qt.io Tue Jan 24 13:20:35 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 24 Jan 2017 13:20:35 +0100 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> Message-ID: <1685543.Pak2pvBs3S@frederik-thinkcentre-m93p> On tirsdag 24. januar 2017 12.00.40 CET Kai Koehne wrote: > Looks like this discussion got stuck before reaching a conclusion ... > > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Oswald Buddenhagen > > Sent: Thursday, November 10, 2016 3:23 PM > > To: development at qt-project.org; releasing at qt-project.org > > Subject: Re: [Development] Change file process & improvement proposal > > [...] > > > > > 1) Let's enable [ChangeLog] -tag by default in commit template. After > > > that you must remove/comment out it by purpose if you don't want add > > > it. > > > > i really don't think this will make a positive difference. the problem is > > that many people just don't have the right audience-oriented mindset. > > we *already* have lots of garbage changelog entries, and this will just > > worsen the S/N ratio. > > Actually looking through the commit logs e.g. in qtbase, I do think most > [ChangeLog] entries are rather fine - surely some tweaking is sometimes > necessary, but the quality of the ChangeLog entries we have is not all that > bad. > > What is obvious though is that a lot of commits where I would have expected > a [ChangeLog] do not have one. What's more, a well written [ChangeLog] > entry will help also during the review, and can serve as a sanity check > when it comes to the right branch being targeted etc. > > I therefore agree with Janne that we should encourage people to write them, > and changing the default template is a very easy thing to do. > > > And in addition to this update sanity bot so that it will give '-1' if > > > change log entry isn't given in release branch. > > > > this is probably not sensible. most last-minute fixes relate to recently > > introduced problems, which means that they specifically *don't* need > > changelog entries. > > That might be the case until the first .0 release from the branch is done, > but surely not afterwards. > > Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 > branched_. Is that easy to enable/disable? > > here's what i think would actually make a difference (based on historical > > evidence within trolltech): > > https://bugreports.qt.io/browse/QTQAINFRA-933 > > Such a tool/infrastructure would be cool to have, indeed. It requires a lot > more investment though than the incremental changes Jani proposed. > > I therefore suggest to implement Jani's suggestions for the time being. If > we find out they're not effective, we can always come back and look into > alternative processes. > > 1. Enable [ChangeLog] tag in commit template > > https://codereview.qt-project.org/183244 > > 2. Add check in sanity bot to check for missing ChangeLog entries > (potentially only in 5.x branches after 5.x.0 is out) Why only there? All relevant changes should have it - regardless of branch. I would actually suggest we change the sanity bot to -1 any change that has no [ChangeLog] entry. And we then agree on a marker that says "no changelog needed". [ChangeLog] none or similar. At this point we'll be all constantly reminded to add change log entries and it's still reasonably easy to opt out. Cheers, Frederik > > (who could do this?) > > Regards > > Kai > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From edward.welbourne at qt.io Tue Jan 24 15:38:11 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 24 Jan 2017 14:38:11 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08>, Message-ID: > Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 branched_. Is that easy to enable/disable? It should be easy to detect that 5.x.0 "has branched" - check for existence of either origin/5.x.0 branch or v5.x.0 tag. That we're committing to 5.x is fairly easy *in Gerrit* (with its relatively conservative branch set), and checking for 5.x when folk are using that locally for development is easy, but checking a topic-branch for whether it's based on (so presumptively targetting) 5.x rather than 5.y or dev may be trickier. (Getting such checks through code review may also be tricky; c.f. https://codereview.qt-project.org/177706 ...) Eddy. From oswald.buddenhagen at qt.io Tue Jan 24 16:20:33 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 24 Jan 2017 16:20:33 +0100 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> Message-ID: <20170124152033.GE20252@troll08> On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote: > > Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 > > branched_. Is that easy to enable/disable? > > It should be easy to detect that 5.x.0 "has branched" - check for > existence of either origin/5.x.0 branch or v5.x.0 tag. [...] > that's answering the wrong question. changes for 5.x.0 may require a changelog just as well, as the branch may receive fixes against 5.(x-1). we could suppress the changelog enforcement for example by standardizing my "amends ." lines in the commit messages. if the reference is to a commit which has not been tagged yet, we know that users won't find it interesting. From Kai.Koehne at qt.io Tue Jan 24 16:30:06 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 24 Jan 2017 15:30:06 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <1685543.Pak2pvBs3S@frederik-thinkcentre-m93p> References: <20161110142306.GC9877@troll08> <1685543.Pak2pvBs3S@frederik-thinkcentre-m93p> Message-ID: > -----Original Message----- > > [...] > > I therefore suggest to implement Jani's suggestions for the time > > being. If we find out they're not effective, we can always come back > > and look into alternative processes. > > > > 1. Enable [ChangeLog] tag in commit template > > > > https://codereview.qt-project.org/183244 > > > > 2. Add check in sanity bot to check for missing ChangeLog entries > > (potentially only in 5.x branches after 5.x.0 is out) > > Why only there? All relevant changes should have it - regardless of branch. > > I would actually suggest we change the sanity bot to -1 any change that has > no [ChangeLog] entry. And we then agree on a marker that says "no > changelog needed". > > [ChangeLog] none > > or similar. This will add quite some noise - There'll always be a significant portion of the commits, if not the majority, which do not require a ChangeLog. But yeah, it's easy to check and enforce :) I could live with this, too. Kai From edward.welbourne at qt.io Wed Jan 25 10:21:09 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 25 Jan 2017 09:21:09 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <20170124152033.GE20252@troll08> References: <20161110142306.GC9877@troll08> , <20170124152033.GE20252@troll08> Message-ID: On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote: >>> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 >>> branched_. Is that easy to enable/disable? >> >> It should be easy to detect that 5.x.0 "has branched" - check for >> existence of either origin/5.x.0 branch or v5.x.0 tag. [...] On 24 January 2017 16:20, Oswald Buddenhagen replied: > that's answering the wrong question. changes for 5.x.0 may require a > changelog just as well, as the branch may receive fixes against 5.(x-1). What the proposal actually asked for was technically feasible; so I said how to do it. My impression was that the proposal was motivated by a claim that stabilisation fixes typically won't want a change-log, as they're fixes to recent changes. The reasoning there may in fact be flawed - a fix to a recent change *with a change-log entry* might well need to amend/update the change-log entry. Still, aside from that, I suppose patch branches (M.m.p) are typically such stabilisation. However, you seem to be talking about *release* 5.x.0 rather than the *branch* of that name, so I'm not really clear on what you're talking about. > we could suppress the changelog enforcement for example by standardizing > my "amends ." lines in the commit messages. if the reference is to > a commit which has not been tagged yet, we know that users won't find it > interesting. I have never heard of these amends lines; where are they explained ? In any case, users may find a change interesting even if there is no specific earlier commit that can be pinned down as what this new change amends - sometimes, the origin of a status quo (being amended) is murky, its causes are contentious and most of the lines of prior code involved date from the 190MB commit 38be0d1383 that pulled most of our code into git in the first place. Still, maybe your amends-spec addresses that ... Eddy. From Shawn.Rutledge at qt.io Wed Jan 25 10:32:19 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 25 Jan 2017 09:32:19 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> Message-ID: > On 25 Jan 2017, at 10:21, Edward Welbourne wrote: > > I have never heard of these amends lines; where are they > explained ? In any case, users may find a change interesting even if > there is no specific earlier commit that can be pinned down as what this > new change amends - sometimes, the origin of a status quo (being > amended) is murky, its causes are contentious and most of the lines of > prior code involved date from the 190MB commit 38be0d1383 that pulled > most of our code into git in the first place. Still, maybe your > amends-spec addresses that … You’ll find many of them in the logs, and every valid SHA1 (or even unique prefix of a SHA1) turns into a link automatically in some tools such as gitk, and the git log viewer in Creator, which helps a bit with following the chain of reasoning behind a block of code. Forming a link which identifies a subset of the lines of the patch would be really very cool, but I don’t know of a way. From oswald.buddenhagen at qt.io Wed Jan 25 12:13:29 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 25 Jan 2017 12:13:29 +0100 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> Message-ID: <20170125111329.GH20252@troll08> On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote: > However, you seem to be talking about *release* 5.x.0 rather than the > *branch* of that name, so I'm not really clear on what you're talking > about. > i don't know how you arrived at this conclusion, but it isn't relevant to my reasoning anyway. > > we could suppress the changelog enforcement for example by standardizing > > my "amends ." lines in the commit messages. if the reference is to > > a commit which has not been tagged yet, we know that users won't find it > > interesting. > > I have never heard of these amends lines; where are they > explained ? > git log --author=oswald > In any case, users may find a change interesting even if there is no > specific earlier commit that can be pinned down [...] > unsurprisingly, i think that the correct fallback in case of a missing reference is assuming that the commit relates to a tagged commit (if it's even a fix at all) and therefore complaining about a missing changelog. From Simon.Hausmann at qt.io Wed Jan 25 13:31:52 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 25 Jan 2017 12:31:52 +0000 Subject: [Releasing] Avoiding platform test coverage regressions Message-ID: Hi, I'm writing this email because of a recurring problem with our test coverage in combination with releases of Qt. Many times in the past we've had the situation where a change was applied to the CI system that temporarily removed an entire platform, for example in favor of adding a new one in steps. I'll cite two examples right off the top of my head, but upon request I can dig up more: (1) During times of qtqa-testconfig we added and removed configurations without observing what their test coverage was, and at some point near the 5.3/5.4 release ended up in a situation where our entire cross-platform network stack was only tested partially on Linux, partly as a consequence of removing an older Windows (where we ran tests) in favor of a newer Windows (where we "insignifified" all network tests). We made several releases with a network stack that was untested on Windows and macOS. (2) Today we are in the situation where we are building Qt and running tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that added 10.11 to the CI configuration to provide build and test coverage were never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no tests run on 10.11. During a related discussion in https://codereview.qt-project.org/#/c/183219/ I suggested that we use a release blocking bug to track the progress of changing platforms and that way ensure that we don't release Qt before the regression of temporarily removing build and/or test coverage is fixed. Tony declined the suggestion with the following statement: "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in 5.6, but it got show down as it was seen as definitely not being able to block a release. And this happened again in 5.8. If everything else is fine, a missing platform from CI was seen as not to be able to block the release." I could not find any mention of that in the release team meeting logs regarding such a decision. I would like to raise the attention to this topic and request either approval to use blocking release bugs to track these regressions or ask for suggestions of alternate methods to prevent us from repeatedly running into the scenario of releasing Qt with regressed build and test coverage. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Wed Jan 25 14:17:40 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 25 Jan 2017 13:17:40 +0000 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: Message-ID: Hi! I totally agree with you that missing platforms should block the release. I would be even tighter, we should get all new platforms we are planning to support in before feature freeze. But lately it has been really hard to get new platforms in and that's why we have accepted the situation where missing platform hasn't been the release blocker. And that is one of most important things to be fixed. We need to get new platforms in ci much easier that it is now. I have seen us fighting to get new platforms in several months. And that should be only few hours work. It seems that it is really hard to get all tests passing at same time for that new platform. We try to get new platform in & find some test failing. Failures are fixed and new try... Argh, some other test are now failing ;) And test are fixed and new test are failing... All that has prevented us to get stuff in. So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in. br, Jani ________________________________________ From: Releasing on behalf of Simon Hausmann Sent: Wednesday, January 25, 2017 2:31 PM To: releasing at qt-project.org Subject: [Releasing] Avoiding platform test coverage regressions Hi, I'm writing this email because of a recurring problem with our test coverage in combination with releases of Qt. Many times in the past we've had the situation where a change was applied to the CI system that temporarily removed an entire platform, for example in favor of adding a new one in steps. I'll cite two examples right off the top of my head, but upon request I can dig up more: (1) During times of qtqa-testconfig we added and removed configurations without observing what their test coverage was, and at some point near the 5.3/5.4 release ended up in a situation where our entire cross-platform network stack was only tested partially on Linux, partly as a consequence of removing an older Windows (where we ran tests) in favor of a newer Windows (where we "insignifified" all network tests). We made several releases with a network stack that was untested on Windows and macOS. (2) Today we are in the situation where we are building Qt and running tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that added 10.11 to the CI configuration to provide build and test coverage were never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no tests run on 10.11. During a related discussion in https://codereview.qt-project.org/#/c/183219/ I suggested that we use a release blocking bug to track the progress of changing platforms and that way ensure that we don't release Qt before the regression of temporarily removing build and/or test coverage is fixed. Tony declined the suggestion with the following statement: "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in 5.6, but it got show down as it was seen as definitely not being able to block a release. And this happened again in 5.8. If everything else is fine, a missing platform from CI was seen as not to be able to block the release." I could not find any mention of that in the release team meeting logs regarding such a decision. I would like to raise the attention to this topic and request either approval to use blocking release bugs to track these regressions or ask for suggestions of alternate methods to prevent us from repeatedly running into the scenario of releasing Qt with regressed build and test coverage. Simon From frederik.gladhorn at qt.io Wed Jan 25 14:47:18 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 25 Jan 2017 14:47:18 +0100 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: Message-ID: <2562003.RilkULjINR@frederik-thinkcentre-m93p> On onsdag 25. januar 2017 13.17.40 CET Jani Heikkinen wrote: > Hi! > > I totally agree with you that missing platforms should block the release. I > would be even tighter, we should get all new platforms we are planning to > support in before feature freeze. But lately it has been really hard to get > new platforms in and that's why we have accepted the situation where > missing platform hasn't been the release blocker. Don't accept. You are the one to say: "no, then we don't release". Scream out loud and early that we won't release instead :) I think there was a bit of screaming now so I'm happy that the missing platforms got into many people's mind and focus. Especially you, Jani, are in a position to demand things from the rest of the organization. When you see something that is going to make us unable to release, try to talk to the people that can do something about it directly. If people don't react, raise a big red flag with Olli and/or Tuukka. Considering our track record in releasing on time and Tuukka's concern with releases we'll hopefully get people to help out. > And that is one of most important things to be fixed. We need to get new > platforms in ci much easier that it is now. I have seen us fighting to get > new platforms in several months. And that should be only few hours work. It > seems that it is really hard to get all tests passing at same time for that > new platform. We try to get new platform in & find some test failing. > Failures are fixed and new try... Argh, some other test are now failing ;) > And test are fixed and new test are failing... All that has prevented us to > get stuff in. So we need to find a way to get platforms in easier or then > block other development until failed test are fixed & new platform is in. I agree. Creative proposals and code that implements that please :) We (in Oslo and Berlin) have probably been quite hard to deal with in this regard, since we made some experiences that are really on our minds when dealing with this: We don't want platforms added when they actually don't work, because history has shown again and again that nobody will fix them. To this day I know we don't test qtxmlpatterns (well, we run 5 out of 100 tests or so) and Simon mentioned the network example. I think maybe it needs someone with the will to do a bit of leadership and who has passion to write it on their flags and fight the battle. Cheers, Frederik > > br, > Jani > > ________________________________________ > From: Releasing on > behalf of Simon Hausmann Sent: Wednesday, January > 25, 2017 2:31 PM > To: releasing at qt-project.org > Subject: [Releasing] Avoiding platform test coverage regressions > > Hi, > > > I'm writing this email because of a recurring problem with our test coverage > in combination with releases of Qt. > > > Many times in the past we've had the situation where a change was applied to > the CI system that temporarily removed an entire platform, for example in > favor of adding a new one in steps. I'll cite two examples right off the > top of my head, but upon request I can dig up more: > > > (1) During times of qtqa-testconfig we added and removed configurations > without observing what their test coverage was, and at some point near the > 5.3/5.4 release ended up in a situation where our entire cross-platform > network stack was only tested partially on Linux, partly as a consequence > of removing an older Windows (where we ran tests) in favor of a newer > Windows (where we "insignifified" all network tests). We made several > releases with a network stack that was untested on Windows and macOS. > > > (2) Today we are in the situation where we are building Qt and running > tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that > added 10.11 to the CI configuration to provide build and test coverage were > never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no > tests run on 10.11. > > > During a related discussion in https://codereview.qt-project.org/#/c/183219/ > I suggested that we use a release blocking bug to track the progress of > changing platforms and that way ensure that we don't release Qt before the > regression of temporarily removing build and/or test coverage is fixed. > > > Tony declined the suggestion with the following statement: > > "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in > 5.6, but it got show down as it was seen as definitely not being able to > block a release. And this happened again in 5.8. If everything else is > fine, a missing platform from CI was seen as not to be able to block the > release." > > > I could not find any mention of that in the release team meeting logs > regarding such a decision. > > > I would like to raise the attention to this topic and request either > approval to use blocking release bugs to track these regressions or ask for > suggestions of alternate methods to prevent us from repeatedly running into > the scenario of releasing Qt with regressed build and test coverage. > > > > > Simon > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From jani.heikkinen at qt.io Thu Jan 26 06:28:23 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 26 Jan 2017 05:28:23 +0000 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started Message-ID: Hi all, 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) br, Jani Heikkinen Release Manager The Qt Company From Simon.Hausmann at qt.io Thu Jan 26 09:19:35 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 26 Jan 2017 08:19:35 +0000 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: , Message-ID: Hi, You wrote "So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in". I do think that both go hand-in-hand. There is infrastructural work that has been done and still needs to be done to make it easier to get those platforms in. At the same time there is a last mile of actual test fixing that often requires attention from a developer who is familiar enough with the platform details to fix the issue in some way. I was under the impression that release blocking bugs are the most effective instrument we have today to direct the attention of development to a particular issue, because we have buy-in from the rest of the organization and project that release blocking issues are really easy to justify in terms of priorities. However relating you statement of "accepted the situation where missing platform hasn't been the release blocker" to my question of whether to use jira release blockers or if there's an alternate method of blocking, I am therefore inclined to conclude: We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. This is important to me, because when reviewing changes that relate to this it really helps to know where we stand with our goals. Knowing that retaining that coverage is not a release goal means we can approve changes that temporarily remove platforms without the need to follow up that they are added again. I personally find this very sad from a quality point of view. Simon ________________________________ From: Jani Heikkinen Sent: Wednesday, January 25, 2017 2:17:40 PM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi! I totally agree with you that missing platforms should block the release. I would be even tighter, we should get all new platforms we are planning to support in before feature freeze. But lately it has been really hard to get new platforms in and that's why we have accepted the situation where missing platform hasn't been the release blocker. And that is one of most important things to be fixed. We need to get new platforms in ci much easier that it is now. I have seen us fighting to get new platforms in several months. And that should be only few hours work. It seems that it is really hard to get all tests passing at same time for that new platform. We try to get new platform in & find some test failing. Failures are fixed and new try... Argh, some other test are now failing ;) And test are fixed and new test are failing... All that has prevented us to get stuff in. So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in. br, Jani ________________________________________ From: Releasing on behalf of Simon Hausmann Sent: Wednesday, January 25, 2017 2:31 PM To: releasing at qt-project.org Subject: [Releasing] Avoiding platform test coverage regressions Hi, I'm writing this email because of a recurring problem with our test coverage in combination with releases of Qt. Many times in the past we've had the situation where a change was applied to the CI system that temporarily removed an entire platform, for example in favor of adding a new one in steps. I'll cite two examples right off the top of my head, but upon request I can dig up more: (1) During times of qtqa-testconfig we added and removed configurations without observing what their test coverage was, and at some point near the 5.3/5.4 release ended up in a situation where our entire cross-platform network stack was only tested partially on Linux, partly as a consequence of removing an older Windows (where we ran tests) in favor of a newer Windows (where we "insignifified" all network tests). We made several releases with a network stack that was untested on Windows and macOS. (2) Today we are in the situation where we are building Qt and running tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that added 10.11 to the CI configuration to provide build and test coverage were never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no tests run on 10.11. During a related discussion in https://codereview.qt-project.org/#/c/183219/ I suggested that we use a release blocking bug to track the progress of changing platforms and that way ensure that we don't release Qt before the regression of temporarily removing build and/or test coverage is fixed. Tony declined the suggestion with the following statement: "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in 5.6, but it got show down as it was seen as definitely not being able to block a release. And this happened again in 5.8. If everything else is fine, a missing platform from CI was seen as not to be able to block the release." I could not find any mention of that in the release team meeting logs regarding such a decision. I would like to raise the attention to this topic and request either approval to use blocking release bugs to track these regressions or ask for suggestions of alternate methods to prevent us from repeatedly running into the scenario of releasing Qt with regressed build and test coverage. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Thu Jan 26 09:51:24 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 26 Jan 2017 08:51:24 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <20170125111329.GH20252@troll08> References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> , <20170125111329.GH20252@troll08> Message-ID: On Wed, Jan 25, 2017 at 10:21:09AM +0100, Edward Welbourne wrote: >> However, you seem to be talking about *release* 5.x.0 rather than the >> *branch* of that name, so I'm not really clear on what you're talking >> about. 25 January 2017 12:13, Oswald Buddenhagen: > i don't know how you arrived at this conclusion, but it isn't relevant > to my reasoning anyway. On the other hand, it's a fairly good clue to the possibility that I've misunderstood what you were talking about. >>> we could suppress the changelog enforcement for example by standardizing >>> my "amends ." lines in the commit messages. if the reference is to >>> a commit which has not been tagged yet, we know that users won't find it >>> interesting. > >> I have never heard of these amends lines; where are they >> explained ? >> > git log --author=oswald So a sort of after-the-fact fixup! tag. >> In any case, users may find a change interesting even if there is no >> specific earlier commit that can be pinned down [...] > > unsurprisingly, i think that the correct fallback in case of a missing > reference is assuming that the commit relates to a tagged commit (if > it's even a fix at all) and therefore complaining about a missing > changelog. 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 *can* see how an amends line would be a basis for not demanding a changelog entry, though. Eddy. From jani.heikkinen at qt.io Thu Jan 26 10:48:56 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 26 Jan 2017 09:48:56 +0000 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: , , Message-ID: Hi, >>We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. I didn't mean that and I think we shouldn't do this ;) We have accepted that earlier with a) Not defining missing platform as a release blocker b) Blacklisting big mass of autotest And I do agree we need to stop that. That is causing us lots of problems & false impression about our quality, test coverage & supported platforms. But we cannot change all that at once; we are committed to deliver new releases & new features. So we need to improve the situation by doing baby steps to right direction. For example now; I think most important thing is to get missing platforms in the builds first (macOS 10.11, 10.12, msvc 2017, Ubuntu 16.10 etc). Even without running tests there. But we do need to make sure that all possible test must be run there eventuallyl. As soon as possible, well before official release. And I would state now that missing test coverage (meaning if we temporarily remove some test now to get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating P0 bug for that is definitely OK. As you wrote p0 bug is good (I think best) way to get someone focusing to that issue... And in addition to these new platforms I think we must put effort to reduce the amount of those blacklisted autotest. It is just wrong to have those in as much as there is now. I do understand that sometimes it is wise to blacklist the test to be able to proceed but in that case we must create a plan how to remove that blacklisting as soon as possible. p0 bug there would be good option as well. We tried that but it didn't work. Maybe it could be good time now to retry? But what to do for this existing mass of blacklisted autotest, it is also test coverage regression from previous releases? How we should fix that? br, Jani ________________________________________ From: Simon Hausmann Sent: Thursday, January 26, 2017 10:19 AM To: Jani Heikkinen; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, You wrote "So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in". I do think that both go hand-in-hand. There is infrastructural work that has been done and still needs to be done to make it easier to get those platforms in. At the same time there is a last mile of actual test fixing that often requires attention from a developer who is familiar enough with the platform details to fix the issue in some way. I was under the impression that release blocking bugs are the most effective instrument we have today to direct the attention of development to a particular issue, because we have buy-in from the rest of the organization and project that release blocking issues are really easy to justify in terms of priorities. However relating you statement of "accepted the situation where missing platform hasn't been the release blocker" to my question of whether to use jira release blockers or if there's an alternate method of blocking, I am therefore inclined to conclude: We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. This is important to me, because when reviewing changes that relate to this it really helps to know where we stand with our goals. Knowing that retaining that coverage is not a release goal means we can approve changes that temporarily remove platforms without the need to follow up that they are added again. I personally find this very sad from a quality point of view. Simon ________________________________ From: Jani Heikkinen Sent: Wednesday, January 25, 2017 2:17:40 PM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi! I totally agree with you that missing platforms should block the release. I would be even tighter, we should get all new platforms we are planning to support in before feature freeze. But lately it has been really hard to get new platforms in and that's why we have accepted the situation where missing platform hasn't been the release blocker. And that is one of most important things to be fixed. We need to get new platforms in ci much easier that it is now. I have seen us fighting to get new platforms in several months. And that should be only few hours work. It seems that it is really hard to get all tests passing at same time for that new platform. We try to get new platform in & find some test failing. Failures are fixed and new try... Argh, some other test are now failing ;) And test are fixed and new test are failing... All that has prevented us to get stuff in. So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in. br, Jani ________________________________________ From: Releasing on behalf of Simon Hausmann Sent: Wednesday, January 25, 2017 2:31 PM To: releasing at qt-project.org Subject: [Releasing] Avoiding platform test coverage regressions Hi, I'm writing this email because of a recurring problem with our test coverage in combination with releases of Qt. Many times in the past we've had the situation where a change was applied to the CI system that temporarily removed an entire platform, for example in favor of adding a new one in steps. I'll cite two examples right off the top of my head, but upon request I can dig up more: (1) During times of qtqa-testconfig we added and removed configurations without observing what their test coverage was, and at some point near the 5.3/5.4 release ended up in a situation where our entire cross-platform network stack was only tested partially on Linux, partly as a consequence of removing an older Windows (where we ran tests) in favor of a newer Windows (where we "insignifified" all network tests). We made several releases with a network stack that was untested on Windows and macOS. (2) Today we are in the situation where we are building Qt and running tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that added 10.11 to the CI configuration to provide build and test coverage were never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no tests run on 10.11. During a related discussion in https://codereview.qt-project.org/#/c/183219/ I suggested that we use a release blocking bug to track the progress of changing platforms and that way ensure that we don't release Qt before the regression of temporarily removing build and/or test coverage is fixed. Tony declined the suggestion with the following statement: "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in 5.6, but it got show down as it was seen as definitely not being able to block a release. And this happened again in 5.8. If everything else is fine, a missing platform from CI was seen as not to be able to block the release." I could not find any mention of that in the release team meeting logs regarding such a decision. I would like to raise the attention to this topic and request either approval to use blocking release bugs to track these regressions or ask for suggestions of alternate methods to prevent us from repeatedly running into the scenario of releasing Qt with regressed build and test coverage. Simon From Simon.Hausmann at qt.io Thu Jan 26 10:58:53 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 26 Jan 2017 09:58:53 +0000 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: , , , Message-ID: Hi, I think it's important here to distinguish between the addition of new platforms to our test coverage and regressing on existing coverage. I agree that it's probably fine to be relaxed about the former, but in this email thread I'm only concerned about the latter (regressions). So what you mention with 10.12, msvc 2017 and Ubuntu 16.10 are _new_ platform additions. While those are important, I'm - as an example - referring to the case I mentioned in the first email, where I quoted Tony saying that previous attempts to making such a platform regression a blocker was rejected. So based on your [ very clear, btw, thanks :) ] statement "And I would state now that missing test coverage (meaning if we temporarily remove some test now to get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating P0 bug for that is definitely OK" I would revert my earlier conclusion. To make it even more concrete: Can you confirm that it is OK to make a release blocking bug for 5.9 to re-add build and test coverage for macOS 10.11 like we have today for Qt 5.6? Simon ________________________________ From: Jani Heikkinen Sent: Thursday, January 26, 2017 10:48:56 AM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, >>We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. I didn't mean that and I think we shouldn't do this ;) We have accepted that earlier with a) Not defining missing platform as a release blocker b) Blacklisting big mass of autotest And I do agree we need to stop that. That is causing us lots of problems & false impression about our quality, test coverage & supported platforms. But we cannot change all that at once; we are committed to deliver new releases & new features. So we need to improve the situation by doing baby steps to right direction. For example now; I think most important thing is to get missing platforms in the builds first (macOS 10.11, 10.12, msvc 2017, Ubuntu 16.10 etc). Even without running tests there. But we do need to make sure that all possible test must be run there eventuallyl. As soon as possible, well before official release. And I would state now that missing test coverage (meaning if we temporarily remove some test now to get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating P0 bug for that is definitely OK. As you wrote p0 bug is good (I think best) way to get someone focusing to that issue... And in addition to these new platforms I think we must put effort to reduce the amount of those blacklisted autotest. It is just wrong to have those in as much as there is now. I do understand that sometimes it is wise to blacklist the test to be able to proceed but in that case we must create a plan how to remove that blacklisting as soon as possible. p0 bug there would be good option as well. We tried that but it didn't work. Maybe it could be good time now to retry? But what to do for this existing mass of blacklisted autotest, it is also test coverage regression from previous releases? How we should fix that? br, Jani ________________________________________ From: Simon Hausmann Sent: Thursday, January 26, 2017 10:19 AM To: Jani Heikkinen; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, You wrote "So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in". I do think that both go hand-in-hand. There is infrastructural work that has been done and still needs to be done to make it easier to get those platforms in. At the same time there is a last mile of actual test fixing that often requires attention from a developer who is familiar enough with the platform details to fix the issue in some way. I was under the impression that release blocking bugs are the most effective instrument we have today to direct the attention of development to a particular issue, because we have buy-in from the rest of the organization and project that release blocking issues are really easy to justify in terms of priorities. However relating you statement of "accepted the situation where missing platform hasn't been the release blocker" to my question of whether to use jira release blockers or if there's an alternate method of blocking, I am therefore inclined to conclude: We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. This is important to me, because when reviewing changes that relate to this it really helps to know where we stand with our goals. Knowing that retaining that coverage is not a release goal means we can approve changes that temporarily remove platforms without the need to follow up that they are added again. I personally find this very sad from a quality point of view. Simon ________________________________ From: Jani Heikkinen Sent: Wednesday, January 25, 2017 2:17:40 PM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi! I totally agree with you that missing platforms should block the release. I would be even tighter, we should get all new platforms we are planning to support in before feature freeze. But lately it has been really hard to get new platforms in and that's why we have accepted the situation where missing platform hasn't been the release blocker. And that is one of most important things to be fixed. We need to get new platforms in ci much easier that it is now. I have seen us fighting to get new platforms in several months. And that should be only few hours work. It seems that it is really hard to get all tests passing at same time for that new platform. We try to get new platform in & find some test failing. Failures are fixed and new try... Argh, some other test are now failing ;) And test are fixed and new test are failing... All that has prevented us to get stuff in. So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in. br, Jani ________________________________________ From: Releasing on behalf of Simon Hausmann Sent: Wednesday, January 25, 2017 2:31 PM To: releasing at qt-project.org Subject: [Releasing] Avoiding platform test coverage regressions Hi, I'm writing this email because of a recurring problem with our test coverage in combination with releases of Qt. Many times in the past we've had the situation where a change was applied to the CI system that temporarily removed an entire platform, for example in favor of adding a new one in steps. I'll cite two examples right off the top of my head, but upon request I can dig up more: (1) During times of qtqa-testconfig we added and removed configurations without observing what their test coverage was, and at some point near the 5.3/5.4 release ended up in a situation where our entire cross-platform network stack was only tested partially on Linux, partly as a consequence of removing an older Windows (where we ran tests) in favor of a newer Windows (where we "insignifified" all network tests). We made several releases with a network stack that was untested on Windows and macOS. (2) Today we are in the situation where we are building Qt and running tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that added 10.11 to the CI configuration to provide build and test coverage were never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no tests run on 10.11. During a related discussion in https://codereview.qt-project.org/#/c/183219/ I suggested that we use a release blocking bug to track the progress of changing platforms and that way ensure that we don't release Qt before the regression of temporarily removing build and/or test coverage is fixed. Tony declined the suggestion with the following statement: "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in 5.6, but it got show down as it was seen as definitely not being able to block a release. And this happened again in 5.8. If everything else is fine, a missing platform from CI was seen as not to be able to block the release." I could not find any mention of that in the release team meeting logs regarding such a decision. I would like to raise the attention to this topic and request either approval to use blocking release bugs to track these regressions or ask for suggestions of alternate methods to prevent us from repeatedly running into the scenario of releasing Qt with regressed build and test coverage. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Thu Jan 26 11:01:12 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 26 Jan 2017 10:01:12 +0000 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: , , , , Message-ID: Hi, >>To make it even more concrete: Can you confirm that it is OK to make a release blocking bug for 5.9 to re-add build and test coverage for macOS 10.11 like we have today for Qt 5.6? Yes, that is more than OK. br, Jani ________________________________________ From: Simon Hausmann Sent: Thursday, January 26, 2017 11:58 AM To: Jani Heikkinen; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, I think it's important here to distinguish between the addition of new platforms to our test coverage and regressing on existing coverage. I agree that it's probably fine to be relaxed about the former, but in this email thread I'm only concerned about the latter (regressions). So what you mention with 10.12, msvc 2017 and Ubuntu 16.10 are _new_ platform additions. While those are important, I'm - as an example - referring to the case I mentioned in the first email, where I quoted Tony saying that previous attempts to making such a platform regression a blocker was rejected. So based on your [ very clear, btw, thanks :) ] statement "And I would state now that missing test coverage (meaning if we temporarily remove some test now to get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating P0 bug for that is definitely OK" I would revert my earlier conclusion. To make it even more concrete: Can you confirm that it is OK to make a release blocking bug for 5.9 to re-add build and test coverage for macOS 10.11 like we have today for Qt 5.6? Simon ________________________________ From: Jani Heikkinen Sent: Thursday, January 26, 2017 10:48:56 AM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, >>We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. I didn't mean that and I think we shouldn't do this ;) We have accepted that earlier with a) Not defining missing platform as a release blocker b) Blacklisting big mass of autotest And I do agree we need to stop that. That is causing us lots of problems & false impression about our quality, test coverage & supported platforms. But we cannot change all that at once; we are committed to deliver new releases & new features. So we need to improve the situation by doing baby steps to right direction. For example now; I think most important thing is to get missing platforms in the builds first (macOS 10.11, 10.12, msvc 2017, Ubuntu 16.10 etc). Even without running tests there. But we do need to make sure that all possible test must be run there eventuallyl. As soon as possible, well before official release. And I would state now that missing test coverage (meaning if we temporarily remove some test now to get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating P0 bug for that is definitely OK. As you wrote p0 bug is good (I think best) way to get someone focusing to that issue... And in addition to these new platforms I think we must put effort to reduce the amount of those blacklisted autotest. It is just wrong to have those in as much as there is now. I do understand that sometimes it is wise to blacklist the test to be able to proceed but in that case we must create a plan how to remove that blacklisting as soon as possible. p0 bug there would be good option as well. We tried that but it didn't work. Maybe it could be good time now to retry? But what to do for this existing mass of blacklisted autotest, it is also test coverage regression from previous releases? How we should fix that? br, Jani ________________________________________ From: Simon Hausmann Sent: Thursday, January 26, 2017 10:19 AM To: Jani Heikkinen; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, You wrote "So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in". I do think that both go hand-in-hand. There is infrastructural work that has been done and still needs to be done to make it easier to get those platforms in. At the same time there is a last mile of actual test fixing that often requires attention from a developer who is familiar enough with the platform details to fix the issue in some way. I was under the impression that release blocking bugs are the most effective instrument we have today to direct the attention of development to a particular issue, because we have buy-in from the rest of the organization and project that release blocking issues are really easy to justify in terms of priorities. However relating you statement of "accepted the situation where missing platform hasn't been the release blocker" to my question of whether to use jira release blockers or if there's an alternate method of blocking, I am therefore inclined to conclude: We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. This is important to me, because when reviewing changes that relate to this it really helps to know where we stand with our goals. Knowing that retaining that coverage is not a release goal means we can approve changes that temporarily remove platforms without the need to follow up that they are added again. I personally find this very sad from a quality point of view. Simon ________________________________ From: Jani Heikkinen Sent: Wednesday, January 25, 2017 2:17:40 PM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi! I totally agree with you that missing platforms should block the release. I would be even tighter, we should get all new platforms we are planning to support in before feature freeze. But lately it has been really hard to get new platforms in and that's why we have accepted the situation where missing platform hasn't been the release blocker. And that is one of most important things to be fixed. We need to get new platforms in ci much easier that it is now. I have seen us fighting to get new platforms in several months. And that should be only few hours work. It seems that it is really hard to get all tests passing at same time for that new platform. We try to get new platform in & find some test failing. Failures are fixed and new try... Argh, some other test are now failing ;) And test are fixed and new test are failing... All that has prevented us to get stuff in. So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in. br, Jani ________________________________________ From: Releasing on behalf of Simon Hausmann Sent: Wednesday, January 25, 2017 2:31 PM To: releasing at qt-project.org Subject: [Releasing] Avoiding platform test coverage regressions Hi, I'm writing this email because of a recurring problem with our test coverage in combination with releases of Qt. Many times in the past we've had the situation where a change was applied to the CI system that temporarily removed an entire platform, for example in favor of adding a new one in steps. I'll cite two examples right off the top of my head, but upon request I can dig up more: (1) During times of qtqa-testconfig we added and removed configurations without observing what their test coverage was, and at some point near the 5.3/5.4 release ended up in a situation where our entire cross-platform network stack was only tested partially on Linux, partly as a consequence of removing an older Windows (where we ran tests) in favor of a newer Windows (where we "insignifified" all network tests). We made several releases with a network stack that was untested on Windows and macOS. (2) Today we are in the situation where we are building Qt and running tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that added 10.11 to the CI configuration to provide build and test coverage were never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no tests run on 10.11. During a related discussion in https://codereview.qt-project.org/#/c/183219/ I suggested that we use a release blocking bug to track the progress of changing platforms and that way ensure that we don't release Qt before the regression of temporarily removing build and/or test coverage is fixed. Tony declined the suggestion with the following statement: "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in 5.6, but it got show down as it was seen as definitely not being able to block a release. And this happened again in 5.8. If everything else is fine, a missing platform from CI was seen as not to be able to block the release." I could not find any mention of that in the release team meeting logs regarding such a decision. I would like to raise the attention to this topic and request either approval to use blocking release bugs to track these regressions or ask for suggestions of alternate methods to prevent us from repeatedly running into the scenario of releasing Qt with regressed build and test coverage. Simon From Simon.Hausmann at qt.io Thu Jan 26 11:04:36 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 26 Jan 2017 10:04:36 +0000 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: , , , , , Message-ID: Thank you! :) That concludes the question in my very first email then that it is fine to use release blocking bugs to track regressions in platform test coverage. Simon ________________________________ From: Jani Heikkinen Sent: Thursday, January 26, 2017 11:01:12 AM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, >>To make it even more concrete: Can you confirm that it is OK to make a release blocking bug for 5.9 to re-add build and test coverage for macOS 10.11 like we have today for Qt 5.6? Yes, that is more than OK. br, Jani ________________________________________ From: Simon Hausmann Sent: Thursday, January 26, 2017 11:58 AM To: Jani Heikkinen; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, I think it's important here to distinguish between the addition of new platforms to our test coverage and regressing on existing coverage. I agree that it's probably fine to be relaxed about the former, but in this email thread I'm only concerned about the latter (regressions). So what you mention with 10.12, msvc 2017 and Ubuntu 16.10 are _new_ platform additions. While those are important, I'm - as an example - referring to the case I mentioned in the first email, where I quoted Tony saying that previous attempts to making such a platform regression a blocker was rejected. So based on your [ very clear, btw, thanks :) ] statement "And I would state now that missing test coverage (meaning if we temporarily remove some test now to get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating P0 bug for that is definitely OK" I would revert my earlier conclusion. To make it even more concrete: Can you confirm that it is OK to make a release blocking bug for 5.9 to re-add build and test coverage for macOS 10.11 like we have today for Qt 5.6? Simon ________________________________ From: Jani Heikkinen Sent: Thursday, January 26, 2017 10:48:56 AM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, >>We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. I didn't mean that and I think we shouldn't do this ;) We have accepted that earlier with a) Not defining missing platform as a release blocker b) Blacklisting big mass of autotest And I do agree we need to stop that. That is causing us lots of problems & false impression about our quality, test coverage & supported platforms. But we cannot change all that at once; we are committed to deliver new releases & new features. So we need to improve the situation by doing baby steps to right direction. For example now; I think most important thing is to get missing platforms in the builds first (macOS 10.11, 10.12, msvc 2017, Ubuntu 16.10 etc). Even without running tests there. But we do need to make sure that all possible test must be run there eventuallyl. As soon as possible, well before official release. And I would state now that missing test coverage (meaning if we temporarily remove some test now to get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating P0 bug for that is definitely OK. As you wrote p0 bug is good (I think best) way to get someone focusing to that issue... And in addition to these new platforms I think we must put effort to reduce the amount of those blacklisted autotest. It is just wrong to have those in as much as there is now. I do understand that sometimes it is wise to blacklist the test to be able to proceed but in that case we must create a plan how to remove that blacklisting as soon as possible. p0 bug there would be good option as well. We tried that but it didn't work. Maybe it could be good time now to retry? But what to do for this existing mass of blacklisted autotest, it is also test coverage regression from previous releases? How we should fix that? br, Jani ________________________________________ From: Simon Hausmann Sent: Thursday, January 26, 2017 10:19 AM To: Jani Heikkinen; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi, You wrote "So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in". I do think that both go hand-in-hand. There is infrastructural work that has been done and still needs to be done to make it easier to get those platforms in. At the same time there is a last mile of actual test fixing that often requires attention from a developer who is familiar enough with the platform details to fix the issue in some way. I was under the impression that release blocking bugs are the most effective instrument we have today to direct the attention of development to a particular issue, because we have buy-in from the rest of the organization and project that release blocking issues are really easy to justify in terms of priorities. However relating you statement of "accepted the situation where missing platform hasn't been the release blocker" to my question of whether to use jira release blockers or if there's an alternate method of blocking, I am therefore inclined to conclude: We continue to accept today's situation of knowingly regressing in platform test coverage for releases of Qt. This is important to me, because when reviewing changes that relate to this it really helps to know where we stand with our goals. Knowing that retaining that coverage is not a release goal means we can approve changes that temporarily remove platforms without the need to follow up that they are added again. I personally find this very sad from a quality point of view. Simon ________________________________ From: Jani Heikkinen Sent: Wednesday, January 25, 2017 2:17:40 PM To: Simon Hausmann; releasing at qt-project.org Subject: Re: Avoiding platform test coverage regressions Hi! I totally agree with you that missing platforms should block the release. I would be even tighter, we should get all new platforms we are planning to support in before feature freeze. But lately it has been really hard to get new platforms in and that's why we have accepted the situation where missing platform hasn't been the release blocker. And that is one of most important things to be fixed. We need to get new platforms in ci much easier that it is now. I have seen us fighting to get new platforms in several months. And that should be only few hours work. It seems that it is really hard to get all tests passing at same time for that new platform. We try to get new platform in & find some test failing. Failures are fixed and new try... Argh, some other test are now failing ;) And test are fixed and new test are failing... All that has prevented us to get stuff in. So we need to find a way to get platforms in easier or then block other development until failed test are fixed & new platform is in. br, Jani ________________________________________ From: Releasing on behalf of Simon Hausmann Sent: Wednesday, January 25, 2017 2:31 PM To: releasing at qt-project.org Subject: [Releasing] Avoiding platform test coverage regressions Hi, I'm writing this email because of a recurring problem with our test coverage in combination with releases of Qt. Many times in the past we've had the situation where a change was applied to the CI system that temporarily removed an entire platform, for example in favor of adding a new one in steps. I'll cite two examples right off the top of my head, but upon request I can dig up more: (1) During times of qtqa-testconfig we added and removed configurations without observing what their test coverage was, and at some point near the 5.3/5.4 release ended up in a situation where our entire cross-platform network stack was only tested partially on Linux, partly as a consequence of removing an older Windows (where we ran tests) in favor of a newer Windows (where we "insignifified" all network tests). We made several releases with a network stack that was untested on Windows and macOS. (2) Today we are in the situation where we are building Qt and running tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that added 10.11 to the CI configuration to provide build and test coverage were never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no tests run on 10.11. During a related discussion in https://codereview.qt-project.org/#/c/183219/ I suggested that we use a release blocking bug to track the progress of changing platforms and that way ensure that we don't release Qt before the regression of temporarily removing build and/or test coverage is fixed. Tony declined the suggestion with the following statement: "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in 5.6, but it got show down as it was seen as definitely not being able to block a release. And this happened again in 5.8. If everything else is fine, a missing platform from CI was seen as not to be able to block the release." I could not find any mention of that in the release team meeting logs regarding such a decision. I would like to raise the attention to this topic and request either approval to use blocking release bugs to track these regressions or ask for suggestions of alternate methods to prevent us from repeatedly running into the scenario of releasing Qt with regressed build and test coverage. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Thu Jan 26 12:51:51 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 26 Jan 2017 12:51:51 +0100 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> Message-ID: <20170126115151.GD3289@troll08> 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. From Kai.Koehne at qt.io Thu Jan 26 13:28:30 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 26 Jan 2017 12:28:30 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <20170126115151.GD3289@troll08> References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08> Message-ID: > -----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 From frederik.gladhorn at qt.io Thu Jan 26 13:58:38 2017 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 26 Jan 2017 13:58:38 +0100 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: References: Message-ID: <1865765.62yUJa2i65@frederik-thinkcentre-m93p> On torsdag 26. januar 2017 09.48.56 CET Jani Heikkinen wrote: > Hi, > > >>We continue to accept today's situation of knowingly regressing in > >>platform test coverage for releases of Qt. > I didn't mean that and I think we shouldn't do this ;) > > We have accepted that earlier with > a) Not defining missing platform as a release blocker > b) Blacklisting big mass of autotest > > And I do agree we need to stop that. That is causing us lots of problems & > false impression about our quality, test coverage & supported platforms. > > But we cannot change all that at once; we are committed to deliver new > releases & new features. So we need to improve the situation by doing baby > steps to right direction. For example now; I think most important thing is > to get missing platforms in the builds first (macOS 10.11, 10.12, msvc > 2017, Ubuntu 16.10 etc). Even without running tests there. But we do need > to make sure that all possible test must be run there eventuallyl. To me new platforms including testing on them are features. Either they make feature freeze or not. Let's either postpone the feature freeze or not add them past the poing of the feature freeze. We all agreed we want a strict feature freeze, so let's not make exceptions here. This is exactly why I don't think 5.9 will be out according to schedule. > As soon > as possible, well before official release. And I would state now that > missing test coverage (meaning if we temporarily remove some test now to > get new platform in) is p0 bug for the Qt 5.9.0 release and so on creating > P0 bug for that is definitely OK. As you wrote p0 bug is good (I think > best) way to get someone focusing to that issue... I think it's a matter of perception, but P0 is not the answer because the definition to me is "blocks other people from working" and this doesn't. So for me P1 would feel correct. But we have a big inflation about the meaning of the bug priorities. I still think we should have P1s being release blockers. And de-mote every P1 to P2 if it's determined not to be a blocker. > > And in addition to these new platforms I think we must put effort to reduce > the amount of those blacklisted autotest. It is just wrong to have those in > as much as there is now. I do understand that sometimes it is wise to > blacklist the test to be able to proceed but in that case we must create a > plan how to remove that blacklisting as soon as possible. p0 bug there > would be good option as well. We tried that but it didn't work. Maybe it > could be good time now to retry? But what to do for this existing mass of > blacklisted autotest, it is also test coverage regression from previous > releases? How we should fix that? I think we need to make individuals responsible for each of these P1s and make sure that they know they are the only ones working on them and that these will block the release. Cheers, Frederik > > br, > Jani > > ________________________________________ > From: Simon Hausmann > Sent: Thursday, January 26, 2017 10:19 AM > To: Jani Heikkinen; releasing at qt-project.org > Subject: Re: Avoiding platform test coverage regressions > > Hi, > > > You wrote "So we need to find a way to get platforms in easier or then block > other development until failed test are fixed & new platform is in". > > > I do think that both go hand-in-hand. There is infrastructural work that has > been done and still needs to be done to make it easier to get those > platforms in. At the same time there is a last mile of actual test fixing > that often requires attention from a developer who is familiar enough with > the platform details to fix the issue in some way. I was under the > impression that release blocking bugs are the most effective instrument we > have today to direct the attention of development to a particular issue, > because we have buy-in from the rest of the organization and project that > release blocking issues are really easy to justify in terms of priorities. > > > However relating you statement of "accepted the situation where missing > platform hasn't been the release blocker" to my question of whether to use > jira release blockers or if there's an alternate method of blocking, I am > therefore inclined to conclude: > > > We continue to accept today's situation of knowingly regressing in > platform test coverage for releases of Qt. > > > > This is important to me, because when reviewing changes that relate to this > it really helps to know where we stand with our goals. Knowing that > retaining that coverage is not a release goal means we can approve changes > that temporarily remove platforms without the need to follow up that they > are added again. I personally find this very sad from a quality point of > view. > > > > Simon > > ________________________________ > From: Jani Heikkinen > Sent: Wednesday, January 25, 2017 2:17:40 PM > To: Simon Hausmann; releasing at qt-project.org > Subject: Re: Avoiding platform test coverage regressions > > Hi! > > I totally agree with you that missing platforms should block the release. I > would be even tighter, we should get all new platforms we are planning to > support in before feature freeze. But lately it has been really hard to get > new platforms in and that's why we have accepted the situation where > missing platform hasn't been the release blocker. > > And that is one of most important things to be fixed. We need to get new > platforms in ci much easier that it is now. I have seen us fighting to get > new platforms in several months. And that should be only few hours work. It > seems that it is really hard to get all tests passing at same time for that > new platform. We try to get new platform in & find some test failing. > Failures are fixed and new try... Argh, some other test are now failing ;) > And test are fixed and new test are failing... All that has prevented us to > get stuff in. So we need to find a way to get platforms in easier or then > block other development until failed test are fixed & new platform is in. > > br, > Jani > > ________________________________________ > From: Releasing on > behalf of Simon Hausmann Sent: Wednesday, January > 25, 2017 2:31 PM > To: releasing at qt-project.org > Subject: [Releasing] Avoiding platform test coverage regressions > > Hi, > > > I'm writing this email because of a recurring problem with our test coverage > in combination with releases of Qt. > > > Many times in the past we've had the situation where a change was applied to > the CI system that temporarily removed an entire platform, for example in > favor of adding a new one in steps. I'll cite two examples right off the > top of my head, but upon request I can dig up more: > > > (1) During times of qtqa-testconfig we added and removed configurations > without observing what their test coverage was, and at some point near the > 5.3/5.4 release ended up in a situation where our entire cross-platform > network stack was only tested partially on Linux, partly as a consequence > of removing an older Windows (where we ran tests) in favor of a newer > Windows (where we "insignifified" all network tests). We made several > releases with a network stack that was untested on Windows and macOS. > > > (2) Today we are in the situation where we are building Qt and running > tests on macOS 10.11 in the 5.6 branch of Qt. However the changes that > added 10.11 to the CI configuration to provide build and test coverage were > never applied to the 5.7, 5.8 or the dev branch of Qt, leaving us with no > tests run on 10.11. > > > During a related discussion in https://codereview.qt-project.org/#/c/183219/ > I suggested that we use a release blocking bug to track the progress of > changing platforms and that way ensure that we don't release Qt before the > regression of temporarily removing build and/or test coverage is fixed. > > > Tony declined the suggestion with the following statement: > > "We had that. We had a P0 bug to put 10.11 in to 5.7 as it was already in > 5.6, but it got show down as it was seen as definitely not being able to > block a release. And this happened again in 5.8. If everything else is > fine, a missing platform from CI was seen as not to be able to block the > release." > > > I could not find any mention of that in the release team meeting logs > regarding such a decision. > > > I would like to raise the attention to this topic and request either > approval to use blocking release bugs to track these regressions or ask for > suggestions of alternate methods to prevent us from repeatedly running into > the scenario of releasing Qt with regressed build and test coverage. > > > > > Simon > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From Spencer.Schumann at echostar.com Thu Jan 26 17:11:09 2017 From: Spencer.Schumann at echostar.com (Schumann, Spencer) Date: Thu, 26 Jan 2017 16:11:09 +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: > 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Thu Jan 26 17:56:02 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 26 Jan 2017 16:56:02 +0000 Subject: [Releasing] Avoiding platform test coverage regressions In-Reply-To: <1865765.62yUJa2i65@frederik-thinkcentre-m93p> References: <1865765.62yUJa2i65@frederik-thinkcentre-m93p> Message-ID: > -----Original Message----- > From: Releasing [mailto:releasing-bounces+tuukka.turunen=qt.io at qt- > project.org] On Behalf Of Frederik Gladhorn > Sent: torstaina 26. tammikuuta 2017 14.59 > To: releasing at qt-project.org > Subject: Re: [Releasing] Avoiding platform test coverage regressions > > To me new platforms including testing on them are features. > Either they make feature freeze or not. Let's either postpone the feature > freeze or not add them past the poing of the feature freeze. > We all agreed we want a strict feature freeze, so let's not make exceptions > here. This is exactly why I don't think 5.9 will be out according to schedule. I do agree about this in principle, but we can also think it the other way around for the new version of an already supported platform: If the code already works on a new platform version and we know users are using it, should we increase the amount of automated testing even beyond FF if it is possible? For example macOS 10.12 - if we fail to add it by 5.9 FF but can add it after without affecting the release schedule, should we do it? I think we should. But if we consider it to be a blocker for the release, then it should be there already at the FF. Similarly, I think having first the build enforced in CI and then adding the tests step by step is also a viable option. Of course we could take a stand that we block a release of Qt if we can not make it fully tested of a new version of an important platform, but to me that would feel a drastic measure. I would like us to add a new release process step e.g. 4 weeks before FF to have all the supported platforms in place and also all new modules (including possible TP modules) in place. This would help reach FF in time and lower the risk to overall release schedule. Yours, Tuukka From robin.burchell at crimson.no Fri Jan 27 09:07:09 2017 From: robin.burchell at crimson.no (Robin Burchell) Date: Fri, 27 Jan 2017 09:07:09 +0100 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: <1485504429.893913.861240488.64500952@webmail.messagingengine.com> On Thu, Jan 26, 2017, at 01:28 PM, Kai Koehne wrote: > 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 Agreed. In the past, I've had to spend far too much time in "git log" digging up extra changes that should have been mentioned, but weren't. > 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 This seems reasonable, provided there's some guidance about how to use it properly. > * Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx) Sounds good, although I'd suggest that starting off with a slightly softer mallet might be a good idea, at least as an initial transitional step. Maybe making it complain about a lack of ChangeLog tag, but not -1 the change, to start encouraging better habits before they are later enforced. Thinking primarily here about existing pushed, but not merged changes. I don't have hard feelings about this, though. For "under conditions xxx", I'd just apply it to everything. Less difficult to get wrong, and more consistent :) -- Robin Burchell robin at crimson.no From mitch.curtis at qt.io Fri Jan 27 10:20:10 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 27 Jan 2017 09:20:10 +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: It seems that not every reviewer with approval rights is aware (or seems to care, or just forgets) about stuff like this, though. It's a similar problem with docs; no doc team member is added to patches and so you end up with lots of doc issues that they then have to stumble upon after years of it being exposed to the public. From: Releasing [mailto:releasing-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Schumann, Spencer Sent: Thursday, 26 January 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 > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Jan 27 10:54:49 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 27 Jan 2017 09:54:49 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <1485504429.893913.861240488.64500952@webmail.messagingengine.com> References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08> , <1485504429.893913.861240488.64500952@webmail.messagingengine.com> Message-ID: On Thu, Jan 26, 2017, at 01:28 PM, Kai Koehne wrote: >> 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 Robin Burchell replied: > Agreed. In the past, I've had to spend far too much time in "git log" > digging up extra changes that should have been mentioned, but weren't. Would it help if I put up an API review around the time folk are working on change-logs - even when it's for a patch release - so that at least the changes visible in API headers are easy to find ? Or are the lost changes too often elsewhere ? >> 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 > This seems reasonable, provided there's some guidance about how to use > it properly. ... and that guidance is easy to find. A search in our wiki for just "ChangeLog" gets some change-logs, but no obvious guidelines; a search for "ChangeLog guideline" gets nothing. Thankfully a visit to [[Category:Developing Qt::Guidelines]] found me https://wiki.qt.io/Commit_Policy#Change_Log which appears to be the best we have at present; it's very close to what appears in the commit message template. >> * Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx) > Sounds good, although I'd suggest that starting off with a slightly > softer mallet might be a good idea, at least as an initial transitional > step. Maybe making it complain about a lack of ChangeLog tag, but not -1 > the change, to start encouraging better habits before they are later > enforced. Thinking primarily here about existing pushed, but not merged > changes. I don't have hard feelings about this, though. > > For "under conditions xxx", I'd just apply it to everything. Less > difficult to get wrong, and more consistent :) So: gripe about any commit without a ChangeLog. That'll remind reviewers to think about whether one is needed. Simple enough. Eddy. From joerg.bornemann at qt.io Fri Jan 27 12:54:17 2017 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Fri, 27 Jan 2017 12:54:17 +0100 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: <5a7d9f29-a94c-2a73-40e8-10706d36d2b2@qt.io> On 26/01/2017 13:28, Kai Koehne wrote: > 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? Yes, people who cannot be bothered to write a [ChangeLog] line will just add "[ChangeLog] -" to their local template to reduce the overall bossing around from the sanity bot. Then we've gained nothing but a bag of noise in the git log. If anything, enable the [ChangeLog] line in the commit template. The manual action to remove or comment out this line should be enough to remind people of their changelog duty - unless they're using a custom template which you cannot prevent. I claim that you won't find an automatic enforcement that makes manual intervention superfluous when creating change logs. As others already implied, this problem must be solved on a social level. BR, Joerg From Eskil.Abrahamsen-Blomfeldt at qt.io Fri Jan 27 13:58:40 2017 From: Eskil.Abrahamsen-Blomfeldt at qt.io (Eskil Abrahamsen-Blomfeldt) Date: Fri, 27 Jan 2017 12:58:40 +0000 Subject: [Releasing] [Development] Change file process & improvement proposal In-Reply-To: <5a7d9f29-a94c-2a73-40e8-10706d36d2b2@qt.io> References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08> , <5a7d9f29-a94c-2a73-40e8-10706d36d2b2@qt.io> Message-ID: Hi, Seems like the assumption is that people will actively try to sabotage the system because of some hatred of comments :) For me personally, the times I don't add a changelog entry in changes where it would be appropriate, it is simply because I forgot and no one reminded me. I would appreciate the automatic check, as I appreciate the other reminders from the bot, even if there are false positives once in a while (in which case I will just either override the sanity review or add the empty changelog entry to appease the bot.) So count this as my vote for having the sanity bot mention when the changelog is missing. Eskil Abrahamsen Blomfeldt Senior Manager, Qt Graphics/Multimedia The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io ________________________________ Fra: Releasing på vegne av Joerg Bornemann Sendt: 27. januar 2017 12:54:17 Til: releasing at qt-project.org Emne: Re: [Releasing] [Development] Change file process & improvement proposal On 26/01/2017 13:28, Kai Koehne wrote: > 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? Yes, people who cannot be bothered to write a [ChangeLog] line will just add "[ChangeLog] -" to their local template to reduce the overall bossing around from the sanity bot. Then we've gained nothing but a bag of noise in the git log. If anything, enable the [ChangeLog] line in the commit template. The manual action to remove or comment out this line should be enough to remind people of their changelog duty - unless they're using a custom template which you cannot prevent. I claim that you won't find an automatic enforcement that makes manual intervention superfluous when creating change logs. As others already implied, this problem must be solved on a social level. BR, Joerg _______________________________________________ Releasing mailing list Releasing at qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Sat Jan 28 12:46:07 2017 From: jhihn at gmx.com (Jason H) Date: Sat, 28 Jan 2017 12:46:07 +0100 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: References: Message-ID: Aah! I hope not Feb 1. I have Silver Support and I've been wating OVER 2 YEARS for some API changes providing features to land. Some of these are minor, but they are API changes and features. I need time to ruffle the feathers of the developers so they can get the code into 5.9. I know of one issue which is just making a class instance member float into a read-only Q_PROPERTY. The furious pace of major releases coupled with the API lock down is one of my biggest compliants about Qt. Very simply if it isn't a bug fix, I'm going to be waiting at least 12 months before the feature lands. There has got to be a better way. > Sent: Thursday, January 26, 2017 at 6:28 AM > From: "Jani Heikkinen" > To: "development at qt-project.org" > Cc: "releasing at qt-project.org" > Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started > > Hi all, > > 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) > > br, > Jani Heikkinen > Release Manager > The Qt Company > > > > > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing > From thiago.macieira at intel.com Sat Jan 28 19:31:16 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 28 Jan 2017 10:31:16 -0800 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: References: Message-ID: <2417907.sfu9b5zNop@tjmaciei-mobl1> On sábado, 28 de janeiro de 2017 12:46:07 PST Jason H wrote: > The furious pace of major releases coupled with the API lock down is one of > my biggest compliants about Qt. Very simply if it isn't a bug fix, I'm > going to be waiting at least 12 months before the feature lands. > > There has got to be a better way. What do you mean by 12 months? If someone adds finishes a feature by Monday, it will be in the April release. That's 3 months. If they finish the feature on Friday, it'll be in the October/November release. That's the longest possible case and that's 9 or 10 months. Now, reviewing features takes time. If you want it to get in the next release, start early. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Mon Jan 30 16:15:26 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 30 Jan 2017 16:15:26 +0100 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: <2417907.sfu9b5zNop@tjmaciei-mobl1> References: , <2417907.sfu9b5zNop@tjmaciei-mobl1> Message-ID: That's great, but I'm a commercial license owner. Both of these are relatively minor changes that mean a lot to me. Paring my list down to just API changes, I have these two: https://bugreports.qt.io/browse/QTBUG-51133 <- this is the main one I'm talking about (Feb 2016) https://bugreports.qt.io/browse/QTBUG-52013 (Mar 2016) > Sent: Saturday, January 28, 2017 at 1:31 PM > From: "Thiago Macieira" > To: releasing at qt-project.org > Subject: Re: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started > > On sábado, 28 de janeiro de 2017 12:46:07 PST Jason H wrote: > > The furious pace of major releases coupled with the API lock down is one of > > my biggest compliants about Qt. Very simply if it isn't a bug fix, I'm > > going to be waiting at least 12 months before the feature lands. > > > > There has got to be a better way. > > What do you mean by 12 months? If someone adds finishes a feature by Monday, it > will be in the April release. That's 3 months. > > If they finish the feature on Friday, it'll be in the October/November release. > That's the longest possible case and that's 9 or 10 months. > > Now, reviewing features takes time. If you want it to get in the next release, > start early. From thiago.macieira at intel.com Mon Jan 30 18:00:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 Jan 2017 09:00:34 -0800 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: References: <2417907.sfu9b5zNop@tjmaciei-mobl1> Message-ID: <64689147.P6hEdqBiOZ@tjmaciei-mobl1> On segunda-feira, 30 de janeiro de 2017 16:15:26 PST Jason H wrote: > That's great, but I'm a commercial license owner. Both of these are > relatively minor changes that mean a lot to me. > > Paring my list down to just API changes, I have these two: > https://bugreports.qt.io/browse/QTBUG-51133 <- this is the main one I'm > talking about (Feb 2016) https://bugreports.qt.io/browse/QTBUG-52013 (Mar > 2016) If you're submitting the changes yourself and you're not getting the reviews in time, then the Qt Project needs to acommodate you. As I said, the lead time is not 12 months. If you submitted bug reports only, then you got prioritised. It doesn't matter if your change is easy or not. And if you talked to your commercial support, then please ask them why the delay. I'm not privy to your conversaion nor the terms of your commercial contract. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Mon Jan 30 18:27:36 2017 From: jhihn at gmx.com (Jason H) Date: Mon, 30 Jan 2017 18:27:36 +0100 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: <64689147.P6hEdqBiOZ@tjmaciei-mobl1> References: <2417907.sfu9b5zNop@tjmaciei-mobl1> , <64689147.P6hEdqBiOZ@tjmaciei-mobl1> Message-ID: > On segunda-feira, 30 de janeiro de 2017 16:15:26 PST Jason H wrote: > > That's great, but I'm a commercial license owner. Both of these are > > relatively minor changes that mean a lot to me. > > > > Paring my list down to just API changes, I have these two: > > https://bugreports.qt.io/browse/QTBUG-51133 <- this is the main one I'm > > talking about (Feb 2016) https://bugreports.qt.io/browse/QTBUG-52013 (Mar > > 2016) > > If you're submitting the changes yourself and you're not getting the reviews > in time, then the Qt Project needs to acommodate you. As I said, the lead time > is not 12 months. The way the project has been recently run, it is not practicable to get anything done in under 12 months. If my current version is 5.6, and I want an API change, it can't go in 5.7 because it's already in a feature freeze, so there's 6 months. If I can get it scheduled for 5.8, then that's not going to land for a year from 5.6. 5.7 was exactly 6 months from FF to release, 5.8 was just over 6 months. Since no one picked this for 5.8, I'm left still begging for it for 5.9 just before the feature freeze. The support contract is very good for bugs, but for anything else, it's just throwing it over a wall and hoping a developer picks it up, leading me to be vocal on the mailing lists. From thiago.macieira at intel.com Mon Jan 30 19:43:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 Jan 2017 10:43:38 -0800 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: References: <64689147.P6hEdqBiOZ@tjmaciei-mobl1> Message-ID: <3129464.auWTTCLsd6@tjmaciei-mobl1> On segunda-feira, 30 de janeiro de 2017 18:27:36 PST Jason H wrote: > > On segunda-feira, 30 de janeiro de 2017 16:15:26 PST Jason H wrote: > > > That's great, but I'm a commercial license owner. Both of these are > > > relatively minor changes that mean a lot to me. > > > > > > Paring my list down to just API changes, I have these two: > > > https://bugreports.qt.io/browse/QTBUG-51133 <- this is the main one I'm > > > talking about (Feb 2016) https://bugreports.qt.io/browse/QTBUG-52013 > > > (Mar > > > 2016) > > > > If you're submitting the changes yourself and you're not getting the > > reviews in time, then the Qt Project needs to acommodate you. As I said, > > the lead time is not 12 months. > > The way the project has been recently run, it is not practicable to get > anything done in under 12 months. Features going in to 5.9 prove you wrong. > If my current version is 5.6, and I want > an API change, it can't go in 5.7 because it's already in a feature freeze, > so there's 6 months. If I can get it scheduled for 5.8, then that's not > going to land for a year from 5.6. 5.7 was exactly 6 months from FF to > release, 5.8 was just over 6 months. Since no one picked this for 5.8, I'm > left still begging for it for 5.9 just before the feature freeze. "If my current version" doesn't make sense. The current version is not specific to you. It is the same for everyone. The current branch in development (for two more days) is the 5.9 version. It's the same for everyone. If you had started your feature two weeks ago and got it reviewed last week, it would make it into 5.9. If you start it next week, your feature will be submitted to 5.10. You don't need to wait 6 months to submit it: it can be included at the moment that it is ready. So if you start next week and finish it by the end of February, it will be included in February. It will get released when 5.10 is, which should be at the latest in November, which would be the 9 months worst-case-scenario I talked about. Yes, schedules slip. That's unfortunate. But adding more features closer to the release isn't going to make that any better. It's far more likely to destabilise further and cause more delays. The problem to be solved is not the feature admission process, it's the stabilisation and release process. > The support contract is very good for bugs, but for anything else, it's > just throwing it over a wall and hoping a developer picks it up, leading me > to be vocal on the mailing lists. And that's ok. I appreciate hearing you, because I get to hear what's important to you and to others. As I said, I'm not privy to the discussion between you and your support contact. They can't release your name to me either, so I don't know behind a report whether how many would want the feature. And sorry, but I haven't implemented almost anything submitted as feature wishes in the bugtracker either. I have my hands full with reviews, bugfixes and the features I want done. So as it stands, if you want a feature, you have to get it done yourself (or paying for it). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Tue Jan 31 09:09:13 2017 From: tuukka.turunen at qt.io (Tuukka, Turunen) Date: Tue, 31 Jan 2017 08:09:13 +0000 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: <3129464.auWTTCLsd6@tjmaciei-mobl1> References: <64689147.P6hEdqBiOZ@tjmaciei-mobl1> <3129464.auWTTCLsd6@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Releasing [mailto:releasing-bounces+tuukka.turunen=qt.io at qt- > project.org] On Behalf Of Thiago Macieira > Sent: maanantaina 30. tammikuuta 2017 20.44 > To: releasing at qt-project.org > Subject: Re: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started > > On segunda-feira, 30 de janeiro de 2017 18:27:36 PST Jason H wrote: > > > On segunda-feira, 30 de janeiro de 2017 16:15:26 PST Jason H wrote: > > > > That's great, but I'm a commercial license owner. Both of these > > > > are relatively minor changes that mean a lot to me. > > > > > > > > Paring my list down to just API changes, I have these two: > > > > https://bugreports.qt.io/browse/QTBUG-51133 <- this is the main > > > > one I'm talking about (Feb 2016) > > > > https://bugreports.qt.io/browse/QTBUG-52013 > > > > (Mar > > > > 2016) > > > > > > If you're submitting the changes yourself and you're not getting the > > > reviews in time, then the Qt Project needs to acommodate you. As I > > > said, the lead time is not 12 months. > > > > The way the project has been recently run, it is not practicable to > > get anything done in under 12 months. > > Features going in to 5.9 prove you wrong. > We have almost always dev branch open for new development. Since 5.8 branched from dev on 22nd August 2016 new features merged there will be part of Qt 5.9. Soon dev will be the place to put features targeting Qt 5.10. If you need longer time to develop a feature, we can arrange a WIP branch that can be merged to dev when the time is right (i.e. it does not have to go in to the next release). We can also make playground repos for maturing something over time to one day be a new module in Qt when seen fit. > > If my current version is 5.6, and I want an API change, it can't go in > > 5.7 because it's already in a feature freeze, so there's 6 months. If > > I can get it scheduled for 5.8, then that's not going to land for a > > year from 5.6. 5.7 was exactly 6 months from FF to release, 5.8 was > > just over 6 months. Since no one picked this for 5.8, I'm left still > > begging for it for 5.9 just before the feature freeze. > > "If my current version" doesn't make sense. The current version is not > specific to you. It is the same for everyone. > > The current branch in development (for two more days) is the 5.9 version. > It's the same for everyone. If you had started your feature two weeks ago > and got it reviewed last week, it would make it into 5.9. > > If you start it next week, your feature will be submitted to 5.10. You don't > need to wait 6 months to submit it: it can be included at the moment that it is > ready. So if you start next week and finish it by the end of February, it will be > included in February. It will get released when 5.10 is, which should be at the > latest in November, which would be the 9 months worst-case-scenario I > talked about. > > Yes, schedules slip. That's unfortunate. But adding more features closer to > the release isn't going to make that any better. It's far more likely to > destabilise further and cause more delays. The problem to be solved is not > the feature admission process, it's the stabilisation and release process. > With Qt 5.9 we are aiming to keep the schedule better than with many of our previous releases. Looking into reasons for the delays, one of the biggest reason is not respecting the feature freeze. By agreeing upon exception to squeeze some feature in we often hurt all others. Similarly pushing in something that really is not yet ready can cause delays in the maturization phase. Everyone wants new features. We just should also start trusting that there will be a new release in 6 months time, if work is not ready in time for the next release. > > The support contract is very good for bugs, but for anything else, > > it's just throwing it over a wall and hoping a developer picks it up, > > leading me to be vocal on the mailing lists. > > And that's ok. I appreciate hearing you, because I get to hear what's > important to you and to others. As I said, I'm not privy to the discussion > between you and your support contact. They can't release your name to me > either, so I don't know behind a report whether how many would want the > feature. > Both of the mentioned issues are known by support and in the priority queue. One of them is in progress and the other not yet. Being in the priority queue does not automatically mean the bug (or feature request) gets implemented immediately, but we do take into account factors such as how many licenses the customer has, how many other customers have reported it, what the regular bug priority is, can it be worked around or does it completely block the customer, how big an effort it is, etc. Yours, Tuukka > And sorry, but I haven't implemented almost anything submitted as feature > wishes in the bugtracker either. I have my hands full with reviews, bugfixes > and the features I want done. So as it stands, if you want a feature, you have > to get it done yourself (or paying for it). > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From jani.heikkinen at qt.io Tue Jan 31 16:36:32 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 31 Jan 2017 15:36:32 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 31.1.2017 Message-ID: Meeting minutes from Qt Release Team meeting 31st January 2017 Qt 5.9 status: * Soft branching ongoing * Target to have final downmerge from 'dev' to '5.9' and Qt 5.9 feature freeze Wed 1st February * Won't be done first on morning but later that day to give a bit more time to get final things in. * All new platforms aren't in ci yet but will be added in before alpha * Target to create alpha packages immediately when needed platforms in and qt5.git integration succeed in '5.9' * API review to be started immediately after final downmerge. Not blocking the alpha but should be in mostly done before it Next meeting Tue 7th Feb 16:00 CET br, Jani irc log below: [17:00:11] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:00:26] jaheikki3: pong [17:00:36] jaheikki3: pong [17:00:40] jaheikki3: pong [17:01:12] Time to start qt release team meeting [17:01:20] On agenda today: [17:01:30] Qt 5.9 (ff) status [17:01:41] Any additional item to the agenda? [17:03:22] Ok, let's browse through the 5.9 status [17:04:04] Soft branching ongoing, target to have final downmerge from 'dev' to '5.9' tomorrow [17:05:17] We don't have all new platforms in yet & there were some ci issues due to RHEL icenses etc but the plan is still to do the final downmerge & FF as planned [17:05:40] & add missing platforms etc in '5.9' and before alpha release [17:06:37] But maybe we should do the final downmerge & ff a bit later tomorrow so that people can still get final issues in 'dev' [17:08:03] And I think we can do Aplha release as soon as possible after new platforms are in '5.9' & qt5.git integration succeed there [17:08:10] Any comments / questions? [17:08:52] Hm..is API review in progress? [17:09:00] qtwebengine will still need a large merge after the alpha, the 55-based merge won't be ready, but we have done such merges previously between alpha and beta [17:09:00] BC, etc [17:09:28] fkleint: API review will be done between alpha & beta as usual [17:09:56] carewolf: yeah, that should be OK (as usual) [17:10:20] jaheikki3: why not start API review earlier? [17:10:42] yep, since alpha is basically useless without... [17:11:26] API review starts now and needs to finish by beta [17:12:02] isn't that the alpha means that "we developer believe that the software is ok" [17:12:15] cough, cough [17:12:25] no that is rc [17:12:40] nierob: Well, I think alpha is for api review [17:14:07] but yes, we should start reviewing API and I'll ask eddy to create those diffs etc for "official review" when alpha content ready [17:15:07] Any other comments/questions? [17:15:12] alpha is "hey, cool new stuff, tell us what you think" [17:15:26] so... yeah, you're right, API review shoud be finished [17:15:45] beta is implementation test, not API [17:15:57] (or mostly finished, I guess) [17:16:04] thiago: yes, that was my understanding :-) [17:16:20] have we had a discussion here of the timeline of 5.8.1 and 5.6.3 here? or the lack there of? [17:17:22] carewolf: not yet. Let's first see the feedback from 5.8.0 & get 5.9 alpha out and then discuss about those [17:17:34] ok [17:18:29] thiago: so did you mean we should have API review before alpha or between alpha and beta (as it has been earlier)? [17:19:23] we should start now and have it mostly finished by alpha [17:19:42] I think we should do it as earlier but of course start reviewing immediately to be able to fix possible findings as soon as possible. But not waiting that fully done before releasing alpha [17:20:02] BC review is done after the release branch is created [17:20:31] err, but also prefereably as soon as possible [17:20:32] yeah & we should have bc test ongiing all the time [17:20:55] the problem of doing it early is not catching a late mistake [17:20:58] most important here, avoid branch mess (imcompatible modules) across release branch/5.9 by all means [17:21:30] Ok, I'll ask eddy to do needed diffs etc as soon as possible [17:22:35] ok [17:23:03] I think it was all at this time. let's skip next weeks meeting & have new one 14th February, ok? [17:23:25] not on 7th? [17:23:34] no exciting things happening? [17:24:00] ok, anywayas [17:24:17] fkleint: well, we can have short one then as wekll if needed [17:24:26] yup, short update [17:24:41] That's ok. Let's have one also 7th Feb [17:25:09] Let's end this meeting now. Thanks your participation. Bye! [17:27:05] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Tue Jan 31 16:50:42 2017 From: jhihn at gmx.com (Jason H) Date: Tue, 31 Jan 2017 16:50:42 +0100 Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.9' started In-Reply-To: References: <64689147.P6hEdqBiOZ@tjmaciei-mobl1> <3129464.auWTTCLsd6@tjmaciei-mobl1>, Message-ID: > Sent: Tuesday, January 31, 2017 at 3:09 AM > From: "Tuukka, Turunen" > > > The support contract is very good for bugs, but for anything else, > > > it's just throwing it over a wall and hoping a developer picks it up, > > > leading me to be vocal on the mailing lists. > > > > And that's ok. I appreciate hearing you, because I get to hear what's > > important to you and to others. As I said, I'm not privy to the discussion > > between you and your support contact. They can't release your name to me > > either, so I don't know behind a report whether how many would want the > > feature. > > > > Both of the mentioned issues are known by support and in the priority queue. One of them is in progress and the other not yet. Being in the priority queue does not automatically mean the bug (or feature request) gets implemented immediately, but we do take into account factors such as how many licenses the customer has, how many other customers have reported it, what the regular bug priority is, can it be worked around or does it completely block the customer, how big an effort it is, etc. > Thanks for the insight. I completely acknowledge that my startup is a small fish in a big pond, and I have the utmost respect for the project, having it be my absolute favorite tech and using it professionally since 2004. The features I suggest, I mean _really_ suggest (I know I throw a lot of "what ifs" out there) and push for I make sure would benefit everyone. Generally these issues come from a lack of foresight about how the tech will be used in the wild, which is impossible to predict. Many times these can be a big fix, but on occasion they need an API change. Qt is a little more difficult in that it has a self-imposed binary compatibility requirement (which works to various degrees, but that's another discussion). The two API changes that I requested stem from a lack of API completeness. I figure API completeness would have it's own dimension in prioritization? The two issues (so you don't have to search): The QML LocalStorage API used a private function for file path, so it could not share the location of its database (say for use with QSqlDatabase on the C++ side), without reverse engineering the local storage file naming function. (And there is no guarantee that Qt won't change it later). There is now a patch for that, but I don't know if I'll get pulled into 5.9... https://codereview.qt-project.org/#/c/181736/ The other one, the current Font comes from using QML Text Fit settings - there is no way to determine what it ended up using. This is important when a designer tells you that a fint should take up 10% of the height of the screen, and the rest of the text should be relative to that. At first glance you could impose the same height constraint, but then when you go multi-line it's just not possible. There is now code for this and it's in!! (thanks Eskil & co!) https://codereview.qt-project.org/#/c/184005/ From edward.welbourne at qt.io Tue Jan 31 17:52:47 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 31 Jan 2017 16:52:47 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 31.1.2017 In-Reply-To: References: Message-ID: Jani Heikkinen: > * API review to be started immediately after final downmerge. 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 ... Eddy.