From jani.heikkinen at qt.io Mon Jun 6 16:53:57 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 6 Jun 2016 14:53:57 +0000 Subject: [Releasing] Qt 5.6.1 packages available Message-ID: Hi all We have Qt5.6.1 packages available: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.1/496/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.1/444/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.1/380/ Src: http://download.qt.io/snapshots/qt/5.6/5.6.1/latest_src/ Please test the packages to everything is still ok. We are planning to release Qt 5.6.1 during this week if nothing really serious found during testing. Also update known issues page (https://wiki.qt.io/Qt_5.6.1_Known_Issues) as well for the release. Qt Creator in the packages is a bit old one & will be updated before final release. br, Jani --- Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland Jani.heikkinen at qt.io +358 50 4873735 http://qt.io --- From jani.heikkinen at qt.io Tue Jun 14 16:29:15 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 14 Jun 2016 14:29:15 +0000 Subject: [Releasing] Meeting minutes from Qt Release Team meeting 14.6.2016 Message-ID: Meeting minutes from Qt Release Team meeting 14th June 2016 - Qt 5.7.0 'go' decision: GO! * Content in place, RTA OK, Manual testing ongoing. No new blockers found. - Qt 5.8 branching & FF * We propose to start branching 2nd August & have feature freeze 9th August 2016 * Jani will sent proposal to dev ML where official agreement will be done - Next meeting Tue 2nd August 2016 16:00 CET Have a nice summer for everyone! Br, Jani Irc log below: [17:00:20] akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping [17:00:52] jaheikki3: pong [17:02:28] jaheikki3: pong [17:03:01] time to start qt release team meeting [17:03:08] on agenda today: [17:03:22] qt 5.7.0 release 'go' decision [17:03:34] Qt 5.8.0 feature freeze schedule [17:03:43] Any additional item to the agenda? [17:05:17] Ok, let's start from Qt 5.7.0 release [17:05:37] Release content is in place & packages are under testing [17:05:54] no new blockers reported [17:06:24] According to RTA packages are good enough for the release [17:07:10] So it seems these packages can be released as Qt 5.7.0 [17:08:03] I propose to release these packages as Qt 5.7.0 this Thursday (We cannot release tomorrow because we need have time to update mirrors etc) [17:08:20] Any comments or questions? [17:08:43] no objections [17:09:19] +1 [17:09:36] Great! that's all about 5.7.0 [17:09:49] Then Qt 5.8 feature freeze: [17:10:19] needs to be discussed in the ML [17:10:31] we can make a proposal only [17:12:09] when is the release supposed to happen? [17:12:26] Ok, and I propose that we start branching at the beginning of August (2nd) and have FF 9th August. That way we will have enough time for release before Christmas [17:12:49] that is pretty much same what we had with 5.6 [17:13:13] And fits in our summer holidays [17:14:17] If we will postpone FF later then we cannot plan release before Christmas :( All old releases indicates that... [17:14:42] I think it's good [17:15:11] we'll be in-between alpha and beta during QtCon [17:15:27] Yeah [17:16:35] 5.8 schedule sounds ok [17:16:42] Great. I'll sent proposal in ML [17:18:19] Then next meeting. No need to have meeting next week and then I'll start my summer holidays. So let's have next meeting 2nd August. There we can check if we are ready to start branching & start preparing FF [17:18:27] OK? [17:18:42] +1 [17:20:12] Ok, let's end this meeting now. [17:20:17] Thanks for your participation! Have a nice summer, see you on August again! [17:20:23] Bye! [17:20:34] thanks, bye From jani.heikkinen at qt.io Thu Jun 16 12:38:02 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 16 Jun 2016 10:38:02 +0000 Subject: [Releasing] brown paper bag issue in Qt 5.6.1 packages Message-ID: Hi, Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is actually a brown paper bag issue for Qt 5.6.1 release. That's why we need to update release packages with change https://codereview.qt-project.org/#/c/162677/ . We will "release" new packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and tested the packages from new content. It is much easier and safer to select that option instead of releasing Qt 5.6.2 before summer vacations. br, Jani [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jun 22 01:42:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Jun 2016 16:42:14 -0700 Subject: [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: Message-ID: <2002755.ggY99F3WFB@tjmaciei-mobl1> On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote: > Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is > actually a brown paper bag issue for Qt 5.6.1 release. That's why we need > to update release packages with change > https://codereview.qt-project.org/#/c/162677/ . We will "release" new > packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and > tested the packages from new content. It is much easier and safer to select > that option instead of releasing Qt 5.6.2 before summer vacations. I've just noticed this email. QTBUG-53761 is not P0, so it did not warrant new packages. The naming for the new tag is totally unacceptable. It should have been v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then we release v5.6.2 immediately after. And if for some reason it was too difficult to bump everything that was scheduled for 5.6.2 to 5.6.3, then at the very least we should have used v5.6.1.1, which is probably what everyone making Qt packages will need to use since a dash is completely unacceptable in release versions. I propose that we delete the bad tag, retag and rerelease with a better name. Let's not make rash decisions again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Jun 22 07:03:28 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 22 Jun 2016 05:03:28 +0000 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <2002755.ggY99F3WFB@tjmaciei-mobl1> References: , <2002755.ggY99F3WFB@tjmaciei-mobl1> Message-ID: Hi! Actually https://bugreports.qt.io/browse/QTBUG-53761 is a blocker. Priority isn't correct at the moment but in reality the bug is preventing any bigger and a bit complex applications working correctly. Unfortunately bug isn't describing that well enough :( That's why we need to update the packages just with that one fix. And that's why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix. There was already request 'because you are doing new release please include this fixes' etc :) and that is unfortunately impossible now, just before summer holidays, sorry. And what comes to tag: we have used '-1' tag earlier (in enterprise repositories) and we didn't see any reason to change that 'hotfix' tagging scheme. It was discussed in irc as well but at least for me no-one really says why '-1' pattern is wrong. There was just opinions for and against and because we have used '-1' tag earlier it was selected this time as well. Another reason was the package naming: We have some tools which cannot handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to use same format in the tag what is used in package names. But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 would work then it is really ok for me to change the tag. But let's don't change that just because of opinions... br, Jani ________________________________ From: Development on behalf of Thiago Macieira Sent: Wednesday, June 22, 2016 2:42 AM To: releasing at qt-project.org Cc: development at qt-project.org Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote: > Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is > actually a brown paper bag issue for Qt 5.6.1 release. That's why we need > to update release packages with change > https://codereview.qt-project.org/#/c/162677/ . We will "release" new > packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and > tested the packages from new content. It is much easier and safer to select > that option instead of releasing Qt 5.6.2 before summer vacations. I've just noticed this email. QTBUG-53761 is not P0, so it did not warrant new packages. The naming for the new tag is totally unacceptable. It should have been v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then we release v5.6.2 immediately after. And if for some reason it was too difficult to bump everything that was scheduled for 5.6.2 to 5.6.3, then at the very least we should have used v5.6.1.1, which is probably what everyone making Qt packages will need to use since a dash is completely unacceptable in release versions. I propose that we delete the bad tag, retag and rerelease with a better name. Let's not make rash decisions again. -- 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 thiago.macieira at intel.com Wed Jun 22 07:50:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Jun 2016 22:50:18 -0700 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <2002755.ggY99F3WFB@tjmaciei-mobl1> Message-ID: <9706243.cgEQ5ABx34@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 05:03:28 PDT Jani Heikkinen wrote: > That's why we need to update the packages just with that one fix. And that's > why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix. That's still "the next release after 5.6.1 without new features", so it's 5.6.2. > And what comes to tag: we have used '-1' tag earlier (in enterprise > repositories) and we didn't see any reason to change that 'hotfix' tagging I don't care what you've done in enterprise repositories since they are not visible and the Qt community wasn't consulted. We also have a rule that only the Qt Project can create new version numbers, so enterprise releases need to have a field to annotate differentiations: that's the part after the dash. The binary packages also don't count. That's again exactly what the part after the dash is for: it notes what the different build (release) of that particular source code version is. But the source packages cannot have a dash. There's no discussion to be had here. See also what QVersionNumber does: QVersionNumber::fromString("5.6.1") < QVersionNumber::fromString("5.6.1-1') is false > scheme. It was discussed in irc as well but at least for me no-one really > says why '-1' pattern is wrong. There was just opinions for and against and > because we have used '-1' tag earlier it was selected this time as well. We have never used a dash in the version number itself. Separation for "rc" and "beta" has never been a problem, though I'm sure many of our downstream would have liked us to use version numbers like 5.7.90, 5.7.99, etc. in the source for those. > Another reason was the package naming: We have some tools which cannot > handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to > use same format in the tag what is used in package names. We have tools that can't handle 5.6.1-1, but can handle 5.6.1.1. More importantly, we have tools that can't handle either, like the configure script, which produces QT_VERSION. Conclusion: both 5.6.1.1 and 5.6.1-1 are bad ideas. Let's use the correct version number: 5.6.2. > But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 > would work then it is really ok for me to change the tag. But let's don't > change that just because of opinions... 5.6.1-1 does not work in Linux packages. The part after the dash is reserved for the distribution packages themselves, like the our binary packages as discussed above. For example, OpenSUSE Tumbleweed currently has Qt packages with version 5.6.0-1.1, the KDE::Qt56 repositories are providing 5.6.2-5.1, KDE:Qt57 has 5.7.0-35.1. That means release 1.1 of Qt's 5.6.0 source code. Traditionally, the release number resets to 1 when a source version number changes, but is rev'ved up whenever you make changes to the scripts that produce the packages. Like our binaries. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Jun 22 08:28:12 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 22 Jun 2016 06:28:12 +0000 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <9706243.cgEQ5ABx34@tjmaciei-mobl1> References: <2002755.ggY99F3WFB@tjmaciei-mobl1> , <9706243.cgEQ5ABx34@tjmaciei-mobl1> Message-ID: Hi, To be clear: There isn't version bump in qt, it is still 5.6.1. We just re-packed the release from '5.6.1' branch with that new change for fixing QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In tags & packages we used 5.6.1-1 to make difference with original and updated ones & to be able to identify if user has original or re-packed version in the use. Of course we could just move v5.6.1 tag in declarative and ignore v5.6.1-1 and that's it... But It has done this way now. Ok, if tag or something is really broken let's just correct that but otherwise just live with this now. And for the future lets just agree the way to work with this kind of 'brown paper bug issue'. In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker. br, Jani ________________________________ From: Releasing on behalf of Thiago Macieira Sent: Wednesday, June 22, 2016 8:50 AM To: releasing at qt-project.org Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages On quarta-feira, 22 de junho de 2016 05:03:28 PDT Jani Heikkinen wrote: > That's why we need to update the packages just with that one fix. And that's > why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix. That's still "the next release after 5.6.1 without new features", so it's 5.6.2. > And what comes to tag: we have used '-1' tag earlier (in enterprise > repositories) and we didn't see any reason to change that 'hotfix' tagging I don't care what you've done in enterprise repositories since they are not visible and the Qt community wasn't consulted. We also have a rule that only the Qt Project can create new version numbers, so enterprise releases need to have a field to annotate differentiations: that's the part after the dash. The binary packages also don't count. That's again exactly what the part after the dash is for: it notes what the different build (release) of that particular source code version is. But the source packages cannot have a dash. There's no discussion to be had here. See also what QVersionNumber does: QVersionNumber::fromString("5.6.1") < QVersionNumber::fromString("5.6.1-1') is false > scheme. It was discussed in irc as well but at least for me no-one really > says why '-1' pattern is wrong. There was just opinions for and against and > because we have used '-1' tag earlier it was selected this time as well. We have never used a dash in the version number itself. Separation for "rc" and "beta" has never been a problem, though I'm sure many of our downstream would have liked us to use version numbers like 5.7.90, 5.7.99, etc. in the source for those. > Another reason was the package naming: We have some tools which cannot > handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to > use same format in the tag what is used in package names. We have tools that can't handle 5.6.1-1, but can handle 5.6.1.1. More importantly, we have tools that can't handle either, like the configure script, which produces QT_VERSION. Conclusion: both 5.6.1.1 and 5.6.1-1 are bad ideas. Let's use the correct version number: 5.6.2. > But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 > would work then it is really ok for me to change the tag. But let's don't > change that just because of opinions... 5.6.1-1 does not work in Linux packages. The part after the dash is reserved for the distribution packages themselves, like the our binary packages as discussed above. For example, OpenSUSE Tumbleweed currently has Qt packages with version 5.6.0-1.1, the KDE::Qt56 repositories are providing 5.6.2-5.1, KDE:Qt57 has 5.7.0-35.1. That means release 1.1 of Qt's 5.6.0 source code. Traditionally, the release number resets to 1 when a source version number changes, but is rev'ved up whenever you make changes to the scripts that produce the packages. Like our binaries. -- 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 Releasing Info Page - Qt lists.qt-project.org To see the collection of prior postings to the list, visit the Releasing Archives. Using Releasing: To post a message to all the list members, send ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangelog at gmail.com Wed Jun 22 10:04:12 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 22 Jun 2016 10:04:12 +0200 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <9706243.cgEQ5ABx34@tjmaciei-mobl1> Message-ID: On Wed, Jun 22, 2016 at 8:28 AM, Jani Heikkinen wrote: > In my opinion bumping version numbers and doing totally new release > because of just one fix is too heavy. I think we should have a way to > produce this kind of update with 'simple hot fix ' easily and quickly > without re-doing whole release in case of this kind of blocker. This reopens a question which is still very obscure to the community (or at least to me), which is: what is the complexity of creating packages? Why is redoing packages with a different version number (say, by branching 5.6.1 into 5.6.2) "too heavy"? Could you please share some insights on what happens behind the scenes? Thank you, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Wed Jun 22 12:20:15 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 22 Jun 2016 10:20:15 +0000 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <9706243.cgEQ5ABx34@tjmaciei-mobl1> , Message-ID: Hi! Actually there is quite many things to do for the new release (agree the content, get the agreed content in etc.) but if we are assuming content is agreed to be one change + version bumps then the flow is pretty much as follows: 1. Create new branch for the release (not needed if updating existing release) 2. Do version bumps for submodules in that new branch + create a fix in that new branch (not needed if updating existing release) 3. Integrate fix + version bumps. When we are doing new release we need to bump version in each submodule as well. Knowing our CI stability it will take a while when all version bumps are in submodules. Without version bump we just need to integrate that one change in one submodule 4. Integrate submodule changes in qt5.git. If all modules are changed this step will most probably fail few times because of CI instability (flaky tests, network issues etc). With change in one submodule this is most probably much easier & will go through much quicker 5. Merge qt5.git in our super repository containing qt5.git + enterprise features. 6. Run packaging tools for src and binary packages (patch content, package content in suitable form for installers). 7. Update packaging configurations. If we are doing new release we need to create all new packaging configurations for that. When updating existing release we don't need to change configurations at all. We just need to update package version number for online repository configurations. 8. Update release test automation configurations and tests. (not needed if updating existing release) 9. Create packages for the release (Online repository and offline inataller packages, LGPL and commercial ones) 10. Test the release. If we update existing release with one change it is much easier to test. We need just test that the fix is in and fixes the issue + don't break anything else. And of course test that packaging went ok. So we can rely on RTA in this case pretty much but with totally new release we need significantly more manual test effort in addition and that takes time (testing + collecting results). 11. Publish the release. There is also more configuration changes in delivery tools if doing new release instead of updating old one. All these take considerable amount of time and Effort. Doing new release instead of updating old one is much harder and here is also more places where something might go wrong. That's why updating old release is much safer. br, jani ________________________________ From: Giuseppe D'Angelo Sent: Wednesday, June 22, 2016 11:04 AM To: Jani Heikkinen Cc: Thiago Macieira; releasing at qt-project.org Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages On Wed, Jun 22, 2016 at 8:28 AM, Jani Heikkinen > wrote: In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker. This reopens a question which is still very obscure to the community (or at least to me), which is: what is the complexity of creating packages? Why is redoing packages with a different version number (say, by branching 5.6.1 into 5.6.2) "too heavy"? Could you please share some insights on what happens behind the scenes? Thank you, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Wed Jun 22 13:21:37 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 22 Jun 2016 13:21:37 +0200 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To:

Message-ID: <20160622112137.GA21404@troll08.intra.qt.io> On Wed, Jun 22, 2016 at 06:48:39AM +0000, Lars Knoll wrote: > The only thing that changes when the Linux distributions do such an > update is the version number of the package, not of the .so’s inside. > > We basically do the same here. > but we can't, because we are upstream. if the qt company's release team does not act directly on behalf of the qt project, then this must be reflected in the version control system, as explicitly stated in the branch policy: the tag is v5.6.1-tqtc-1, and it is *not* forward-merged to 5.6. On Wed, Jun 22, 2016 at 06:54:54AM +0000, Tuukka Turunen wrote: > Users need it and it is ready, so we really need to release this now. > it's undoubtedly necessary, but the fact that it is ready does not authorize us as a company to violate the agreed upon rules. the rest of the mail dissects the technicalities. it's unnecessary to read it if you accept the conclusions reached so far. On Wed, Jun 22, 2016 at 06:28:12AM +0000, Jani Heikkinen wrote: > To be clear: There isn't version bump in qt, it is still 5.6.1. We > just re-packed the release from '5.6.1' branch with that new change > for fixing QTBUG-53761 included. > you're kinda trying to make the argument that the packages are a patched downstream version, but that seems quite unconvincing: we *are* upstream. this is reinforced by the fact that our installers are the primary advertized distribution medium. and it's sealed by you creating an upstream tag in the mainline repository. > In my opinion bumping version numbers and doing totally new release > because of just one fix is too heavy. I think we should have a way to > produce this kind of update with 'simple hot fix' easily and quickly > without re-doing whole release in case of this kind of blocker. > you're trying to both eat the cake and have it. it has different contents (which is reflected by a different tag), so it *is* a different version. it doesn't matter how small the difference is. On Wed, Jun 22, 2016 at 10:20:15AM +0000, Jani Heikkinen wrote: > Actually there is quite many things to do for the new release (agree > the content, get the agreed content in etc.) but if we are assuming > content is agreed to be one change + version bumps then the flow is > pretty much as follows: > > 1. Create new branch for the release (not needed if updating existing > release) > not necessary, as already pointed out. the existence of a release branch is a convenience, not a requirement. the name matching the released version is luxury (we could have release and release-lts branches just as well). > 2. Do version bumps for submodules in that new branch + create a fix > in that new branch (not needed if updating existing release) > while it would be somewhat weird, we could bump only qtdeclarative and qt5, keeping the version number of the other modules the same. but anyway, see next point. > 3. Integrate fix + version bumps. When we are doing new release we > need to bump version in each submodule as well. Knowing our CI > stability it will take a while when all version bumps are in > submodules. Without version bump we just need to integrate that one > change in one submodule > as you could have figured out by just looking at the commits, version bumps are direct-pushed by my script (except repos that happen to be busy for extended periods of time while i do the bumping, typically qtbase). so this is a non-argument. > 4. Integrate submodule changes in qt5.git. If all modules are changed > this step will most probably fail few times because of CI instability > (flaky tests, network issues etc). With change in one submodule this > is most probably much easier & will go through much quicker > i don't see how changing at most the version number in all other modules could delay the integration. > 5. Merge qt5.git in our super repository containing qt5.git + > enterprise features. > > 6. Run packaging tools for src and binary packages (patch content, > package content in suitable form for installers). > > 7. Update packaging configurations. If we are doing new release we > need to create all new packaging configurations for that. > i'll buy that, but this indicates just how broken the system is. cloning a branch config should be a matter of a single near-trivial commit. the previous two points also just show how bad our system is. luckily, this is finally being worked on. > 8. Update release test automation configurations and tests. (not > needed if updating existing release) > > 9. Create packages for the release (Online repository and offline > inataller packages, LGPL and commercial ones) > same again. broken infrastructure. > 10. Test the release. If we update existing release with one change it > is much easier to test. > see point 4. From tuukka.turunen at qt.io Wed Jun 22 13:33:38 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 22 Jun 2016 11:33:38 +0000 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <9706243.cgEQ5ABx34@tjmaciei-mobl1>

Message-ID: Hi, The more there are changes, the more we need to test and the higher the probability of some other things going wrong. If there is only one (or few enough) change to an existing version, we can release binaries in a couple of days e.g. to address a vulnerability or like this case a bad bug. Yours, Tuukka From: Releasing [mailto:releasing-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Giuseppe D'Angelo Sent: keskiviikkona 22. kesäkuuta 2016 11.04 To: Jani Heikkinen Cc: Thiago Macieira ; releasing at qt-project.org Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages On Wed, Jun 22, 2016 at 8:28 AM, Jani Heikkinen > wrote: In my opinion bumping version numbers and doing totally new release because of just one fix is too heavy. I think we should have a way to produce this kind of update with 'simple hot fix ' easily and quickly without re-doing whole release in case of this kind of blocker. This reopens a question which is still very obscure to the community (or at least to me), which is: what is the complexity of creating packages? Why is redoing packages with a different version number (say, by branching 5.6.1 into 5.6.2) "too heavy"? Could you please share some insights on what happens behind the scenes? Thank you, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jun 22 18:26:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Jun 2016 09:26:52 -0700 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <9706243.cgEQ5ABx34@tjmaciei-mobl1> Message-ID: <10385985.jJRtJ70bmi@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 06:28:12 PDT Jani Heikkinen wrote: > Hi, > > > To be clear: There isn't version bump in qt, it is still 5.6.1. Are the source packages the same? No? Then it's a new version. > We just > re-packed the release from '5.6.1' branch with that new change for fixing > QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In > tags & packages we used 5.6.1-1 to make difference with original and > updated ones & to be able to identify if user has original or re-packed > version in the use. Of course we could just move v5.6.1 tag in declarative > and ignore v5.6.1-1 and that's it... We could do that, yes: * no new qtdeclarative source package * cherry-pick the patch to the tree used for the binaries, release * update the binary relase version I just think it's a bad idea and would cause confusion too. But I'm asking that we Do The Right Thing, instead of trying to find the solution with the least amount of effort. We own up to our mistakes and then we fix the correctly. > But It has done this way now. Ok, if tag or something is really broken let's > just correct that but otherwise just live with this now. And for the future > lets just agree the way to work with this kind of 'brown paper bug issue'. Let's agree on no more "brown paper bag fixes". Let's not rush into more mistakes. This only happened because we tried to find the solution with the least amount of effort instead of doing the proper, established way of creating new releases. > In my opinion bumping version numbers and doing totally new release because > of just one fix is too heavy. I think we should have a way to produce this > kind of update with 'simple hot fix ' easily and quickly without re-doing > whole release in case of this kind of blocker. If we have a light-weight procedure, great, let's use it. But we don't. And creating one the moment we need a quick fix is a bad idea, because we're going down untested paths and creating more problems in the process, as the current case has shown. I think we should have a light-weight procedure. Let's investigate it when we have the time to do it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jun 22 18:30:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Jun 2016 09:30:09 -0700 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References:

Message-ID: <6490239.1STGg5yWeR@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 11:33:38 PDT Tuukka Turunen wrote: > The more there are changes, the more we need to test and the higher the > probability of some other things going wrong. If there is only one (or few > enough) change to an existing version, we can release binaries in a couple > of days e.g. to address a vulnerability or like this case a bad bug. No is disputing that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jun 22 18:31:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Jun 2016 09:31:13 -0700 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <9706243.cgEQ5ABx34@tjmaciei-mobl1> Message-ID: <7696335.zP9oOx0sL1@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 06:28:12 PDT Jani Heikkinen wrote: > Hi, > > > To be clear: There isn't version bump in qt, it is still 5.6.1. Are the source packages the same? No? Then it's a new version. > We just > re-packed the release from '5.6.1' branch with that new change for fixing > QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In > tags & packages we used 5.6.1-1 to make difference with original and > updated ones & to be able to identify if user has original or re-packed > version in the use. Of course we could just move v5.6.1 tag in declarative > and ignore v5.6.1-1 and that's it... We could do that, yes: * no new qtdeclarative source package * cherry-pick the patch to the tree used for the binaries, release * update the binary relase version I just think it's a bad idea and would cause confusion too. But I'm asking that we Do The Right Thing, instead of trying to find the solution with the least amount of effort. We own up to our mistakes and then we fix the correctly. > But It has done this way now. Ok, if tag or something is really broken let's > just correct that but otherwise just live with this now. And for the future > lets just agree the way to work with this kind of 'brown paper bug issue'. Let's agree on no more "brown paper bag fixes". Let's not rush into more mistakes. This only happened because we tried to find the solution with the least amount of effort instead of doing the proper, established way of creating new releases. > In my opinion bumping version numbers and doing totally new release because > of just one fix is too heavy. I think we should have a way to produce this > kind of update with 'simple hot fix ' easily and quickly without re-doing > whole release in case of this kind of blocker. If we have a light-weight procedure, great, let's use it. But we don't. And creating one the moment we need a quick fix is a bad idea, because we're going down untested paths and creating more problems in the process, as the current case has shown. I think we should have a light-weight procedure. Let's investigate it when we have the time to do it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dangelog at gmail.com Wed Jun 22 22:52:39 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 22 Jun 2016 22:52:39 +0200 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <9706243.cgEQ5ABx34@tjmaciei-mobl1>

Message-ID: Hi, On Wed, Jun 22, 2016 at 12:20 PM, Jani Heikkinen wrote: > Actually there is quite many things to do for the new release (agree the > content, get the agreed content in etc.) but if we are assuming content is > agreed to be one change + version bumps then the flow is pretty much as > follows: thank you for the extensive description. Some follow up questions: how much of this is automated today? From just this high level description, it looks like that most steps can be scripted. Also, what are the real bottlenecks? Getting the content to integrate cleanly? Testing the packages on all the platforms? Cheers, -- Giuseppe D'Angelo From thiago.macieira at intel.com Thu Jun 23 01:07:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Jun 2016 16:07:34 -0700 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References:

Message-ID: <4655333.M8MngVeAJb@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote: > 10. Test the release. If we update existing release with one change it is > much easier to test. We need just test that the fix is in and fixes the > issue + don't break anything else. And of course test that packaging went > ok. So we can rely on RTA in this case pretty much but with totally new > release we need significantly more manual test effort in addition and that > takes time (testing + collecting results). What (or who) is RTA? Rapid Testing Automation? Release Testing Automation? Release Testing Authority? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sahumada at texla.cl Thu Jun 23 07:21:45 2016 From: sahumada at texla.cl (Sergio Ahumada) Date: Thu, 23 Jun 2016 07:21:45 +0200 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <4655333.M8MngVeAJb@tjmaciei-mobl1> References:

<4655333.M8MngVeAJb@tjmaciei-mobl1> Message-ID: <576B71E9.8090903@texla.cl> On 23.06.2016 01:07, Thiago Macieira wrote: > On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote: >> 10. Test the release. If we update existing release with one change it is >> much easier to test. We need just test that the fix is in and fixes the >> issue + don't break anything else. And of course test that packaging went >> ok. So we can rely on RTA in this case pretty much but with totally new >> release we need significantly more manual test effort in addition and that >> takes time (testing + collecting results). > > What (or who) is RTA? > > Rapid Testing Automation? > > Release Testing Automation? > > Release Testing Authority? > http://lists.qt-project.org/pipermail/releasing/2013-November/001502.html -- Sergio Ahumada sahumada at texla.cl From tuukka.turunen at qt.io Thu Jun 23 11:37:50 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 23 Jun 2016 09:37:50 +0000 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <576B71E9.8090903@texla.cl> References:

<4655333.M8MngVeAJb@tjmaciei-mobl1> <576B71E9.8090903@texla.cl> Message-ID: > -----Original Message----- > From: Releasing [mailto:releasing-bounces+tuukka.turunen=qt.io at qt- > project.org] On Behalf Of Sergio Ahumada > Sent: torstaina 23. kesäkuuta 2016 8.22 > To: releasing at qt-project.org > Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 > packages > > On 23.06.2016 01:07, Thiago Macieira wrote: > > On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote: > >> 10. Test the release. If we update existing release with one change > >> it is much easier to test. We need just test that the fix is in and > >> fixes the issue + don't break anything else. And of course test that > >> packaging went ok. So we can rely on RTA in this case pretty much but > >> with totally new release we need significantly more manual test > >> effort in addition and that takes time (testing + collecting results). > > > > What (or who) is RTA? > > > > Rapid Testing Automation? > > > > Release Testing Automation? > > > > Release Testing Authority? > > > > http://lists.qt-project.org/pipermail/releasing/2013-November/001502.html > Release Test Automation (RTA) is a system that automatically installs binary packages and runs a series of tests in multiple platforms using Froglogic Squish and various Qt applications. It is currently a separate system, commanded by Jenkins. The system can run a quick smoke test set before manual testing of a snapshot starts, and it can also run a more complete set, which is especially beneficial for patch releases. It of course does not have to be separate, it could be part of the same CI system as other tests are. But for the while being it is not connected to the CI. People operating the RTA are working in the release & qa team, it is not a separate organization. Yours, Tuukka > -- > Sergio Ahumada > sahumada at texla.cl > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From johanna.aijala at qt.io Thu Jun 23 11:57:08 2016 From: johanna.aijala at qt.io (=?iso-8859-1?Q?Johanna_=C4ij=E4l=E4?=) Date: Thu, 23 Jun 2016 09:57:08 +0000 Subject: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References:

<4655333.M8MngVeAJb@tjmaciei-mobl1> <576B71E9.8090903@texla.cl> Message-ID: Hi Thiago & all, In addition what Tuukka wrote about RTA, currently I'm mainly responsible of the RTA tests for offline and online installers. The goal of the RTA is to minimize the need of manual testing, but everything can't be tested automatically, manual tests are always needed. RTA tests installer functionality and the packages that are installed, it does not test the content in git repositories. There are two level of tests, RTA smoke and RTA full tests. - Smoke test set takes couple of hours to run and analyze. RTA smoke is done before manual test requests are send out, it does a sanity check for the installer by verifying that installer installs correct content with default settings and builds all examples to verify that the content works, also light QtCreator testing is included. - Full test round takes about 48 hours. It is done parallel with manual testing. Tests include installing with different options, license checking, source package tests (content and licenses check and building Qt with different configure options) and some iOS and Android deployment tests. Test execution times depends on the number of available machines, RTA uses same build machines as coin. Br, Johanna -----Original Message----- From: Releasing [mailto:releasing-bounces+johanna.aijala=qt.io at qt-project.org] On Behalf Of Tuukka Turunen Sent: 23. kesäkuuta 2016 12:38 To: Sergio Ahumada; releasing at qt-project.org Subject: Re: [Releasing] [Development] brown paper bag issue in Qt 5.6.1 packages > -----Original Message----- > From: Releasing [mailto:releasing-bounces+tuukka.turunen=qt.io at qt- > project.org] On Behalf Of Sergio Ahumada > Sent: torstaina 23. kesäkuuta 2016 8.22 > To: releasing at qt-project.org > Subject: Re: [Releasing] [Development] brown paper bag issue in Qt > 5.6.1 packages > > On 23.06.2016 01:07, Thiago Macieira wrote: > > On quarta-feira, 22 de junho de 2016 10:20:15 PDT Jani Heikkinen wrote: > >> 10. Test the release. If we update existing release with one change > >> it is much easier to test. We need just test that the fix is in and > >> fixes the issue + don't break anything else. And of course test > >> that packaging went ok. So we can rely on RTA in this case pretty > >> much but with totally new release we need significantly more manual > >> test effort in addition and that takes time (testing + collecting results). > > > > What (or who) is RTA? > > > > Rapid Testing Automation? > > > > Release Testing Automation? > > > > Release Testing Authority? > > > > http://lists.qt-project.org/pipermail/releasing/2013-November/001502.h > tml > Release Test Automation (RTA) is a system that automatically installs binary packages and runs a series of tests in multiple platforms using Froglogic Squish and various Qt applications. It is currently a separate system, commanded by Jenkins. The system can run a quick smoke test set before manual testing of a snapshot starts, and it can also run a more complete set, which is especially beneficial for patch releases. It of course does not have to be separate, it could be part of the same CI system as other tests are. But for the while being it is not connected to the CI. People operating the RTA are working in the release & qa team, it is not a separate organization. Yours, Tuukka > -- > Sergio Ahumada > sahumada at texla.cl > > _______________________________________________ > 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