From jani.heikkinen at qt.io  Wed Dec 14 06:19:08 2016
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 14 Dec 2016 05:19:08 +0000
Subject: [Releasing] Meeting minutes from Qt Release Team meeting 13.12.2016
Message-ID: <AM5PR0202MB25157A170635CE9C4ED7563A9D9A0@AM5PR0202MB2515.eurprd02.prod.outlook.com>

Meeting minutes from Qt Release Team meeting 13th December 2016

Qt 5.7.1 status:
- Final packages available and tested. All seems to be ok for the release
- Target to release existing packages as Qt 5.7.1 Wed 14th Dec 2016

Qt 5.8.0 status:
- New rc snapshot under testing
   * Enterprise packages smoke tested & manual testing ongoing
   * LGPL packages under smoke testing, Manual testing will be started after smoke ready (&OK)
- Most of blocker issues from https://bugreports.qt.io/issues/?filter=18053 should have a fix in existing packages
- Most probably we need to update packages before official rc release
   * Few additional fixes + change files already merged in '5.8.0'
- Current target for Qt 5.8.0 rc is 20th December

Next meeting Tue 3rd January 2017 16:00 CET (if we get rc out as planned)

br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:20] <jaheikki3> akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping 
[17:00:30] <fkleint> jaheikki3: pong
[17:00:48] <akseli> jaheikki3: pong
[17:02:39] <jaheikki3> Time to start qt release team meeting
[17:02:47] <jaheikki3> on agenda today:
[17:02:54] <jaheikki3> Qt 5.7.1 status
[17:03:02] <jaheikki3> qt 5.8.0 rc status
[17:03:12] <jaheikki3> Any additional item to the agenda?
[17:05:13] <jaheikki3> Let's start from qt 5.7.1 status:
[17:05:23] <jaheikki3> - Final packages available and tested
[17:05:31] <jaheikki3> All seems to be ok for the release
[17:05:50] <jaheikki3> target to release existing packages as qt 5.7.1 tomorrow
[17:06:00] <jaheikki3> Any comments/questions?
[17:07:20] <fregl> good news :)
[17:07:57] <jaheikki3> Then Qt 5.8.0 rc status:
[17:08:08] <jaheikki3> New rc snapshot available
[17:08:31] <jaheikki3> enterprise packages smoke tested & seems to be OK. Manual testing started
[17:08:59] <jaheikki3> LGPL packages under smoke testing. Manual testing will be started when smoke results available (and all OK)
[17:10:21] <jaheikki3> Most of blocker issues from https://bugreports.qt.io/issues/?filter=18053 should have a fix in existing packages
[17:10:55] <jaheikki3> But there is already few additional fixes + change files in
[17:11:21] <jaheikki3> --> Most probably we need to update packages before official rc release
[17:11:55] <jaheikki3> Current target for qt 5.8.0 rc is 20th December
[17:12:22] <w00t> this may be a stupid question, but aren't the LGPL and commercial content the same now? why do they need seperate testing steps?
[17:13:23] <jaheikki3> w00t: not exactly, there is still some difference & that's why we have still separate LGPL and enterprise packages
[17:13:41] <jaheikki3> But the difference isn't that big anymore
[17:14:13] <w00t> ok :)
[17:14:22] <jaheikki3> Any other comments or questions?
[17:17:14] <jaheikki3> Ok, this was all at this time. If we managed to get RC out next tue as planned let's skip remaining meetings from this year & have next one Tue 3rd January 2017, OK?
[17:17:41] <akseli> +1
[17:18:23] <jaheikki3> great. Let's end this meeting now. Thanks for your participation, bye!
[17:18:37] <akseli> bye
[17:19:07] <fkleint> bye




From giuseppe.dangelo at kdab.com  Wed Dec 14 10:52:12 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Wed, 14 Dec 2016 09:52:12 +0000
Subject: [Releasing] Meeting minutes from Qt Release Team meeting
 13.12.2016
In-Reply-To: <AM5PR0202MB25157A170635CE9C4ED7563A9D9A0@AM5PR0202MB2515.eurprd02.prod.outlook.com>
References: <AM5PR0202MB25157A170635CE9C4ED7563A9D9A0@AM5PR0202MB2515.eurprd02.prod.outlook.com>
Message-ID: <c8e5da8b-7c2f-9bd2-964c-7fff9bbed3ee@kdab.com>

On 14/12/16 05:19, Jani Heikkinen wrote:
> - Current target for Qt 5.8.0 rc is 20th December

IMHO this is a rather poor choice. No one is going to seriously test the
RC over the holidays, leading to an untested final release.

My 2 cents,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20161214/ee067ebd/attachment.bin>

From jani.heikkinen at qt.io  Wed Dec 14 11:56:27 2016
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 14 Dec 2016 10:56:27 +0000
Subject: [Releasing] new Qt 5.8.0 rc snapshot available
Message-ID: <AM5PR0202MB25154AEC1CD0D38A206201379D9A0@AM5PR0202MB2515.eurprd02.prod.outlook.com>

Hi all,

We have new snapshot for testing

Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/596/
Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/664/
Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/689/
src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/

Packages are based on https://codereview.qt-project.org/#/c/179514/ . Packages are RTA smoke tested and everything seems to be mostly OK so please test the packages to see if we are ready for RC or not. Please make sure all open blockers are visible in https://bugreports.qt.io/issues/?filter=18053.

We are trying to get rc out still before Christmas so please fix all found blockers immediately! And remember, no any nice-to-have's in '5.8.0' anymore!

br,
Jani Heikkinen
Release Manager





From jani.heikkinen at qt.io  Tue Dec 20 10:36:43 2016
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Tue, 20 Dec 2016 09:36:43 +0000
Subject: [Releasing] Meeting minutes from Qt Release Team meeting
 13.12.2016
In-Reply-To: <AM5PR0202MB25157A170635CE9C4ED7563A9D9A0@AM5PR0202MB2515.eurprd02.prod.outlook.com>
References: <AM5PR0202MB25157A170635CE9C4ED7563A9D9A0@AM5PR0202MB2515.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0202MB2521E22ECDD649AC917FE3409D900@HE1PR0202MB2521.eurprd02.prod.outlook.com>

No release team meeting today even RC isn't out yet. Let's have new meeting Tue 3th January, hoping RC is out before it

br,
Jani

________________________________________
From: Jani Heikkinen
Sent: Wednesday, December 14, 2016 7:19 AM
To: releasing at qt-project.org
Subject: Meeting minutes from Qt Release Team meeting 13.12.2016

Meeting minutes from Qt Release Team meeting 13th December 2016

Qt 5.7.1 status:
- Final packages available and tested. All seems to be ok for the release
- Target to release existing packages as Qt 5.7.1 Wed 14th Dec 2016

Qt 5.8.0 status:
- New rc snapshot under testing
   * Enterprise packages smoke tested & manual testing ongoing
   * LGPL packages under smoke testing, Manual testing will be started after smoke ready (&OK)
- Most of blocker issues from https://bugreports.qt.io/issues/?filter=18053 should have a fix in existing packages
- Most probably we need to update packages before official rc release
   * Few additional fixes + change files already merged in '5.8.0'
- Current target for Qt 5.8.0 rc is 20th December

Next meeting Tue 3rd January 2017 16:00 CET (if we get rc out as planned)

br,
Jani Heikkinen
Release Manager

irc log below:
[17:00:20] <jaheikki3> akseli: iieklund: thiago: fkleint: ZapB: tronical: vladimirM: aholza: peter-h: mapaaso: ankokko: fkleint: carewolf: fregl: ablasche: ping
[17:00:30] <fkleint> jaheikki3: pong
[17:00:48] <akseli> jaheikki3: pong
[17:02:39] <jaheikki3> Time to start qt release team meeting
[17:02:47] <jaheikki3> on agenda today:
[17:02:54] <jaheikki3> Qt 5.7.1 status
[17:03:02] <jaheikki3> qt 5.8.0 rc status
[17:03:12] <jaheikki3> Any additional item to the agenda?
[17:05:13] <jaheikki3> Let's start from qt 5.7.1 status:
[17:05:23] <jaheikki3> - Final packages available and tested
[17:05:31] <jaheikki3> All seems to be ok for the release
[17:05:50] <jaheikki3> target to release existing packages as qt 5.7.1 tomorrow
[17:06:00] <jaheikki3> Any comments/questions?
[17:07:20] <fregl> good news :)
[17:07:57] <jaheikki3> Then Qt 5.8.0 rc status:
[17:08:08] <jaheikki3> New rc snapshot available
[17:08:31] <jaheikki3> enterprise packages smoke tested & seems to be OK. Manual testing started
[17:08:59] <jaheikki3> LGPL packages under smoke testing. Manual testing will be started when smoke results available (and all OK)
[17:10:21] <jaheikki3> Most of blocker issues from https://bugreports.qt.io/issues/?filter=18053 should have a fix in existing packages
[17:10:55] <jaheikki3> But there is already few additional fixes + change files in
[17:11:21] <jaheikki3> --> Most probably we need to update packages before official rc release
[17:11:55] <jaheikki3> Current target for qt 5.8.0 rc is 20th December
[17:12:22] <w00t> this may be a stupid question, but aren't the LGPL and commercial content the same now? why do they need seperate testing steps?
[17:13:23] <jaheikki3> w00t: not exactly, there is still some difference & that's why we have still separate LGPL and enterprise packages
[17:13:41] <jaheikki3> But the difference isn't that big anymore
[17:14:13] <w00t> ok :)
[17:14:22] <jaheikki3> Any other comments or questions?
[17:17:14] <jaheikki3> Ok, this was all at this time. If we managed to get RC out next tue as planned let's skip remaining meetings from this year & have next one Tue 3rd January 2017, OK?
[17:17:41] <akseli> +1
[17:18:23] <jaheikki3> great. Let's end this meeting now. Thanks for your participation, bye!
[17:18:37] <akseli> bye
[17:19:07] <fkleint> bye




From tuukka.turunen at qt.io  Tue Dec 20 14:34:39 2016
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Tue, 20 Dec 2016 13:34:39 +0000
Subject: [Releasing] Proposal to adjust release candidate process
Message-ID: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>


Hi,

I think we have three major problems with our current release process regarding the release candidate phase:

1.       Process to make a RC that is as flawless as final causes inefficiency as we only get full test coverage with the RC itself

2.       We get full attention for testing a bit too late, many fixes are still coming in close to the planned RC time causing instability

3.       Current time between RC and final is planned to be 2 weeks, which is very little in order to take in the feedback and fix things

Therefore, I would like to propose the following:

a.       Consider "Release Candidate" to be a phase rather than an individual delivery

b.       Create the first "RC1" almost immediately after release branch (e.g. 5.9.0) is operational

c.       Criteria for the "RC1" is that no known P0 bugs exist (i.e. there can be other issues that would not be acceptable in a final release)

d.       During the "RC" phase P1 (and possible P0 of course) bugs and documentation are fixed

e.       Public "RC" release is similar development release as Alpha and Beta in that it starts a phase of work

f.        Multiple snapshots / new candidates are created during the "RC" phase until one of them is considered the final release

If desired, we could use some other name than "Release Candidate 1" for the release that begins the last phase of the release. It could be called "Beta 2" or "Technology preview", if so desired. Personally, I would call it "Release Candidate 1".

The difference to our current process is quite small. In essence it would be about considering the "RC1" the beginning of the final releasing phase (.0 branch), not something we do almost at the end of it. I believe that lowering the quality criterial for "RC1" helps us in being more efficient as it has been in practice impossible to really fulfill the current process goal and have already the first RC as good as the final.

In case of Qt 5.9 it would mean that we have the first "RC" out around end of April, soon after the branching to 5.9.0 has been completed. We then have 4 or so weeks to make all the needed amount of candidates / snapshots until one of them will be released as Qt 5.9.0 final. If it happens earlier than in 4 weeks, great. If it takes more time, then so be it (although in such case we have probably missed something in the earlier steps of the release creation).

Yours,

---
Tuukka Turunen
Director, R&D

The Qt Company
Lutakonaukio 1
40100 Jyväskylä, Finland
tuukka.turunen at qt.io
+358 40 7655 800
http://qt.io
---

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20161220/bfdaf186/attachment.html>

From Shawn.Rutledge at qt.io  Tue Dec 20 16:10:48 2016
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Tue, 20 Dec 2016 15:10:48 +0000
Subject: [Releasing] [Development] Proposal to adjust release candidate
 process
In-Reply-To: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
Message-ID: <262D86AE-CB73-436F-A3FE-C4D420AC8EEC@qt.io>


> On 20 Dec 2016, at 14:34, Tuukka Turunen <tuukka.turunen at qt.io> wrote:
> 
>  
> Hi,
>  
> I think we have three major problems with our current release process regarding the release candidate phase:
> 1.       Process to make a RC that is as flawless as final causes inefficiency as we only get full test coverage with the RC itself
> 2.       We get full attention for testing a bit too late, many fixes are still coming in close to the planned RC time causing instability
> 3.       Current time between RC and final is planned to be 2 weeks, which is very little in order to take in the feedback and fix things
>  
> Therefore, I would like to propose the following:
> a.       Consider “Release Candidate” to be a phase rather than an individual delivery
> b.       Create the first “RC1” almost immediately after release branch (e.g. 5.9.0) is operational
> c.       Criteria for the “RC1” is that no known P0 bugs exist (i.e. there can be other issues that would not be acceptable in a final release)
> d.       During the “RC” phase P1 (and possible P0 of course) bugs and documentation are fixed
> e.       Public “RC” release is similar development release as Alpha and Beta in that it starts a phase of work
> f.        Multiple snapshots / new candidates are created during the “RC” phase until one of them is considered the final release
>  
> If desired, we could use some other name than “Release Candidate 1” for the release that begins the last phase of the release. It could be called “Beta 2” or “Technology preview”, if so desired. Personally, I would call it “Release Candidate 1”.
>  
> The difference to our current process is quite small. In essence it would be about considering the “RC1” the beginning of the final releasing phase (.0 branch), not something we do almost at the end of it. I believe that lowering the quality criterial for “RC1” helps us in being more efficient as it has been in practice impossible to really fulfill the current process goal and have already the first RC as good as the final.
>  
> In case of Qt 5.9 it would mean that we have the first “RC” out around end of April, soon after the branching to 5.9.0 has been completed. We then have 4 or so weeks to make all the needed amount of candidates / snapshots until one of them will be released as Qt 5.9.0 final. If it happens earlier than in 4 weeks, great. If it takes more time, then so be it (although in such case we have probably missed something in the earlier steps of the release creation).

+1, sounds good to me.

From sean.harmer at kdab.com  Tue Dec 20 16:14:17 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 20 Dec 2016 15:14:17 +0000
Subject: [Releasing] [Development] Proposal to adjust release candidate
 process
In-Reply-To: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
Message-ID: <2254680.W3ZZFgYWVg@cartman>

Hi Tuukka,

I agree with your proposal, however I think there is also another issue or two 
that we should address.

At present we have ~ 4 releases per year 2 minor versions and 2 further patch 
releases. One issue is that it looks like 5.8.0 will soon render the very new 
5.7.1 release redundant. With that in mind was it worth splitting the effort 
and having the 5.7.1 release at all? Don't get me wrong I'm all for additional 
patch releases just that I'd hope they wouldn't coincide so closely with a 
minor version release.

This brings me onto another issue which perhaps we feel more strongly than 
average in Qt 3D as a new module that is undergoing rapid bug-fixing, 
improvements and with lots of new feature development starting to open up. For 
example, although Qt 3D in Qt 5.7.0 was a nice release after lots of effort, 
we still fixed a huge number of issues for 5.7.1, which took 181 days to 
release from 5.7.0.

Would it be possible for us to release more frequent patch releases? If not 
for the whole of Qt, then at least for addon modules such as Qt 3D? The latter 
would require splitting the packaging of such modules but would reduce the 
amount of overall testing required for a new patch release. If we'd 
collectively rather not go down that street I still think more frequent patch 
releases would be nice. Users have the option of upgrading or not if they want 
to reduce their own internal regression testing burden and freeze on a specific 
version. But it would have the benefit that other users don't need to wait 6 
months for a set of bug fixes - roughly the same time to wait as for new 
features.

I wonder how much of the current pressure on releases is driven by the time-
based release policy. We aim for a new minor release every 6 months which is 
admirable. But I wonder about the consequences of trying to stick to that at 
the expense of quality of the 5.x.0 releases, especially given the long turn 
around for subsequent patch releases.

With the above in mind, how about this proposal in addition to yours regarding 
the RC phase?

* Branch off new feature branch every 6 months as at present.

* Do not rush the release at the expense of quality or when it's convenient 
due to packagers going on vacation etc. We release only when the release is 
deemed to meet quality standards.

* Aim for a patch release every alternate month if there are fixes on the minor 
version branch and packaging/release staff are available. i.e. don't try to 
force one out before the summer/Xmas vacations.

* Consider releasing at least one patch release of the previous minor series 
after the release of the next minor series' .0 release. For example, in the 
current situation, potentially release a 5.7.2 after 5.8.0. (We already have 
fixes on 5.8.0 and 5.8 that could have been submitted to the 5.7 branch if 
there were to be a 5.7.2 release).

Additionally, is there any way that contributors outside of The Qt Company can 
assist with the practicalities of packaging?

Just some food for thought.

Cheers,

Sean

On Tuesday 20 December 2016 13:34:39 Tuukka Turunen wrote:
> Hi,
> 
> I think we have three major problems with our current release process
> regarding the release candidate phase:
> 
> 1.       Process to make a RC that is as flawless as final causes
> inefficiency as we only get full test coverage with the RC itself
> 
> 2.       We get full attention for testing a bit too late, many fixes are
> still coming in close to the planned RC time causing instability
> 
> 3.       Current time between RC and final is planned to be 2 weeks, which
> is very little in order to take in the feedback and fix things
> 
> Therefore, I would like to propose the following:
> 
> a.       Consider "Release Candidate" to be a phase rather than an
> individual delivery
> 
> b.       Create the first "RC1" almost immediately after release branch
> (e.g. 5.9.0) is operational
> 
> c.       Criteria for the "RC1" is that no known P0 bugs exist (i.e. there
> can be other issues that would not be acceptable in a final release)
> 
> d.       During the "RC" phase P1 (and possible P0 of course) bugs and
> documentation are fixed
> 
> e.       Public "RC" release is similar development release as Alpha and
> Beta in that it starts a phase of work
> 
> f.        Multiple snapshots / new candidates are created during the "RC"
> phase until one of them is considered the final release
> 
> If desired, we could use some other name than "Release Candidate 1" for the
> release that begins the last phase of the release. It could be called "Beta
> 2" or "Technology preview", if so desired. Personally, I would call it
> "Release Candidate 1".
> 
> The difference to our current process is quite small. In essence it would be
> about considering the "RC1" the beginning of the final releasing phase (.0
> branch), not something we do almost at the end of it. I believe that
> lowering the quality criterial for "RC1" helps us in being more efficient
> as it has been in practice impossible to really fulfill the current process
> goal and have already the first RC as good as the final.
> 
> In case of Qt 5.9 it would mean that we have the first "RC" out around end
> of April, soon after the branching to 5.9.0 has been completed. We then
> have 4 or so weeks to make all the needed amount of candidates / snapshots
> until one of them will be released as Qt 5.9.0 final. If it happens earlier
> than in 4 weeks, great. If it takes more time, then so be it (although in
> such case we have probably missed something in the earlier steps of the
> release creation).
> 
> Yours,
> 
> ---
> Tuukka Turunen
> Director, R&D
> 
> The Qt Company
> Lutakonaukio 1
> 40100 Jyväskylä, Finland
> tuukka.turunen at qt.io
> +358 40 7655 800
> http://qt.io
> ---

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From sean.harmer at kdab.com  Tue Dec 20 16:31:44 2016
From: sean.harmer at kdab.com (Sean Harmer)
Date: Tue, 20 Dec 2016 15:31:44 +0000
Subject: [Releasing] [Development] Proposal to adjust release candidate
 process
In-Reply-To: <2254680.W3ZZFgYWVg@cartman>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<2254680.W3ZZFgYWVg@cartman>
Message-ID: <2607031.P9e58b0odW@cartman>

On Tuesday 20 December 2016 15:14:17 Sean Harmer wrote:
> Hi Tuukka,
> 
> I agree with your proposal, however I think there is also another issue or
> two that we should address.

Except that instead of calling it RC1 why not call it another beta? The RC 
should be something that *may* be suitable for release. But at present we get 
the RC too late so it gets difficult to get fixes for issues accepted. Sure we 
might need a new RC after that but calling the initial packages after the 
release branch is branched an RC seems like a misnomer.

Cheers,

Sean

> 
> At present we have ~ 4 releases per year 2 minor versions and 2 further
> patch releases. One issue is that it looks like 5.8.0 will soon render the
> very new 5.7.1 release redundant. With that in mind was it worth splitting
> the effort and having the 5.7.1 release at all? Don't get me wrong I'm all
> for additional patch releases just that I'd hope they wouldn't coincide so
> closely with a minor version release.
> 
> This brings me onto another issue which perhaps we feel more strongly than
> average in Qt 3D as a new module that is undergoing rapid bug-fixing,
> improvements and with lots of new feature development starting to open up.
> For example, although Qt 3D in Qt 5.7.0 was a nice release after lots of
> effort, we still fixed a huge number of issues for 5.7.1, which took 181
> days to release from 5.7.0.
> 
> Would it be possible for us to release more frequent patch releases? If not
> for the whole of Qt, then at least for addon modules such as Qt 3D? The
> latter would require splitting the packaging of such modules but would
> reduce the amount of overall testing required for a new patch release. If
> we'd collectively rather not go down that street I still think more
> frequent patch releases would be nice. Users have the option of upgrading
> or not if they want to reduce their own internal regression testing burden
> and freeze on a specific version. But it would have the benefit that other
> users don't need to wait 6 months for a set of bug fixes - roughly the same
> time to wait as for new features.
> 
> I wonder how much of the current pressure on releases is driven by the time-
> based release policy. We aim for a new minor release every 6 months which
> is admirable. But I wonder about the consequences of trying to stick to
> that at the expense of quality of the 5.x.0 releases, especially given the
> long turn around for subsequent patch releases.
> 
> With the above in mind, how about this proposal in addition to yours
> regarding the RC phase?
> 
> * Branch off new feature branch every 6 months as at present.
> 
> * Do not rush the release at the expense of quality or when it's convenient
> due to packagers going on vacation etc. We release only when the release is
> deemed to meet quality standards.
> 
> * Aim for a patch release every alternate month if there are fixes on the
> minor version branch and packaging/release staff are available. i.e. don't
> try to force one out before the summer/Xmas vacations.
> 
> * Consider releasing at least one patch release of the previous minor series
> after the release of the next minor series' .0 release. For example, in the
> current situation, potentially release a 5.7.2 after 5.8.0. (We already
> have fixes on 5.8.0 and 5.8 that could have been submitted to the 5.7
> branch if there were to be a 5.7.2 release).
> 
> Additionally, is there any way that contributors outside of The Qt Company
> can assist with the practicalities of packaging?
> 
> Just some food for thought.
> 
> Cheers,
> 
> Sean
> 
> On Tuesday 20 December 2016 13:34:39 Tuukka Turunen wrote:
> > Hi,
> > 
> > I think we have three major problems with our current release process
> > regarding the release candidate phase:
> > 
> > 1.       Process to make a RC that is as flawless as final causes
> > inefficiency as we only get full test coverage with the RC itself
> > 
> > 2.       We get full attention for testing a bit too late, many fixes are
> > still coming in close to the planned RC time causing instability
> > 
> > 3.       Current time between RC and final is planned to be 2 weeks, which
> > is very little in order to take in the feedback and fix things
> > 
> > Therefore, I would like to propose the following:
> > 
> > a.       Consider "Release Candidate" to be a phase rather than an
> > individual delivery
> > 
> > b.       Create the first "RC1" almost immediately after release branch
> > (e.g. 5.9.0) is operational
> > 
> > c.       Criteria for the "RC1" is that no known P0 bugs exist (i.e. there
> > can be other issues that would not be acceptable in a final release)
> > 
> > d.       During the "RC" phase P1 (and possible P0 of course) bugs and
> > documentation are fixed
> > 
> > e.       Public "RC" release is similar development release as Alpha and
> > Beta in that it starts a phase of work
> > 
> > f.        Multiple snapshots / new candidates are created during the "RC"
> > phase until one of them is considered the final release
> > 
> > If desired, we could use some other name than "Release Candidate 1" for
> > the
> > release that begins the last phase of the release. It could be called
> > "Beta
> > 2" or "Technology preview", if so desired. Personally, I would call it
> > "Release Candidate 1".
> > 
> > The difference to our current process is quite small. In essence it would
> > be about considering the "RC1" the beginning of the final releasing phase
> > (.0 branch), not something we do almost at the end of it. I believe that
> > lowering the quality criterial for "RC1" helps us in being more efficient
> > as it has been in practice impossible to really fulfill the current
> > process goal and have already the first RC as good as the final.
> > 
> > In case of Qt 5.9 it would mean that we have the first "RC" out around end
> > of April, soon after the branching to 5.9.0 has been completed. We then
> > have 4 or so weeks to make all the needed amount of candidates / snapshots
> > until one of them will be released as Qt 5.9.0 final. If it happens
> > earlier
> > than in 4 weeks, great. If it takes more time, then so be it (although in
> > such case we have probably missed something in the earlier steps of the
> > release creation).
> > 
> > Yours,
> > 
> > ---
> > Tuukka Turunen
> > Director, R&D
> > 
> > The Qt Company
> > Lutakonaukio 1
> > 40100 Jyväskylä, Finland
> > tuukka.turunen at qt.io
> > +358 40 7655 800
> > http://qt.io
> > ---

-- 
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
KDAB (UK) Ltd, a KDAB Group company
Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090
Mobile: +44 (0)7545 140604
KDAB - Qt Experts


From giuseppe.dangelo at kdab.com  Wed Dec 21 01:25:11 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Wed, 21 Dec 2016 01:25:11 +0100
Subject: [Releasing] Proposal to adjust release candidate process
In-Reply-To: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
Message-ID: <05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>

Hello,

first and foremost, thanks for raising these issues.


Il 20/12/2016 14:34, Tuukka Turunen ha scritto:

> I think we have three major problems with our current release process
> regarding the release candidate phase:
> 
> 1.       Process to make a RC that is as flawless as final causes
> inefficiency as we only get full test coverage with the RC itself

Well, "Release Candidate" by definition means "(hopefully) suitable
*as-is* for final release"; as such, we must enter that phase only when
we have already reached a state as flawless as possible. It's sad that
we get "test coverage" with the RC. Do you mind to elaborate more,
however? What does "test coverage" mean here?

> 2.       We get full attention for testing a bit too late, many fixes
> are still coming in close to the planned RC time causing instability
>
> 3.       Current time between RC and final is planned to be 2 weeks,
> which is very little in order to take in the feedback and fix things

IMHO this time should be enough, if

1) it doesn't happen over holidays (I sent an email a few days ago about
this very issue. Proper testing can't happen across holidays. As such we
should refrain from releasing just before them, and/or not consider them
as part of the timeout period)

2) Release candidate really means "candidate suitable for final
release". As such we would've failed the release process if we put a RC
out with blatant bugs. Two weeks should be enough to confirm that indeed
there are no such bugs.



What I really feel here is that these are symptoms of a more serious
issue, which is our commitment to time-based releases.

Instead of entering the RC phase when the product is ready for it, we
forcibly push for it because of the approaching deadlines.

This results in lack of proper testing before the RC (since there's no
real stabilization phase). Also, because in the RC phase only critical
bugfixes are accepted, we end up releasing a product with known serious
bugs (causing .0 releases to be frowned upon because full of bugs).

(Side note: we haven't managed to make a release happen on time since
5.2; actually, we've got pretty significant delays:

* Qt 5.2.0: +2 days
* Qt 5.3.0: +21 days
* Qt 5.4.0: +48 days
* Qt 5.5.0: +64 days
* Qt 5.6.0: +99 days
* Qt 5.7.0: +49 days
* Qt 5.8.0: +22 days and counting (won't be less than 50 considering the
RC is not out yet, plus the 2 weeks of holidays))

I would therefore ask to _stop_ the timed-based release process for new
minor releases, and keep it only for patch releases. For those, I would
actually like it to be at a stable and high frequency (say, every 2
months for the stable branches, and 3-4 for the 5.6 branch).


> Therefore, I would like to propose the following:
> 
> a.       Consider “Release Candidate” to be a phase rather than an
> individual delivery
> 
> b.       Create the first “RC1” almost immediately after release branch
> (e.g. 5.9.0) is operational
> 
> c.       Criteria for the “RC1” is that no known P0 bugs exist (i.e.
> there can be other issues that would not be acceptable in a final release)
> 
> d.       During the “RC” phase P1 (and possible P0 of course) bugs and
> documentation are fixed
> 
> e.       Public “RC” release is similar development release as Alpha and
> Beta in that it starts a phase of work
> 
> f.        Multiple snapshots / new candidates are created during the
> “RC” phase until one of them is considered the final release

Honestly I'm not too convinced of this plan; how do you decide when to
branch 5.9.0 out of 5.9? "No known P0" isn't an acceptable bar -- that's
actually true most of the time. When does the stabilization actually
happen in the above plan?

> 
> If desired, we could use some other name than “Release Candidate 1” for
> the release that begins the last phase of the release. It could be
> called “Beta 2” or “Technology preview”, if so desired. Personally, I
> would call it “Release Candidate 1”.

Yes, please, the correct name for all of this is "Beta", not "Release
Candidate". And during the beta we should accept fixes for P2/P3 bugs
too, if they affect the product quality in a significant way.

(We should also put betas and RC outs for patch releases; hopefully, the
stabilization period for those should be considerably shorter given
they're already supposed to be branched out of a "stable" tree.)


> The difference to our current process is quite small. In essence it
> would be about considering the “RC1” the beginning of the final
> releasing phase (.0 branch), not something we do almost at the end of
> it. I believe that lowering the quality criterial for “RC1” helps us in
> being more efficient as it has been in practice impossible to really
> fulfill the current process goal and have already the first RC as good
> as the final.

As I said before, I think this is a symptom, not the cause. Lowering the
quality criteria for release phase just doesn't seem right to me. Let's
try to get more betas out, and more frequently, instead.


> In case of Qt 5.9 it would mean that we have the first “RC” out around
> end of April, soon after the branching to 5.9.0 has been completed. We
> then have 4 or so weeks to make all the needed amount of candidates /
> snapshots until one of them will be released as Qt 5.9.0 final. If it
> happens earlier than in 4 weeks, great. If it takes more time, then so
> be it (although in such case we have probably missed something in the
> earlier steps of the release creation).

We've missed to evaluate whether we were ready to branch off 5.9.0 out
of the 5.9 branch and enter the release process. I think that's the part
where we shouldn't rush things out by having fixed deadlines, but allow
stabilization and bugfixing to happen by releasing several betas before
getting into the RC phase.


Cheers,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20161221/404d2864/attachment.bin>

From jani.heikkinen at qt.io  Wed Dec 21 06:28:03 2016
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 21 Dec 2016 05:28:03 +0000
Subject: [Releasing] Qt 5.9 prebuild binary packages( was: Re: [Development]
 Qt 5.9)
In-Reply-To: <5895604.KNhrVNCRLl@tjmaciei-mobl1>
References: <HE1PR0202MB252171FA6D321F159234CE199DA70@HE1PR0202MB2521.eurprd02.prod.outlook.com>
	<AM4PR0201MB21640C27134EAF8C752822EEE78C0@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io>,
	<5895604.KNhrVNCRLl@tjmaciei-mobl1>
Message-ID: <AM5PR0202MB2515E0149AB83B7102AA2AD79D930@AM5PR0202MB2515.eurprd02.prod.outlook.com>

Hi all,

I finally managed to do testing how big combined windows installer would be. I was a bit surprised that it is only ~3.3 GB, which is still smaller than combined mac-android-ios installer ;) Ok, this is done from 5.8 packages & binaries so situation might be a bit different in 5.9 where we will have some new binaries to be done. But in the other hand we will/should drop some so I think the size of combined one should be still manageable.

So I propose we will offer following set of offline installers from Qt 5.9 ->

- For linux we will have 3 installers (instead of existing 5):
   * qt-enterprise-linux-x64-android  (already delivering this)
   * qt-opensource-linux-x64-android (already delivering this)
      ** Desktop gcc 64-bit
      ** Android x86
      ** Android armv7
   * qt-enterprise-linux-x64-qnx (already delivering this)
      ** Desktop gcc 64-bit
      ** Qnx x86
      ** Qnx armv7
      ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0

- For mac we will have 2 installers (instead of existing 6):
   * qt-enterprise-mac-x64-android-ios (already delivering this)
   * qt-opensource-mac-x64-android-ios (already delivering this)
      ** Desktop clang 64-bit
      ** Android x86
      ** Android armv7
      ** iOS

- For windows we will have 3 installers (instead of existing 17):
   * qt-enterprise-windows-x86 (new)
   * qt-opensource-windows-x86 (new)
      ** Desktop MSVC 2013 x64
      ** Desktop MSVC 2015 x86
      ** Desktop MSVC 2015 x64
      ** Desktop MSVC 2017 x64
      ** Desktop MinGW 5.3 x86
      ** UWP MSVC 2015 x86
      ** UWP MSVC 2015 x64
      ** UWP MSVC 2015 armv7
      ** UWP MSVC 2017 x86
      ** UWP MSVC 2017 x64
      ** UWP MSVC 2017 armv7
      ** Android x86
      ** Android armv7
  * qt-enterprise-linux-x64-qnx (already delivering this)
      ** Desktop MinGW 5.3 x86
      ** Qnx x86
      ** Qnx armv7
      ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0
br,
Jani

________________________________________
From: Development <development-bounces+jani.heikkinen=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
Sent: Wednesday, November 30, 2016 5:05 PM
To: development at qt-project.org
Subject: Re: [Development] Qt 5.9

On quarta-feira, 30 de novembro de 2016 07:53:40 PST Jake Petroules wrote:
> How about we have one package per host platform which includes all possible
> hosts and targets compatible with it? Then we have 3 packages, ever.

Or, at least, one binary per platform + compiler combination. So that's 1
Linux package, 1 macOS package, 3 Windows packages today, with a 4th Windows
(MSVC 2017) coming for 5.9.

--
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 Maurice.Kalinowski at qt.io  Wed Dec 21 08:34:16 2016
From: Maurice.Kalinowski at qt.io (Maurice Kalinowski)
Date: Wed, 21 Dec 2016 07:34:16 +0000
Subject: [Releasing] Proposal to adjust release candidate process
In-Reply-To: <05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>
Message-ID: <HE1PR0201MB2218C2509389D0875450495995930@HE1PR0201MB2218.eurprd02.prod.outlook.com>

> >
> > 1.       Process to make a RC that is as flawless as final causes
> > inefficiency as we only get full test coverage with the RC itself
> 
> Well, "Release Candidate" by definition means "(hopefully) suitable
> *as-is* for final release"; as such, we must enter that phase only when we
> have already reached a state as flawless as possible. It's sad that we get "test
> coverage" with the RC. Do you mind to elaborate more, however? What
> does "test coverage" mean here?

 [Kalinowski Maurice] 
Test coverage implies active user manual testing outside the Qt Company. Whenever new packages are ready, R&D is asked to test all available packages. Those are actually more packages than the ones we send out to everyone asking to test.

However, the feedback we get from the community on package testing before the RC is almost zero, but then raises significantly when a package is claimed to be a Release Candidate and sometimes a Release Candidate Candidate. But as mentioned before, for many reported items, this is too late in the process.

[...]
> 
> 
> What I really feel here is that these are symptoms of a more serious issue,
> which is our commitment to time-based releases.
> 
> Instead of entering the RC phase when the product is ready for it, we forcibly
> push for it because of the approaching deadlines.
> 
> This results in lack of proper testing before the RC (since there's no real
> stabilization phase). Also, because in the RC phase only critical bugfixes are
> accepted, we end up releasing a product with known serious bugs (causing .0
> releases to be frowned upon because full of bugs).

 [Kalinowski Maurice] 
I would object to that. The reason we are having so many delays for minor releases is that we are not taking the feature freeze seriously, push a huge amount of stuff still into it (with at least questionable significance) and pray that it'll work. As you mention, it never does, but neither does everyone accept the fact that each and every individual contributing raises the chance of causing regressions and further bugs at that stage.

The idea of having patch level releases more frequent is certainly welcomed, but then again the problems are the same, way too many changes for those causing a lot of effort for testing and verification.


While I can understand the background for this proposal, I still do not like the idea to call it Release Candidate, because right from the description it is not and hence distinguishes from any other software product doing releases including release candidates.

Maurice

From tuukka.turunen at qt.io  Wed Dec 21 08:58:32 2016
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Wed, 21 Dec 2016 07:58:32 +0000
Subject: [Releasing] Proposal to adjust release candidate process
In-Reply-To: <HE1PR0201MB2218C2509389D0875450495995930@HE1PR0201MB2218.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>
	<HE1PR0201MB2218C2509389D0875450495995930@HE1PR0201MB2218.eurprd02.prod.outlook.com>
Message-ID: <AM4PR0202MB2948A5EA76957013C0B9F1998F930@AM4PR0202MB2948.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Releasing [mailto:releasing-bounces+tuukka.turunen=qt.io at qt-
> project.org] On Behalf Of Maurice Kalinowski
> Sent: keskiviikkona 21. joulukuuta 2016 9.34
> To: Giuseppe D'Angelo <giuseppe.dangelo at kdab.com>; releasing at qt-
> project.org
> Subject: Re: [Releasing] Proposal to adjust release candidate process
> 
> > >
> > > 1.       Process to make a RC that is as flawless as final causes
> > > inefficiency as we only get full test coverage with the RC itself
> >
> > Well, "Release Candidate" by definition means "(hopefully) suitable
> > *as-is* for final release"; as such, we must enter that phase only
> > when we have already reached a state as flawless as possible. It's sad
> > that we get "test coverage" with the RC. Do you mind to elaborate
> > more, however? What does "test coverage" mean here?
> 
>  [Kalinowski Maurice]
> Test coverage implies active user manual testing outside the Qt Company.
> Whenever new packages are ready, R&D is asked to test all available
> packages. Those are actually more packages than the ones we send out to
> everyone asking to test.
> 
> However, the feedback we get from the community on package testing
> before the RC is almost zero, but then raises significantly when a package is
> claimed to be a Release Candidate and sometimes a Release Candidate
> Candidate. But as mentioned before, for many reported items, this is too late
> in the process.
> 

Exactly. The main point in my proposal is to get focus from users to the "RC1" (or whatever we decide to call it). We are in practice already doing most of this, only issue is that in my opinion we wait too long before making the first release out of the .0 release branch. Then we aim to do the final in 2 weeks after, which means it is difficult to get enough feedback in time.  

> [...]
> >
> >
> > What I really feel here is that these are symptoms of a more serious
> > issue, which is our commitment to time-based releases.
> >
> > Instead of entering the RC phase when the product is ready for it, we
> > forcibly push for it because of the approaching deadlines.
> >
> > This results in lack of proper testing before the RC (since there's no
> > real stabilization phase). Also, because in the RC phase only critical
> > bugfixes are accepted, we end up releasing a product with known
> > serious bugs (causing .0 releases to be frowned upon because full of bugs).
> 
>  [Kalinowski Maurice]
> I would object to that. The reason we are having so many delays for minor
> releases is that we are not taking the feature freeze seriously, push a huge
> amount of stuff still into it (with at least questionable significance) and pray
> that it'll work. As you mention, it never does, but neither does everyone
> accept the fact that each and every individual contributing raises the chance
> of causing regressions and further bugs at that stage.
> 
> The idea of having patch level releases more frequent is certainly welcomed,
> but then again the problems are the same, way too many changes for those
> causing a lot of effort for testing and verification.
> 

Qt 5.7.1 took way too long to get out, no arguments there. We should make the first patch release soon after the .0 release because there always are already many changes waiting in the stable branch at the time of making the .0 release. 

In my (probably biased :) opinion our current quality level of the .0 releases has been quite good recently. I do not expect my proposal to make RC1 earlier to make it worse - on the contrary I expect to get feedback earlier thus resulting in a better .0 release.

> 
> While I can understand the background for this proposal, I still do not like the
> idea to call it Release Candidate, because right from the description it is not
> and hence distinguishes from any other software product doing releases
> including release candidates.
> 

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).  

Yours,

	Tuukka

> Maurice
> _______________________________________________
> Releasing mailing list
> Releasing at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing


From tuukka.turunen at qt.io  Wed Dec 21 09:17:58 2016
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Wed, 21 Dec 2016 08:17:58 +0000
Subject: [Releasing] [Development] Proposal to adjust release candidate
 process
In-Reply-To: <2254680.W3ZZFgYWVg@cartman>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<2254680.W3ZZFgYWVg@cartman>
Message-ID: <AM4PR0202MB2948C24CBD89306EA059F6A28F930@AM4PR0202MB2948.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: sean.harmer On Behalf Of Sean Harmer
> Sent: tiistaina 20. joulukuuta 2016 17.14
> To: development at qt-project.org
> Cc: Tuukka Turunen <tuukka.turunen at qt.io>; releasing at qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> Hi Tuukka,
> 
> I agree with your proposal, however I think there is also another issue or two
> that we should address.
> 
> At present we have ~ 4 releases per year 2 minor versions and 2 further
> patch releases. One issue is that it looks like 5.8.0 will soon render the very
> new
> 5.7.1 release redundant. With that in mind was it worth splitting the effort
> and having the 5.7.1 release at all? Don't get me wrong I'm all for additional
> patch releases just that I'd hope they wouldn't coincide so closely with a
> minor version release.
> 

Did we need Qt 5.7.1 in my opinion, yes we did. Was it too late, yes it was. We can not change the past, but for Qt 5.8, I would like to branch 5.8.1 quite soon after the 5.8.0 is released. This way there will be more time between 5.8.1 and 5.9.0 releases. There are already quite many changes in 5.8 branch that are not in 5.8.0 branch.

> This brings me onto another issue which perhaps we feel more strongly than
> average in Qt 3D as a new module that is undergoing rapid bug-fixing,
> improvements and with lots of new feature development starting to open
> up. For example, although Qt 3D in Qt 5.7.0 was a nice release after lots of
> effort, we still fixed a huge number of issues for 5.7.1, which took 181 days to
> release from 5.7.0.
> 
> Would it be possible for us to release more frequent patch releases? If not
> for the whole of Qt, then at least for addon modules such as Qt 3D? 

I would like to have more patch level releases. Perhaps not between the feature releases, but to continue patch releases of Qt 5.x also after 5.x+1 is released. Currently this has not been feasible, but it is something I am interested in for 5.9 (after we have completed the big CI HW and virtualization infrastructure change and relocated the machine room).

>The
> latter would require splitting the packaging of such modules but would
> reduce the amount of overall testing required for a new patch release. If
> we'd collectively rather not go down that street I still think more frequent
> patch releases would be nice. Users have the option of upgrading or not if
> they want to reduce their own internal regression testing burden and freeze
> on a specific version. But it would have the benefit that other users don't
> need to wait 6 months for a set of bug fixes - roughly the same time to wait
> as for new features.
> 
> I wonder how much of the current pressure on releases is driven by the
> time- based release policy. We aim for a new minor release every 6 months
> which is admirable. But I wonder about the consequences of trying to stick to
> that at the expense of quality of the 5.x.0 releases, especially given the long
> turn around for subsequent patch releases.
> 

I think the two biggest reasons to the pressure are: 1. We end of having too big amount of changes in a patch release and 2. Test automation does not yet catch enough issues on embedded and mobile, and we need to use slow manual testing a lot.

Number #1 is something we can fix by our processes and behavior. It is also a "self filling prophecy" as we try to push a lot of things in to current release because it may take long time before next patch release is coming - thus making it more difficult to make patch releases. 

Number #2 is a continuous effort by our release and QA team and we are already quite good on desktop for automated package testing.

> With the above in mind, how about this proposal in addition to yours
> regarding the RC phase?
> 
> * Branch off new feature branch every 6 months as at present.
> 
> * Do not rush the release at the expense of quality or when it's convenient
> due to packagers going on vacation etc. We release only when the release is
> deemed to meet quality standards.
> 

We already try not to rush on expense of quality. I do think the current ~17 weeks is too long time. It may be so long already that some lose focus. I would like to get it shorter, 10 or 12 weeks would be good in my opinion. The first step to reach this is to keep the feature freeze (no exceptions to complete some feature weeks after the FF).

> * Aim for a patch release every alternate month if there are fixes on the
> minor version branch and packaging/release staff are available. i.e. don't try
> to force one out before the summer/Xmas vacations.
> 
> * Consider releasing at least one patch release of the previous minor series
> after the release of the next minor series' .0 release. For example, in the
> current situation, potentially release a 5.7.2 after 5.8.0. (We already have
> fixes on 5.8.0 and 5.8 that could have been submitted to the 5.7 branch if
> there were to be a 5.7.2 release).
> 

I think this would be very good for our users and something I would like to reach for 5.9 some way (see above for the reason why not yet)

> Additionally, is there any way that contributors outside of The Qt Company
> can assist with the practicalities of packaging?
> 

Most important thing from wider community is testing, reporting and fixing the found issues. From maintainers getting the changes files in early and being active to freeze the modules early etc is extremely valuable. The sooner we identify and fix issues, the better it is. 

Yours,

	Tuukka

> Just some food for thought.
> 
> Cheers,
> 
> Sean
> 
> On Tuesday 20 December 2016 13:34:39 Tuukka Turunen wrote:
> > Hi,
> >
> > I think we have three major problems with our current release process
> > regarding the release candidate phase:
> >
> > 1.       Process to make a RC that is as flawless as final causes
> > inefficiency as we only get full test coverage with the RC itself
> >
> > 2.       We get full attention for testing a bit too late, many fixes are
> > still coming in close to the planned RC time causing instability
> >
> > 3.       Current time between RC and final is planned to be 2 weeks, which
> > is very little in order to take in the feedback and fix things
> >
> > Therefore, I would like to propose the following:
> >
> > a.       Consider "Release Candidate" to be a phase rather than an
> > individual delivery
> >
> > b.       Create the first "RC1" almost immediately after release branch
> > (e.g. 5.9.0) is operational
> >
> > c.       Criteria for the "RC1" is that no known P0 bugs exist (i.e. there
> > can be other issues that would not be acceptable in a final release)
> >
> > d.       During the "RC" phase P1 (and possible P0 of course) bugs and
> > documentation are fixed
> >
> > e.       Public "RC" release is similar development release as Alpha and
> > Beta in that it starts a phase of work
> >
> > f.        Multiple snapshots / new candidates are created during the "RC"
> > phase until one of them is considered the final release
> >
> > If desired, we could use some other name than "Release Candidate 1"
> > for the release that begins the last phase of the release. It could be
> > called "Beta 2" or "Technology preview", if so desired. Personally, I
> > would call it "Release Candidate 1".
> >
> > The difference to our current process is quite small. In essence it
> > would be about considering the "RC1" the beginning of the final
> > releasing phase (.0 branch), not something we do almost at the end of
> > it. I believe that lowering the quality criterial for "RC1" helps us
> > in being more efficient as it has been in practice impossible to
> > really fulfill the current process goal and have already the first RC as good as
> the final.
> >
> > In case of Qt 5.9 it would mean that we have the first "RC" out around
> > end of April, soon after the branching to 5.9.0 has been completed. We
> > then have 4 or so weeks to make all the needed amount of candidates /
> > snapshots until one of them will be released as Qt 5.9.0 final. If it
> > happens earlier than in 4 weeks, great. If it takes more time, then so
> > be it (although in such case we have probably missed something in the
> > earlier steps of the release creation).
> >
> > Yours,
> >
> > ---
> > Tuukka Turunen
> > Director, R&D
> >
> > The Qt Company
> > Lutakonaukio 1
> > 40100 Jyväskylä, Finland
> > tuukka.turunen at qt.io
> > +358 40 7655 800
> > http://qt.io
> > ---
> 
> --
> Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB
> (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-
> 563-540090
> Mobile: +44 (0)7545 140604
> KDAB - Qt Experts


From jani.heikkinen at qt.io  Wed Dec 21 09:19:16 2016
From: jani.heikkinen at qt.io (Jani Heikkinen)
Date: Wed, 21 Dec 2016 08:19:16 +0000
Subject: [Releasing] Proposal to adjust release candidate process
In-Reply-To: <HE1PR0201MB2218C2509389D0875450495995930@HE1PR0201MB2218.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>
	<HE1PR0201MB2218C2509389D0875450495995930@HE1PR0201MB2218.eurprd02.prod.outlook.com>
Message-ID: <AM5PR0202MB2515A4CA7F9558CBFAA09F919D930@AM5PR0202MB2515.eurprd02.prod.outlook.com>

> > What I really feel here is that these are symptoms of a more serious
> > issue, which is our commitment to time-based releases.
> >
> > Instead of entering the RC phase when the product is ready for it, we
> > forcibly push for it because of the approaching deadlines.
> >
> > This results in lack of proper testing before the RC (since there's no
> > real stabilization phase). Also, because in the RC phase only critical
> > bugfixes are accepted, we end up releasing a product with known
> > serious bugs (causing .0 releases to be frowned upon because full of bugs).
> 
>  [Kalinowski Maurice]
> I would object to that. The reason we are having so many delays for minor
> releases is that we are not taking the feature freeze seriously, push a huge
> amount of stuff still into it (with at least questionable significance) and pray
> that it'll work. As you mention, it never does, but neither does everyone
> accept the fact that each and every individual contributing raises the chance
> of causing regressions and further bugs at that stage.
> 
> The idea of having patch level releases more frequent is certainly welcomed,
> but then again the problems are the same, way too many changes for those
> causing a lot of effort for testing and verification.
> 
I totally agree with you. To be able to keep the schedules & quality we really need to start respect the feature freeze and decrease the amount of changes after it. By doing that we should eventually be able to dramatically shorten the release schedule as well (but of course first step is to be able to keep existing ones ;) )

So even someone wrote that we should be able to take more p2/p3 fixes in I think just opposite: We should minimize error fixes as well after FF and put focus to identify & fix real release blockers as early as possible and same time make sure we don't cause any new regression by fixing those nice-to-have's (even some of those might have really important in one's point of view but nice-to-have from release point of view). Those nice-to-haves can be fixed in dev...

> 
> While I can understand the background for this proposal, I still do not like the
> idea to call it Release Candidate, because right from the description it is not
> and hence distinguishes from any other software product doing releases
> including release candidates.
> 
> Maurice

I agree. IMHO RC means there isn't any known blockers left  and we will most probably release rc packages as final. And  I agree we could start officially releasing more betas (or one beta as now + few tech preview releases between beta and RC). But still we need to make sure we are fixing only blockers & so on limit the changes between different (sub) releases. 

br,
Jani


From giuseppe.dangelo at kdab.com  Wed Dec 21 10:23:52 2016
From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo)
Date: Wed, 21 Dec 2016 10:23:52 +0100
Subject: [Releasing] Proposal to adjust release candidate process
In-Reply-To: <HE1PR0201MB2218C2509389D0875450495995930@HE1PR0201MB2218.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>
	<HE1PR0201MB2218C2509389D0875450495995930@HE1PR0201MB2218.eurprd02.prod.outlook.com>
Message-ID: <c2ee1fcd-4f8b-bb62-6e56-a75843de420a@kdab.com>

Il 21/12/2016 08:34, Maurice Kalinowski ha scritto:
>>>
>>> 1.       Process to make a RC that is as flawless as final causes
>>> inefficiency as we only get full test coverage with the RC itself
>>
>> Well, "Release Candidate" by definition means "(hopefully) suitable
>> *as-is* for final release"; as such, we must enter that phase only when we
>> have already reached a state as flawless as possible. It's sad that we get "test
>> coverage" with the RC. Do you mind to elaborate more, however? What
>> does "test coverage" mean here?
> 
>  [Kalinowski Maurice] 
> Test coverage implies active user manual testing outside the Qt Company. Whenever new packages are ready, R&D is asked to test all available packages. Those are actually more packages than the ones we send out to everyone asking to test.
> 
> However, the feedback we get from the community on package testing before the RC is almost zero, but then raises significantly when a package is claimed to be a Release Candidate and sometimes a Release Candidate Candidate. But as mentioned before, for many reported items, this is too late in the process.

Then, please, let's try to change _this_; I just don't think that
calling something a "release candidate" (when we know it isn't) with the
sole purpose of gathering more feedback is a good idea. As you say,
"release candidate" is an established name in the industry and we
shouldn't go against it.

> 
> [...]
>>
>>
>> What I really feel here is that these are symptoms of a more serious issue,
>> which is our commitment to time-based releases.
>>
>> Instead of entering the RC phase when the product is ready for it, we forcibly
>> push for it because of the approaching deadlines.
>>
>> This results in lack of proper testing before the RC (since there's no real
>> stabilization phase). Also, because in the RC phase only critical bugfixes are
>> accepted, we end up releasing a product with known serious bugs (causing .0
>> releases to be frowned upon because full of bugs).
> 
>  [Kalinowski Maurice] 
> I would object to that. The reason we are having so many delays for minor releases is that we are not taking the feature freeze seriously, push a huge amount of stuff still into it (with at least questionable significance) and pray that it'll work. As you mention, it never does, but neither does everyone accept the fact that each and every individual contributing raises the chance of causing regressions and further bugs at that stage.
> 
> The idea of having patch level releases more frequent is certainly welcomed, but then again the problems are the same, way too many changes for those causing a lot of effort for testing and verification.

Well, then again we have a problem elsewhere in our process: we're not
being strict enough on the kind of changes landing in stable branches.
Which is a fair critique, and one that should actually make us rivisit
our branching model or our approval/maintainership model if we think
we're failing it.

My 2 cents,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4007 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20161221/abad8025/attachment.bin>

From thiago.macieira at intel.com  Wed Dec 21 15:52:39 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Wed, 21 Dec 2016 12:52:39 -0200
Subject: [Releasing] Proposal to adjust release candidate process
In-Reply-To: <05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<05b5e2e4-91f3-2967-fadb-82435eaf4efd@kdab.com>
Message-ID: <1559322.qs8ZyXozxL@tjmaciei-mobl1>

Em quarta-feira, 21 de dezembro de 2016, às 01:25:11 BRST, Giuseppe D'Angelo 
escreveu:
> (Side note: we haven't managed to make a release happen on time since
> 5.2; actually, we've got pretty significant delays:
> 
> * Qt 5.2.0: +2 days
> * Qt 5.3.0: +21 days
> * Qt 5.4.0: +48 days
> * Qt 5.5.0: +64 days
> * Qt 5.6.0: +99 days
> * Qt 5.7.0: +49 days
> * Qt 5.8.0: +22 days and counting (won't be less than 50 considering the
> RC is not out yet, plus the 2 weeks of holidays))

As you've noticed, we don't have deadlines for the final releases. We only do 
deadlines for the feature freeze. From that point on, it's quality-based and 
should remain so.

The release happens when it's ready.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Jake.Petroules at qt.io  Wed Dec 21 19:37:47 2016
From: Jake.Petroules at qt.io (Jake Petroules)
Date: Wed, 21 Dec 2016 18:37:47 +0000
Subject: [Releasing] [Development] Qt 5.9 prebuild binary packages( was:
 Re: Qt 5.9)
In-Reply-To: <AM5PR0202MB2515E0149AB83B7102AA2AD79D930@AM5PR0202MB2515.eurprd02.prod.outlook.com>
References: <HE1PR0202MB252171FA6D321F159234CE199DA70@HE1PR0202MB2521.eurprd02.prod.outlook.com>
	<AM4PR0201MB21640C27134EAF8C752822EEE78C0@AM4PR0201MB2164.eurprd02.prod.outlook.com>
	<76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io>
	<5895604.KNhrVNCRLl@tjmaciei-mobl1>
	<AM5PR0202MB2515E0149AB83B7102AA2AD79D930@AM5PR0202MB2515.eurprd02.prod.outlook.com>
Message-ID: <DF067667-70D1-43F5-88A1-873BBD1ED603@qt.io>

LET'S DO IT! And thank you for following through on this idea.

This will reduce our package testing burden significantly which is very important because it lowers the barrier to entry for us to actually add new platforms/installers. For example, adding tvOS to the combined macOS/iOS/Android package would be valuable.

I would omit the host architectures (it provides no useful value since there are multiple host architectures in some cases) and target platforms from the filenames, though (like -android, -qnx, -android-ios), because they aren't there for the Windows package so it would be more consistent. The download descriptions should detail what each package contains.

Also, can we simply subsume the QNX packages into the base enterprise packages? i.e. combine qt-enterprise-linux-x64-android and qt-enterprise-linux-x64-qnx? Or is there a licensing-related issue around that? And why do we need different packages based on the license, anyways?

> On Dec 20, 2016, at 9:28 PM, Jani Heikkinen <jani.heikkinen at qt.io> wrote:
> 
> Hi all,
> 
> I finally managed to do testing how big combined windows installer would be. I was a bit surprised that it is only ~3.3 GB, which is still smaller than combined mac-android-ios installer ;) Ok, this is done from 5.8 packages & binaries so situation might be a bit different in 5.9 where we will have some new binaries to be done. But in the other hand we will/should drop some so I think the size of combined one should be still manageable.
> 
> So I propose we will offer following set of offline installers from Qt 5.9 ->
> 
> - For linux we will have 3 installers (instead of existing 5):
>   * qt-enterprise-linux-x64-android  (already delivering this)
>   * qt-opensource-linux-x64-android (already delivering this)
>      ** Desktop gcc 64-bit
>      ** Android x86
>      ** Android armv7
>   * qt-enterprise-linux-x64-qnx (already delivering this)
>      ** Desktop gcc 64-bit
>      ** Qnx x86
>      ** Qnx armv7
>      ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0
> 
> - For mac we will have 2 installers (instead of existing 6):
>   * qt-enterprise-mac-x64-android-ios (already delivering this)
>   * qt-opensource-mac-x64-android-ios (already delivering this)
>      ** Desktop clang 64-bit
>      ** Android x86
>      ** Android armv7
>      ** iOS
> 
> - For windows we will have 3 installers (instead of existing 17):
>   * qt-enterprise-windows-x86 (new)
>   * qt-opensource-windows-x86 (new)
>      ** Desktop MSVC 2013 x64
>      ** Desktop MSVC 2015 x86
>      ** Desktop MSVC 2015 x64
>      ** Desktop MSVC 2017 x64
>      ** Desktop MinGW 5.3 x86
>      ** UWP MSVC 2015 x86
>      ** UWP MSVC 2015 x64
>      ** UWP MSVC 2015 armv7
>      ** UWP MSVC 2017 x86
>      ** UWP MSVC 2017 x64
>      ** UWP MSVC 2017 armv7
>      ** Android x86
>      ** Android armv7
>  * qt-enterprise-linux-x64-qnx (already delivering this)
>      ** Desktop MinGW 5.3 x86
>      ** Qnx x86
>      ** Qnx armv7
>      ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0
> br,
> Jani
> 
> ________________________________________
> From: Development <development-bounces+jani.heikkinen=qt.io at qt-project.org> on behalf of Thiago Macieira <thiago.macieira at intel.com>
> Sent: Wednesday, November 30, 2016 5:05 PM
> To: development at qt-project.org
> Subject: Re: [Development] Qt 5.9
> 
> On quarta-feira, 30 de novembro de 2016 07:53:40 PST Jake Petroules wrote:
>> How about we have one package per host platform which includes all possible
>> hosts and targets compatible with it? Then we have 3 packages, ever.
> 
> Or, at least, one binary per platform + compiler combination. So that's 1
> Linux package, 1 macOS package, 3 Windows packages today, with a 4th Windows
> (MSVC 2017) coming for 5.9.
> 
> --
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petroules at qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io



From Maurice.Kalinowski at qt.io  Thu Dec 22 08:09:51 2016
From: Maurice.Kalinowski at qt.io (Maurice Kalinowski)
Date: Thu, 22 Dec 2016 07:09:51 +0000
Subject: [Releasing] [Development] Proposal to adjust release candidate
 process
In-Reply-To: <AM4PR02MB1652D49BBE52009A6A0690B3F0930@AM4PR02MB1652.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>,
	<2557995.lvaW6oQBlV@tjmaciei-mobl1>
	<AM4PR02MB1652D49BBE52009A6A0690B3F0930@AM4PR02MB1652.eurprd02.prod.outlook.com>
Message-ID: <HE1PR0201MB2218F87C4D13CDDE050F296F95920@HE1PR0201MB2218.eurprd02.prod.outlook.com>

Hence,

Technology Preview
Preview
Release Preview
Release Candidate
Release

\o/

Maurice

Von: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] Im Auftrag von Marco Bubke
Gesendet: Wednesday, December 21, 2016 4:21 PM
An: Thiago Macieira <thiago.macieira at intel.com>; development at qt-project.org
Betreff: Re: [Development] Proposal to adjust release candidate process


I think many users see a beta as something you better not touch, but a release candidates can be trusted much more. I know it's not intended that way but people learned by experiences. [??]



Maybe "pre release" or "preview" could be a name to show the final status?





________________________________
From: Development <development-bounces+marco.bubke=qt.io at qt-project.org<mailto:development-bounces+marco.bubke=qt.io at qt-project.org>> on behalf of Thiago Macieira <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>
Sent: Wednesday, December 21, 2016 3:45:37 PM
To: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] Proposal to adjust release candidate process

Em terça-feira, 20 de dezembro de 2016, às 13:34:39 BRST, Tuukka Turunen
escreveu:
> If desired, we could use some other name than "Release Candidate 1" for the
> release that begins the last phase of the release. It could be called "Beta
> 2" or "Technology preview", if so desired. Personally, I would call it
> "Release Candidate 1".
>
> The difference to our current process is quite small. In essence it would be
> about considering the "RC1" the beginning of the final releasing phase (.0
> branch), not something we do almost at the end of it. I believe that
> lowering the quality criterial for "RC1" helps us in being more efficient
> as it has been in practice impossible to really fulfill the current process
> goal and have already the first RC as good as the final.

I like the process, but I would also rename the release like you proposed. We
can't have something called "release candidate" when we *know* it's not a
candidate. Let's call it beta 2, beta 3, etc. until we can make it a release.

Release candidates are really the snapshots that the release team creates when
we're testing for sanity right before the actual release.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20161222/2af756bd/attachment.html>

From Shawn.Rutledge at qt.io  Thu Dec 22 08:25:23 2016
From: Shawn.Rutledge at qt.io (Shawn Rutledge)
Date: Thu, 22 Dec 2016 07:25:23 +0000
Subject: [Releasing] [Development] Proposal to adjust release candidate
 process
In-Reply-To: <HE1PR0201MB2218F87C4D13CDDE050F296F95920@HE1PR0201MB2218.eurprd02.prod.outlook.com>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<2557995.lvaW6oQBlV@tjmaciei-mobl1>
	<AM4PR02MB1652D49BBE52009A6A0690B3F0930@AM4PR02MB1652.eurprd02.prod.outlook.com>
	<HE1PR0201MB2218F87C4D13CDDE050F296F95920@HE1PR0201MB2218.eurprd02.prod.outlook.com>
Message-ID: <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io>


> On 22 Dec 2016, at 08:09, Maurice Kalinowski <Maurice.Kalinowski at qt.io> wrote:
> 
> Hence,
>  
> Technology Preview
> Preview
> Release Preview
> Release Candidate
> Release

Tech Preview is so far the term for a module which is released but we reserve the right to continue making API changes anyway, right?  So changing that might be confusing.

And besides, alpha and beta are traditional and well understood.  (Following that pattern though, I guess we ought to call the RC a “gamma”, but that’s not traditional for some reason.)


From tuukka.turunen at qt.io  Thu Dec 22 13:54:08 2016
From: tuukka.turunen at qt.io (Tuukka Turunen)
Date: Thu, 22 Dec 2016 12:54:08 +0000
Subject: [Releasing] [Development] Proposal to adjust release candidate
 process
In-Reply-To: <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io>
References: <AM4PR0202MB29480B2D4667E949BBF423778F900@AM4PR0202MB2948.eurprd02.prod.outlook.com>
	<2557995.lvaW6oQBlV@tjmaciei-mobl1>
	<AM4PR02MB1652D49BBE52009A6A0690B3F0930@AM4PR02MB1652.eurprd02.prod.outlook.com>
	<HE1PR0201MB2218F87C4D13CDDE050F296F95920@HE1PR0201MB2218.eurprd02.prod.outlook.com>
	<6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io>
Message-ID: <AM4PR0202MB29487B163D738871A58299BB8F920@AM4PR0202MB2948.eurprd02.prod.outlook.com>



> -----Original Message-----
> From: Development [mailto:development-
> bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Shawn
> Rutledge
> Sent: torstaina 22. joulukuuta 2016 9.25
> To: development at qt-project.org; releasing at qt-project.org
> Subject: Re: [Development] Proposal to adjust release candidate process
> 
> 
> > On 22 Dec 2016, at 08:09, Maurice Kalinowski <Maurice.Kalinowski at qt.io>
> wrote:
> >
> > Hence,
> >
> > Technology Preview
> > Preview
> > Release Preview
> > Release Candidate
> > Release
> 
> Tech Preview is so far the term for a module which is released but we
> reserve the right to continue making API changes anyway, right?  So changing
> that might be confusing.
> 
> And besides, alpha and beta are traditional and well understood.  (Following
> that pattern though, I guess we ought to call the RC a “gamma”, but that’s
> not traditional for some reason.)
> 

:)

If we do not want to call the first development release from the release branch "Release Candidate 1", then I think calling it "Release Preview" is a good approach.

Yours,

	Tuukka

> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

From thiago.macieira at intel.com  Sat Dec 24 13:17:27 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 24 Dec 2016 10:17:27 -0200
Subject: [Releasing] Remove "branch" lines from .gitmodules in qt5.git prior
 to tagging
Message-ID: <1592934.NUJtL8VR8c@tjmaciei-mobl1>

The .gitmodule file contains "branch" lines that are invalid:

[submodule "qtbase"]
        path = qtbase
        url = ../qtbase.git
        branch = 5.7.1
        status = essential

Please remove those lines as the branch gets deleted too after the release.

This started happening in the 5.4.0 release. 5.3.2 is not affected.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From Simon.Hausmann at qt.io  Sat Dec 24 13:36:57 2016
From: Simon.Hausmann at qt.io (Simon Hausmann)
Date: Sat, 24 Dec 2016 12:36:57 +0000
Subject: [Releasing] Remove "branch" lines from .gitmodules in qt5.git
 prior to tagging
In-Reply-To: <1592934.NUJtL8VR8c@tjmaciei-mobl1>
References: <1592934.NUJtL8VR8c@tjmaciei-mobl1>
Message-ID: <VI1PR02MB1006BF4CED27FAD2B33A8D468C940@VI1PR02MB1006.eurprd02.prod.outlook.com>



Hmm, the CI interprets these lines. Do you know of any other tool using them?

How about falling back to the tag if the branch cannot be found?


Simon

From: thiago.macieira at intel.com
Sent: December 24, 2016 13:20
To: releasing at qt-project.org
Subject: [Releasing] Remove "branch" lines from .gitmodules in qt5.git prior to tagging


The .gitmodule file contains "branch" lines that are invalid:

[submodule "qtbase"]
        path = qtbase
        url = ../qtbase.git
        branch = 5.7.1
        status = essential

Please remove those lines as the branch gets deleted too after the release.

This started happening in the 5.4.0 release. 5.3.2 is not affected.
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20161224/0e4bd162/attachment.html>

From thiago.macieira at intel.com  Sat Dec 24 14:04:23 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 24 Dec 2016 11:04:23 -0200
Subject: [Releasing] Remove "branch" lines from .gitmodules in qt5.git
 prior to tagging
In-Reply-To: <VI1PR02MB1006BF4CED27FAD2B33A8D468C940@VI1PR02MB1006.eurprd02.prod.outlook.com>
References: <1592934.NUJtL8VR8c@tjmaciei-mobl1>
	<VI1PR02MB1006BF4CED27FAD2B33A8D468C940@VI1PR02MB1006.eurprd02.prod.outlook.com>
Message-ID: <4427806.1FIm9MFrKF@tjmaciei-mobl1>

Em sábado, 24 de dezembro de 2016, às 12:36:57 BRST, Simon Hausmann escreveu:
> Hmm, the CI interprets these lines. Do you know of any other tool using
> them?

git submodule

> How about falling back to the tag if the branch cannot be found?

Are you proposing a patch to git?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Sat Dec 24 15:35:21 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 24 Dec 2016 12:35:21 -0200
Subject: [Releasing] Remove "branch" lines from .gitmodules in qt5.git
 prior to tagging
In-Reply-To: <4427806.1FIm9MFrKF@tjmaciei-mobl1>
References: <1592934.NUJtL8VR8c@tjmaciei-mobl1>
	<VI1PR02MB1006BF4CED27FAD2B33A8D468C940@VI1PR02MB1006.eurprd02.prod.outlook.com>
	<4427806.1FIm9MFrKF@tjmaciei-mobl1>
Message-ID: <3267798.gNC3r3N6gg@tjmaciei-mobl1>

Em sábado, 24 de dezembro de 2016, às 11:04:23 BRST, Thiago Macieira escreveu:
> Em sábado, 24 de dezembro de 2016, às 12:36:57 BRST, Simon Hausmann 
escreveu:
> > Hmm, the CI interprets these lines. Do you know of any other tool using
> > them?
> 
> git submodule

Some user in interest@ had a problem after checking the v5.7.1 tag out;

===
git checkout tags/v5.7.1
perl init-repository

But it failed with the error "fatal: Remote branch 5.7.1 not found in upstream 
origin”
===

Since the branch gets deleted, the contents of the .gitmodule file are wrong. 
I've found that git submodule accepts "." as the branch name to mean "the same 
branch as this repository", which will also help us by not having to update 
that file every time.

	https://codereview.qt-project.org/180826

I have not tested to see what happens if you're in no branch. It might fall 
back to the linked commit if it can't find a branch. I'll test later.

I have not tested init-repository. I don't use it, so I don't care. git 
submodule is enough.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center



From thiago.macieira at intel.com  Sat Dec 24 17:02:35 2016
From: thiago.macieira at intel.com (Thiago Macieira)
Date: Sat, 24 Dec 2016 14:02:35 -0200
Subject: [Releasing] Remove "branch" lines from .gitmodules in qt5.git
 prior to tagging
In-Reply-To: <3267798.gNC3r3N6gg@tjmaciei-mobl1>
References: <1592934.NUJtL8VR8c@tjmaciei-mobl1>
	<4427806.1FIm9MFrKF@tjmaciei-mobl1>
	<3267798.gNC3r3N6gg@tjmaciei-mobl1>
Message-ID: <3418299.VrS8QFHf7Y@tjmaciei-mobl1>

Em sábado, 24 de dezembro de 2016, às 12:35:21 BRST, Thiago Macieira escreveu:
> I have not tested to see what happens if you're in no branch. It might fall
> back to the linked commit if it can't find a branch. I'll test later.

Looks like git submodule update has no problem either way. The bug is in init-
repository, so I'm done here.

> I have not tested init-repository. I don't use it, so I don't care. git
> submodule is enough.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center