From Lars.Knoll at theqtcompany.com Tue Dec 1 09:11:47 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 1 Dec 2015 08:11:47 +0000 Subject: [Releasing] qtwebkit 5.5.2 or 5.6.0 In-Reply-To: <6436297.Kmkp4EbNRR@tjmaciei-mobl4> References: <2784470.unZ8K7SGxs@tjmaciei-mobl4> <26857263.8uF8lcgcMT@frederik-thinkcentre-m93p> <2953710.E0edDcyU1H@tonks> <6436297.Kmkp4EbNRR@tjmaciei-mobl4> Message-ID: <2893600F-69E0-46D0-85C6-6490F74D7344@theqtcompany.com> On 30/11/15 18:23, "Releasing on behalf of Thiago Macieira" wrote: >On Monday 30 November 2015 12:49:49 Lisandro Damián Nicanor Pérez Meyer wrote: >> On Monday 30 November 2015 13:13:10 Frederik Gladhorn wrote: >> [snip] >> >> > As for source tarballs I think we have so far not considered producing >> > tarballs as Jani writes, why do you see the necessity? >> >> Distributions who have lots of apps still using qtwebkit will simply love >> these tarballs. As a last resort we can create them from git but still >> better if we can use an upstream tarball. > >That is a good reason. The other is the fact that our tarballs are not simple >equivalents of git archive, so there's some post-processing left-over that >some users will not realise they need. > >Asking people to download from Git will lead them to download from GitHub: > https://github.com/qtproject/qtwebkit/archive/dev.zip > >And we know the build from a git archive export does *not* *work*. > >Please create the tarballs and upload them. They don't have to be built to >binary and they don't have to be part of the joined source code, but they will >need to exist. > >And we'll need to keep releasing every time that we change qtbase in such a >way that breaks the build of those modules. The reason for removing modules is to stop having to worry about them. Like this we’ll save very little work in our packaging/releasing. Actually this would be some extra work, as the packages would fall outside the regular workflow. In addition, this conflicts with your message on development about keeping compatibility on the build system level. If we stop supporting a module, we shouldn’t have to do any more releases on it. But this clearly shows that we need to simplify our source packages creation to a git archive call (without further post processing). We haven’t done it so far because people will then need additional build tools (esp. on Windows). But given this, we need to get to that state rather soon, to avoid these kind of problems. Cheers, Lars From thiago.macieira at intel.com Tue Dec 1 17:17:41 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 01 Dec 2015 08:17:41 -0800 Subject: [Releasing] qtwebkit 5.5.2 or 5.6.0 In-Reply-To: <2893600F-69E0-46D0-85C6-6490F74D7344@theqtcompany.com> References: <2784470.unZ8K7SGxs@tjmaciei-mobl4> <6436297.Kmkp4EbNRR@tjmaciei-mobl4> <2893600F-69E0-46D0-85C6-6490F74D7344@theqtcompany.com> Message-ID: <1591090.OAQBrBriGq@tjmaciei-mobl4> On Tuesday 01 December 2015 08:11:47 Knoll Lars wrote: > >And we'll need to keep releasing every time that we change qtbase in such a > > > > way that breaks the build of those modules. > > In addition, this conflicts with your message on development about keeping > compatibility on the build system level. If we stop supporting a module, we > shouldn’t have to do any more releases on it. That's because I wrote this email before that one. I changed my mind: I think we need to keep compatibility, which means that instead of releasing new versions of qtwebkit and qtscript, we'll need to compile the old ones with our new releases as part of our release testing. We can't stop worrying about them, at least not for the next year or so. > But this clearly shows that we need to simplify our source packages creation > to a git archive call (without further post processing). We haven’t done it > so far because people will then need additional build tools (esp. on > Windows). But given this, we need to get to that state rather soon, to > avoid these kind of problems. All that is missing is to rewrite syncqt from Perl to C++. Either we use Standard Library C++ or merge it into qmake if we want to use Qt classes. Given that it is going to open files and all the Unicode issues on Windows, I think the latter is the better way forward. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at theqtcompany.com Wed Dec 2 12:11:04 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 2 Dec 2015 12:11:04 +0100 Subject: [Releasing] qtwebkit 5.5.2 or 5.6.0 In-Reply-To: <1591090.OAQBrBriGq@tjmaciei-mobl4> References: <2784470.unZ8K7SGxs@tjmaciei-mobl4> <6436297.Kmkp4EbNRR@tjmaciei-mobl4> <2893600F-69E0-46D0-85C6-6490F74D7344@theqtcompany.com> <1591090.OAQBrBriGq@tjmaciei-mobl4> Message-ID: <20151202111104.GC8426@troll08.it.local> On Tue, Dec 01, 2015 at 08:17:41AM -0800, Thiago Macieira wrote: > On Tuesday 01 December 2015 08:11:47 Knoll Lars wrote: > > But this clearly shows that we need to simplify our source packages creation > > to a git archive call (without further post processing). We haven’t done it > > so far because people will then need additional build tools (esp. on > > Windows). But given this, we need to get to that state rather soon, to > > avoid these kind of problems. > > All that is missing is to rewrite syncqt from Perl to C++. Either we use > Standard Library C++ or merge it into qmake if we want to use Qt classes. > i've been pondering this just a few days ago with joerg. it sort of makes sense to put it into qmake (the minimal syncqt needed to bootstrap qmake can be easily re-implemented with sh and cmd). what i don't like about this is that this is rather heavily qt-specific, so it's a bit ugly to put it into the more or less generic code in qmake. ah, well ... i've also considered rewriting it in the qmake language, but it would be really abysmally slow. a middle ground may be exposing a parametrizable "c++ preprocessor and parser kernel" which would be used also by the dependency and automoc scanners. eddy had "fun" with this code just recently. how's that for a project? ^^ > Given that it is going to open files and all the Unicode issues on > Windows, I think the latter is the better way forward. > qmake just uses latin1 (windows) or 8-bit pass-through (unix) anyway. but that has never been a serious problem for qt itself. let me also remind you of https://bugreports.qt.io/browse/QTBUG-27896 ;) note that there is another problem in the way of shipping git archives as distributables: configure.exe. at a minimum, the help content needs to be extracted into a static .txt file, so configure.bat can just dump it when it's called with /help. then it will be ok to always bootstrap configure.exe. the help output of the unix configure is mostly static already, so it should be fairly easy to unify it. From thiago.macieira at intel.com Wed Dec 2 22:20:27 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Dec 2015 13:20:27 -0800 Subject: [Releasing] qtwebkit 5.5.2 or 5.6.0 In-Reply-To: <20151202111104.GC8426@troll08.it.local> References: <2784470.unZ8K7SGxs@tjmaciei-mobl4> <1591090.OAQBrBriGq@tjmaciei-mobl4> <20151202111104.GC8426@troll08.it.local> Message-ID: <3519370.IT6Dhbhs6b@tjmaciei-mobl4> On Wednesday 02 December 2015 12:11:04 Oswald Buddenhagen wrote: > it sort of makes sense to put it into qmake (the minimal syncqt needed > to bootstrap qmake can be easily re-implemented with sh and cmd). > what i don't like about this is that this is rather heavily qt-specific, > so it's a bit ugly to put it into the more or less generic code in > qmake. ah, well ... It's not like qmake is agnostic of Qt... it has quite a few Qt'isms there. And people who do CONFIG -= qt know that there may be dragons, since we don't really test that. > i've also considered rewriting it in the qmake language, but it would be > really abysmally slow. > > a middle ground may be exposing a parametrizable "c++ preprocessor and > parser kernel" which would be used also by the dependency and automoc > scanners. eddy had "fun" with this code just recently. how's that for a > project? ^^ Indeed, that would be nice. > > Given that it is going to open files and all the Unicode issues on > > Windows, I think the latter is the better way forward. > > qmake just uses latin1 (windows) or 8-bit pass-through (unix) anyway. > but that has never been a serious problem for qt itself. > let me also remind you of https://bugreports.qt.io/browse/QTBUG-27896 ;) Important, but orthogonal issue. The point is that qmake needs to be able to work when Qt sources or build target are on a path that contains non-local8bit characters on Windows. I don't know if that works now, but I'd rather we didn't make things worse. I think the MinGW runtime library has a function that allows you to set the encoding of filenames in the API to UTF-8 (I think we used it in Subsurface), but I'd be surprised if the same function exists on MSVC. > note that there is another problem in the way of shipping git archives > as distributables: configure.exe. Why? > at a minimum, the help content needs to be extracted into a static .txt > file, so configure.bat can just dump it when it's called with /help. Oh. Yeah, people complained that configure -help started building stuff. We can have a minimal help that says that the full help requires building configure first. This minimal output wouldn't need to be maintained per platform, it would be just the immutable basics. > then it will be ok to always bootstrap configure.exe. > the help output of the unix configure is mostly static already, so > it should be fairly easy to unify it. The problem is that the configures take different options. There are switches that exist only for Unix and not for configure.exe. Unifying the switches is more work that we don't need now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at theqtcompany.com Thu Dec 3 11:13:59 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 3 Dec 2015 11:13:59 +0100 Subject: [Releasing] qtwebkit 5.5.2 or 5.6.0 In-Reply-To: <3519370.IT6Dhbhs6b@tjmaciei-mobl4> References: <2784470.unZ8K7SGxs@tjmaciei-mobl4> <1591090.OAQBrBriGq@tjmaciei-mobl4> <20151202111104.GC8426@troll08.it.local> <3519370.IT6Dhbhs6b@tjmaciei-mobl4> Message-ID: <20151203101359.GB21863@troll08.it.local> On Wed, Dec 02, 2015 at 01:20:27PM -0800, Thiago Macieira wrote: > On Wednesday 02 December 2015 12:11:04 Oswald Buddenhagen wrote: > > at a minimum, the help content needs to be extracted into a static > > .txt file, so configure.bat can just dump it when it's called with > > /help. > > Oh. Yeah, people complained that configure -help started building > stuff. We can have a minimal help that says that the full help > requires building configure first. This minimal output wouldn't need > to be maintained per platform, it would be just the immutable basics. > nah, i don't want "minimal". then you could point to the readme just as well. > > then it will be ok to always bootstrap configure.exe. > > the help output of the unix configure is mostly static already, so > > it should be fairly easy to unify it. > > The problem is that the configures take different options. There are switches > that exist only for Unix and not for configure.exe. Unifying the switches is > more work that we don't need now. > the differences are quite minimal at this point, and resolving them is a worthy goal in itself. the problem of inherently platform-specific switches exists even within the existing configures. this is best dealt with by documenting the switches as such. it would be even an improvement from the user perspective to have everything spelled out consistently - it's actually the usual argument about the evils of dynamic user interfaces. From jani.heikkinen at theqtcompany.com Wed Dec 9 09:48:30 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 9 Dec 2015 08:48:30 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 08.12.2015 Message-ID: Meeting minutes from Qt Release Team meeting 8th December 2015 Qt 5.6 Beta status: - New snapshot under testing, no new blockers reported so far - Latest qt5.git should contain fixes for remaining open beta blockers * Packaging ongoing, we should have beta candidate packages for testing latest tomorrow - Target is to release these new packages as Qt 5.6.0 beta Mon 14th Dec if nothing new & serious enough found during testing Qt 5.7 Feature Freeze: - We need to postpone the Qt 5.7 feature freeze at least until the Qt 5.6 beta is done * ML discussion needed to agree if 5.7 FF can be between beta and RC. Jani will initiate discussion soon. Next meeting: 5.1.2016 15:00 CET (If beta released as agreed) br, Jani irc log below: [17:00:45] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:01:05] jaheikki3: pong [17:02:05] jaheikki3: pong [17:02:21] jaheikki3: pong [17:02:33] time to start qt release team meeting [17:02:38] On agenda today: [17:02:48] - Qt 5.6.0 beta status [17:03:00] - Qt 5.7 feature freeze [17:03:10] Any additional item to the agenda? [17:04:47] let's start from Qt 5.6.0 beta status: [17:05:13] -new snapshot under testing, no new blockers reported so far [17:05:33] - Two old ones still open, fixes in latest qt5.git [17:06:13] - creator build ongoing. When succeed i'll start new installer builds [17:07:00] -> we should have beta candidate packages for testing during tomorrow [17:07:44] Then some testing & beta out if nothing serious found during testing [17:08:17] We are targeting to release beta next monday [17:08:25] Any comments or questions? [17:08:58] Commercial examples in? [17:09:35] fkleint: Unfortunately no :( But it has been agreed earlier that it won't block the beta [17:09:54] hm,ok [17:11:31] ok, that was all about 5.6 beta at the moment [17:11:41] then Qt 5.7 feature freeze: [17:12:46] we haven't released the beta for the feature-frozen Qt 5.6 [17:12:52] at the very least, that should happen first [17:13:00] so Qt 5.7 feature freeze needs to be pushed to next year [17:13:17] thiago: That was just what I meant to propose ;) [17:13:35] We need to get beta out first at least [17:13:53] I was planning to propose new ff date 15th Jan [17:14:19] I would prefer after the RC also, so we don't push multiple places at the same time [17:14:47] I would prefer that too, but I wasn't going to suggest being so radical [17:15:01] let's do this: it needs to be a ML discussion, with lars's ok [17:15:32] I'm ok with shortening a little, like between 5.6 beta anad RC [17:17:39] ok for me. Ideally it should be after RC but on the other hand I don't want to delay 5.7 final so much... let's agree that via ML, I can initiate discussion. Should I use release or dev ML? [17:21:00] dev [17:21:47] Ok, i'll start discussion there [17:23:37] thanks [17:25:03] I think it was all at this time. I think we can skip next week's meeting and then it is christmas week -> I propose to have next meeting 5.1.2016 at this same time. OK? [17:25:30] assuming beta is out, otherwise we might still need it [17:26:46] carewolf: Yeah, true. If beta isn't out let's have a meeting next week. But if it is then let's have next meeting 5.1.2016 [17:26:47] let me check if I can join at this time on 5.1 [17:27:09] where in the world will I be [17:27:47] thiago: ;) We can tune the time if needed [17:28:29] I'll be in Chicago from 6:20 to 9:20 CST [17:28:39] so the best time would be 8:00 am CST, which is... [17:29:08] 15:00 CET / 16:00 EET [17:29:10] one hour earlier [17:29:13] can we do that? [17:29:56] Ok for me [17:31:12] +1 [17:32:04] OK, great. Let's end this meeting now, put beta out & have new neeting 5.1.2016 15:00 CET [17:32:16] Thanks your participation! bye [17:33:33] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Wed Dec 9 11:44:33 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 9 Dec 2015 11:44:33 +0100 Subject: [Releasing] [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <22298513.hvfALFAysn@finn> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn> Message-ID: <20151209104433.GB29009@troll08.it.local> On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > > We should then keep build tests for these modules in the CI. > > Otherwise we won't notice breakages. > > I agree. > this is true. but that basically defeats the whole point, which was not needing to care about these modules any more. now reality caught up already and it turns out that i broke webkit. well, what i actually did, i broke bug-to-bug compatibility, which exposed a pre-existing problem in webkit, as it usually goes. it would be possible to revert the respective qmake change (and uglify the surrounding code), but i don't think it's reasonable to enforce this type of stagnation - we generally accept that code which relies on undefined or outright broken behavior is broken by fixes. so how do we go from there? i see several options: - continue to drag along webkit and the other deprecated modules. the additional cost of actually doing that in addition to compatibility testing is rather low with the new CI. - release further 5.5.x versions of these modules when necessary. i expect this to be a lot more effort than the first option, so it doesn't seem reasonable. - simply accept that it's broken, and tell people to apply patches. From Kai.Koehne at theqtcompany.com Thu Dec 10 15:37:57 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 10 Dec 2015 14:37:57 +0000 Subject: [Releasing] [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: <20151209104433.GB29009@troll08.it.local> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn> <20151209104433.GB29009@troll08.it.local> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Oswald Buddenhagen > Sent: Wednesday, December 09, 2015 11:45 AM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: Re: [Development] buildsystem now needs to keep behaviour > compatibility > > On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: > > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > > > We should then keep build tests for these modules in the CI. > > > Otherwise we won't notice breakages. > > > > I agree. > > > this is true. > but that basically defeats the whole point, which was not needing to care > about these modules any more. > > now reality caught up already and it turns out that i broke webkit. > well, what i actually did, i broke bug-to-bug compatibility, which exposed a > pre-existing problem in webkit, as it usually goes. > > it would be possible to revert the respective qmake change (and uglify the > surrounding code), but i don't think it's reasonable to enforce this type of > stagnation - we generally accept that code which relies on undefined or > outright broken behavior is broken by fixes. > > so how do we go from there? i see several options: > - continue to drag along webkit and the other deprecated modules. the > additional cost of actually doing that in addition to compatibility > testing is rather low with the new CI. I think this is a good compromise. Let's do at least some minimal compile testing before a release, and fix the stuff that's absolutely necessary. We can talk again in case we run into issues that would require some real work... https://bugreports.qt.io/browse/QTBUG-49883 Regards Kai > - release further 5.5.x versions of these modules when necessary. i > expect this to be a lot more effort than the first option, so it > doesn't seem reasonable. > - simply accept that it's broken, and tell people to apply patches. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at theqtcompany.com Thu Dec 10 15:37:57 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 10 Dec 2015 14:37:57 +0000 Subject: [Releasing] [Development] buildsystem now needs to keep behaviourcompatibility In-Reply-To: <20151209104433.GB29009@troll08.it.local> References: <2394178.nH4WTEmeSG@tjmaciei-mobl4><565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn><20151209104433.GB29009@troll08.it.local> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Oswald Buddenhagen > Sent: Wednesday, December 09, 2015 11:45 AM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: Re: [Development] buildsystem now needs to keep behaviour > compatibility > > On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: > > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: > > > We should then keep build tests for these modules in the CI. > > > Otherwise we won't notice breakages. > > > > I agree. > > > this is true. > but that basically defeats the whole point, which was not needing to care > about these modules any more. > > now reality caught up already and it turns out that i broke webkit. > well, what i actually did, i broke bug-to-bug compatibility, which exposed a > pre-existing problem in webkit, as it usually goes. > > it would be possible to revert the respective qmake change (and uglify the > surrounding code), but i don't think it's reasonable to enforce this type of > stagnation - we generally accept that code which relies on undefined or > outright broken behavior is broken by fixes. > > so how do we go from there? i see several options: > - continue to drag along webkit and the other deprecated modules. the > additional cost of actually doing that in addition to compatibility > testing is rather low with the new CI. I think this is a good compromise. Let's do at least some minimal compile testing before a release, and fix the stuff that's absolutely necessary. We can talk again in case we run into issues that would require some real work... https://bugreports.qt.io/browse/QTBUG-49883 Regards Kai > - release further 5.5.x versions of these modules when necessary. i > expect this to be a lot more effort than the first option, so it > doesn't seem reasonable. > - simply accept that it's broken, and tell people to apply patches. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at theqtcompany.com Fri Dec 11 08:44:29 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 11 Dec 2015 07:44:29 +0000 Subject: [Releasing] [Development] buildsystem now needs to keep behaviour compatibility In-Reply-To: References: <2394178.nH4WTEmeSG@tjmaciei-mobl4> <565EB745.8080507@theqtcompany.com> <22298513.hvfALFAysn@finn> <20151209104433.GB29009@troll08.it.local> Message-ID: <354D5F9D-0E08-46F4-AAED-5BB2E4927AB5@theqtcompany.com> On 10/12/15 15:37, "Development on behalf of Koehne Kai" wrote: > > >> -----Original Message----- >> From: Development [mailto:development-bounces at qt-project.org] On >> Behalf Of Oswald Buddenhagen >> Sent: Wednesday, December 09, 2015 11:45 AM >> To: development at qt-project.org >> Cc: releasing at qt-project.org >> Subject: Re: [Development] buildsystem now needs to keep behaviour >> compatibility >> >> On Wed, Dec 02, 2015 at 01:04:40PM +0100, Olivier Goffart wrote: >> > On Wednesday 2. December 2015 10:17:57 Joerg Bornemann wrote: >> > > We should then keep build tests for these modules in the CI. >> > > Otherwise we won't notice breakages. >> > >> > I agree. >> > >> this is true. >> but that basically defeats the whole point, which was not needing to care >> about these modules any more. >> >> now reality caught up already and it turns out that i broke webkit. >> well, what i actually did, i broke bug-to-bug compatibility, which exposed a >> pre-existing problem in webkit, as it usually goes. >> >> it would be possible to revert the respective qmake change (and uglify the >> surrounding code), but i don't think it's reasonable to enforce this type of >> stagnation - we generally accept that code which relies on undefined or >> outright broken behavior is broken by fixes. >> >> so how do we go from there? i see several options: >> - continue to drag along webkit and the other deprecated modules. the >> additional cost of actually doing that in addition to compatibility >> testing is rather low with the new CI. > >I think this is a good compromise. Let's do at least some minimal compile testing before a release, and fix the stuff that's absolutely necessary. We can talk again in case we run into issues that would require some real work... +1. This is probably the best compromise we can come up with. Cheers, Lars > >https://bugreports.qt.io/browse/QTBUG-49883 > >Regards > >Kai > > >> - release further 5.5.x versions of these modules when necessary. i >> expect this to be a lot more effort than the first option, so it >> doesn't seem reasonable. >> - simply accept that it's broken, and tell people to apply patches. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at theqtcompany.com Tue Dec 15 14:15:22 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 15 Dec 2015 13:15:22 +0000 Subject: [Releasing] Meeting minutes: Qt release team meeting 08.12.2015 In-Reply-To: References: Message-ID: No release team meeting today (even beta isn't released yet). We found new blocker (QTBUG-49886) from latest packages. Fix is available and in qt5.git (just integrated). Packaging started, we should have new beta candidate packages for testing tomorrow. And if those are OK then just release those packages as Qt 5.6.0 beta at the end of this week or at the beginning on next one. br, Jani ________________________________ Lähettäjä: Heikkinen Jani Lähetetty: 9. joulukuuta 2015 10:48 Vastaanottaja: releasing at qt-project.org Aihe: Meeting minutes: Qt release team meeting 08.12.2015 Meeting minutes from Qt Release Team meeting 8th December 2015 Qt 5.6 Beta status: - New snapshot under testing, no new blockers reported so far - Latest qt5.git should contain fixes for remaining open beta blockers * Packaging ongoing, we should have beta candidate packages for testing latest tomorrow - Target is to release these new packages as Qt 5.6.0 beta Mon 14th Dec if nothing new & serious enough found during testing Qt 5.7 Feature Freeze: - We need to postpone the Qt 5.7 feature freeze at least until the Qt 5.6 beta is done * ML discussion needed to agree if 5.7 FF can be between beta and RC. Jani will initiate discussion soon. Next meeting: 5.1.2016 15:00 CET (If beta released as agreed) br, Jani irc log below: [17:00:45] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:01:05] jaheikki3: pong [17:02:05] jaheikki3: pong [17:02:21] jaheikki3: pong [17:02:33] time to start qt release team meeting [17:02:38] On agenda today: [17:02:48] - Qt 5.6.0 beta status [17:03:00] - Qt 5.7 feature freeze [17:03:10] Any additional item to the agenda? [17:04:47] let's start from Qt 5.6.0 beta status: [17:05:13] -new snapshot under testing, no new blockers reported so far [17:05:33] - Two old ones still open, fixes in latest qt5.git [17:06:13] - creator build ongoing. When succeed i'll start new installer builds [17:07:00] -> we should have beta candidate packages for testing during tomorrow [17:07:44] Then some testing & beta out if nothing serious found during testing [17:08:17] We are targeting to release beta next monday [17:08:25] Any comments or questions? [17:08:58] Commercial examples in? [17:09:35] fkleint: Unfortunately no :( But it has been agreed earlier that it won't block the beta [17:09:54] hm,ok [17:11:31] ok, that was all about 5.6 beta at the moment [17:11:41] then Qt 5.7 feature freeze: [17:12:46] we haven't released the beta for the feature-frozen Qt 5.6 [17:12:52] at the very least, that should happen first [17:13:00] so Qt 5.7 feature freeze needs to be pushed to next year [17:13:17] thiago: That was just what I meant to propose ;) [17:13:35] We need to get beta out first at least [17:13:53] I was planning to propose new ff date 15th Jan [17:14:19] I would prefer after the RC also, so we don't push multiple places at the same time [17:14:47] I would prefer that too, but I wasn't going to suggest being so radical [17:15:01] let's do this: it needs to be a ML discussion, with lars's ok [17:15:32] I'm ok with shortening a little, like between 5.6 beta anad RC [17:17:39] ok for me. Ideally it should be after RC but on the other hand I don't want to delay 5.7 final so much... let's agree that via ML, I can initiate discussion. Should I use release or dev ML? [17:21:00] dev [17:21:47] Ok, i'll start discussion there [17:23:37] thanks [17:25:03] I think it was all at this time. I think we can skip next week's meeting and then it is christmas week -> I propose to have next meeting 5.1.2016 at this same time. OK? [17:25:30] assuming beta is out, otherwise we might still need it [17:26:46] carewolf: Yeah, true. If beta isn't out let's have a meeting next week. But if it is then let's have next meeting 5.1.2016 [17:26:47] let me check if I can join at this time on 5.1 [17:27:09] where in the world will I be [17:27:47] thiago: ;) We can tune the time if needed [17:28:29] I'll be in Chicago from 6:20 to 9:20 CST [17:28:39] so the best time would be 8:00 am CST, which is... [17:29:08] 15:00 CET / 16:00 EET [17:29:10] one hour earlier [17:29:13] can we do that? [17:29:56] Ok for me [17:31:12] +1 [17:32:04] OK, great. Let's end this meeting now, put beta out & have new neeting 5.1.2016 15:00 CET [17:32:16] Thanks your participation! bye [17:33:33] bye -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimo.belgrano at gmail.com Wed Dec 23 12:44:15 2015 From: massimo.belgrano at gmail.com (massimo) Date: Wed, 23 Dec 2015 11:44:15 +0000 (UTC) Subject: [Releasing] MinGW version for qt 5.5 /5.6 Message-ID: I'd like to suggest updating the MinGW version for qt 5.5/5.6 SEH for 32bits http://mingw-w64.org/doku.php/contribute From mingw.android at gmail.com Wed Dec 23 12:54:02 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 23 Dec 2015 11:54:02 +0000 Subject: [Releasing] MinGW version for qt 5.5 /5.6 In-Reply-To: References: Message-ID: On Wed, Dec 23, 2015 at 11:44 AM, massimo wrote: > I'd like to suggest updating the MinGW version for qt 5.5/5.6 > > SEH for 32bits > http://mingw-w64.org/doku.php/contribute Unfortunately there are no such compilers. That is a suggested task to be completed by someone who wishes to spend time hacking on MinGW-w64. > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From eric.lemanissier at gmail.com Wed Dec 23 14:35:50 2015 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Wed, 23 Dec 2015 13:35:50 +0000 Subject: [Releasing] MinGW version for qt 5.5 /5.6 In-Reply-To: References: Message-ID: May I ask if updating MinGW to version to 5.x.y is planned ? 5.2.0 is available : http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.2.0/threads-posix/dwarf/ . It would allow full use of c++14, including extended constexpr for example. Thanks ! Le mer. 23 déc. 2015 à 12:54, Ray Donnelly a écrit : > On Wed, Dec 23, 2015 at 11:44 AM, massimo > wrote: > > I'd like to suggest updating the MinGW version for qt 5.5/5.6 > > > > SEH for 32bits > > http://mingw-w64.org/doku.php/contribute > > Unfortunately there are no such compilers. That is a suggested task to > be completed by someone who wishes to spend time hacking on MinGW-w64. > > > > > _______________________________________________ > > 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 jani.heikkinen at theqtcompany.com Wed Dec 30 11:12:45 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 30 Dec 2015 10:12:45 +0000 Subject: [Releasing] Qt 5.6.0 String freeze Message-ID: Hi all, As warned a week ago string freeze is now in effect. Please, no changes to translatable strings from now on, unless approved by the documentation team. Br, Jani From: Heikkinen Jani Sent: 21. joulukuuta 2015 9:56 To: localization at qt-project.org Cc: development at qt-project.org Subject: HEADS UP - Qt 5.6.0 String freeze coming Importance: High Hi, Beta is finally out & work for finalizing Qt 5.6 continues. One milestone for that is string freeze which will be 30.12.2015. So it is time to start keeping the translatable strings as it is and fix remaining important issues. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: