Re: [Development] Proposal to adjust release candidate process

2016-12-21 Thread Shawn Rutledge 

> On 22 Dec 2016, at 08:09, Maurice Kalinowski  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.)

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9)

2016-12-21 Thread Oliver Wolff 
Can someone elaborate on how "one package per OS" reduces the testing 
burden significantly? We still have to check every 
platform/configuration that is inside the package. All that changes is 
that the testers install from one big package instead of smaller 
packages. I doubt that one person will check the whole windows package 
(for example). At least I will not volunteer to do that :X



On 21/12/2016 19:37, Jake Petroules wrote:

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  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  on behalf 
of Thiago Macieira 
Sent: Wednesday, November 30, 2016 5:05 PM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

2016-12-21 Thread Maurice Kalinowski 
Hence,

Technology Preview
Preview
Release Preview
Release Candidate
Release

\o/

Maurice

Von: Development 
[mailto:development-bounces+maurice.kalinowski=qt...@qt-project.org] Im Auftrag 
von Marco Bubke
Gesendet: Wednesday, December 21, 2016 4:21 PM
An: Thiago Macieira ; development@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 
mailto:development-bounces+marco.bubke=qt...@qt-project.org>>
 on behalf of Thiago Macieira 
mailto:thiago.macie...@intel.com>>
Sent: Wednesday, December 21, 2016 3:45:37 PM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Calendar Systems proposal

2016-12-21 Thread Sune Vuorela 
On 2016-12-17, Soroush Rabiei  wrote:
> it's wrong to add such implementation to QDate. My view of QDate is this:
> QDate represents a day in time. So it only needs to know what day it is
> (how many days are to the day 0).

And it is exactly things like that that would prevent partial date
support in QDate (which is why I brought it up)

/Sune

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9)

2016-12-21 Thread Jake Petroules 
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  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  
> on behalf of Thiago Macieira 
> Sent: Wednesday, November 30, 2016 5:05 PM
> To: development@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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

2016-12-21 Thread Marco Bubke 
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  on 
behalf of Thiago Macieira 
Sent: Wednesday, December 21, 2016 3:45:37 PM
To: development@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

2016-12-21 Thread Thiago Macieira 
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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

2016-12-21 Thread Alexander Blasche 
Hi,

> -Original Message-
> From: Development [mailto:development-
> bounces+alexander.blasche=qt...@qt-project.org] On Behalf Of Sean Harmer
> Sent: Tuesday, 20 December 2016 16:14
 
> 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.
...
 > * 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.

Tuukka kind of made this point already but I'd like to make it more succinct.

We do not want to change the time or the quality constraint. We want to adjust 
the feature constraint. This means that you and I as maintainers very much have 
it in our hands to manage the release pressure. You have to fight your own 
weaker self and accept that you may not keep the quality up with your feature 
plans for the module you maintain.

--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Proposal to adjust release candidate process

2016-12-21 Thread Tuukka Turunen 


> -Original Message-
> From: sean.harmer On Behalf Of Sean Harmer
> Sent: tiistaina 20. joulukuuta 2016 17.14
> To: development@qt-project.org
> Cc: Tuukka Turunen ; releas...@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 w