Re: [Development] Is QtConcurrent's code generator still in use?

2012-11-14 Thread Sorvig Morten
On Nov 11, 2012, at 6:07 AM, Sze Howe Koh  wrote:
> 
> Thanks for the explanation. I've opened tickets for this:
> https://bugreports.qt-project.org/browse/QTBUG-27940
> https://bugreports.qt-project.org/browse/QTBUG-27941
> 
> I asked because I'm working on patches for Qt Concurrent now; I don't
> know all the updates that the tool needs, but I'll patch it with my
> changes.
> 

I think what QtConcurrent really needs is a plan. What do we want it to be? 
There are several options, and I'd like to offer the "null" option:

QtConcurrent is done. The implementation is not good enough to be used as a 
base for further development. We should limit ourselves to fixing bugs and 
making small improvements where we can.

This is in line with moving QtConcurrent out of Qt Core. It also has the 
advantage of not taking much developer time.

- Morten



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


Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

2012-11-14 Thread Anttila Janne
Hi,

I have been following discussion on this thread for a while now and here 
are some comments from CI point of view. First I would like to list 
existing CI configurations since there clearly are some misunderstandings:

Qt 4.8
linux-g++-32_Ubuntu_10.04_x86
linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64 
linux-g++_shadow-build_Ubuntu_12.04_x64 qws_linux-x86-g++
macx-g++_OSX_10.6
macx-g++_developer-build_OSX_10.7
win32-msvc2010_Windows_7
win32-msvc2010_developer-build_Windows_7

These we plan to keep as is, possibly adding one OS X 10.8 and Windows 8 
configuration.

Qt 5.x
linux-g++-32_Ubuntu_10.04_x86
linux-g++-32_developer-build_Ubuntu_10.04_x86 
linux-arm-gnueabi-g++_Ubuntu_11.10_x86 
linux-g++_shadow-build_Ubuntu_11.10_x86
linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64 
linux-g++_no-widgets_Ubuntu_12.04_x64
macx-g++_developer-build_OSX_10.6
macx-clang_developer-build_qtnamespace_OSX_10.7 
win32-msvc2010_Windows_7 
win32-msvc2010_developer-build_qtnamespace_Windows_7 
win32-msvc2010_developer-build_angle_Windows_7

One important thing to note about CI system is that it is not only OS version
or compiler, but there is also set of different Qt configure options being 
tested
and all of those require about equivalent HW capacity. So when you today stage
something in any of the Qt5 repos, 11 machines start building and testing 
your change. When you multiply that with amount of Qt5 repositories and 
possibly soon introduced branching of repositories. You will quite quickly 
end-up to very high need for HW capacity.

Then a few comments discussions on this thread:

> However, if & when we do decide to remove XP from the CI system it should be 
> replaced with vista (as the oldest supported windows version).
> We shouldn't test only W7 and W8.

Windows XP is not currently tested by CI and I don't believe adding it to CI
would be rational in this phase - there are more important configurations to
test on HW limits we have. If adding Windows XP to makes sense somewhere
it is Qt 4.8 CI.

There is also no Windows Vista in CI and adding that to CI makes even less 
sense for me. Based on our customer surveys installation-base for Vista is 
very small (compared to XP and 7),and decreasing all the time.

> I am wondering if windows-7-64-msvc2010-angle should become a reference 
> platform and windows-7-32-msvc2010-angle a tier 1 instead, given that 
> Windows is 64bit now and running 32 bit applications is not really native.
>
> It would be nice to have it tested though, since compiling on 64bit 
> reveals additional warnings about casting between different 
> ints/pointers, etc, that might one day be caught by a compiler warnings 
> check (which I am still hoping for).

> Tuukka also wants to see Windows 8 (maybe replacing XP). 

I agree CI system should definitely have some 64-bit and  Windows 8 
configurations,but I also would like to keep some 32-bit Windows configurations 
there. And like Kai reminded in one of the previous mails we should get also 
MinGW to CI system. With these in mind my suggestion for Qt5 Windows CI 
configurations:

win32-msvc2010_Windows_7
win32-msvc2010_developer-build_angle_Windows_7
win32-mingw47_developer-build_qtlibinfix_Windows_7(new)
win64-msvc2012_developer-build_qtnamespace_Windows_8 (new)

>> Tuukka and Qi Liang wants to see OS X 10.8 (maybe replacing 10.6) in the 
>> list. The feasibility of this is probably something again for the CI system 
>> maintainers + mac platform maintainer (Morten) to answer...
>
> IMO Mac OS X 10.8 must be Tier 1. 
> Something like half a year after Qt 5.0.0, Mac OS 10.9 will be released and 
> 10.6 becomes more and more irrelevant.

I agree 10.6 is not very relevant for Qt5. And keeping in mind that we have
limited HW capacity, I suggest the following CI configurations for OS SX:

macx-clang_developer-build_qtnamespace_OSX_10.7 
macx-clang_developer-build_OSX_10.8 (new with case-sensitive file system)

One additional thing I would like to study related to OS X CI configurations is 
sandboxing. 

There haven't been too much discussion about different Linux configurations, 
But as you can see from list of currently CI tested configurations there are
quite many of them. Personally I'm thinking that we should remove Ubuntu 
10.04 or at least reduce the number of tested configurations from 2 to 1 
and use that HW capacity to extended testing of different Windows 
configurations and possibly static builds of Qt. That said my suggestion 
for Qt 5 Linux CI configurations is:

linux-g++-32_Ubuntu_10.04_x86 (possibly to be removed)
linux-arm-gnueabi-g++_Ubuntu_11.10_x86 
linux-g++_shadow-build_Ubuntu_11.10_x86
linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64 
linux-g++_no-widgets_Ubuntu_12.04_x64
linux-g++developer-build_static_Ubuntu_12.04_x64 (new)

> However, since right now

[Development] FOSDEM 2012

2012-11-14 Thread Sivan Greenberg
Hi All,

   As I've request presence for the project in FOSDEM, I'd like to know if
people would be interested in giving talks and showcasing demos
specifically for latest Qt5 features and at the most 1 4.8 cool demo at the
FOSDEM stand, if we're granted one.

 Let's keep the discussion on marketing@ , although I've CC'd dev for wider
developer audience.

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


[Development] Qt 4.8.4 Release candidate 3 available

2012-11-14 Thread Taipale Juhani
Hi all,

Qt 4.8.4 Release candidate 3  packages are available at 
http://releases.qt-project.org/digia/4.8.4_RC3/

It is built on SHA1: d742aa4ee727de0e318e26ba24b11a780081f0c9


Br,
Juhani
--
Juhani Taipale
Software Specialist - Digia, Qt

Visit us on: http://qt.digia.com

Juhani Taipale
Software Specialist, Qt Commercial R&D
Digia Plc
Piippukatu 11, FI-40100 JYVÄSKYLÄ FINLAND
Tel: +358 50 384 3755

Visit us at :www.digia.com or qt.digia.com

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


Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

2012-11-14 Thread Sorvig Morten
On Nov 13, 2012, at 2:17 PM, Koehne Kai  wrote:
> 
> Tukka and Qi Liang wants to see OS X 10.8 (maybe replacing 10.6) in the list. 
> The feasibility of this is probably something again for the CI system 
> maintainers + mac platform maintainer (Morten) to answer...

We should make the most recent version of OS X Tier 1 as it is released, if 
nothing else for the messaging: "We think this platform is important".  Can we 
say "Latest Mac OS X"?

10.6 is separate issue. It is getting less relevant, but still has a 
significant market share (31%)[0]. I would say it's a bit to early to drop it.

Morten

[0] 
http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0&qpcustomb=*2
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

2012-11-14 Thread shane.kearns
> There haven't been too much discussion about different Linux
> configurations, But as you can see from list of currently CI tested
> configurations there are quite many of them. Personally I'm thinking
> that we should remove Ubuntu
> 10.04 or at least reduce the number of tested configurations from 2 to
> 1 and use that HW capacity to extended testing of different Windows
> configurations and possibly static builds of Qt. That said my
> suggestion for Qt 5 Linux CI configurations is:
>
> linux-g++-32_Ubuntu_10.04_x86 (possibly to be removed)
> linux-arm-gnueabi-g++_Ubuntu_11.10_x86
> linux-g++_shadow-build_Ubuntu_11.10_x86
> linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64
> linux-g++_no-widgets_Ubuntu_12.04_x64
> linux-g++developer-build_static_Ubuntu_12.04_x64 (new)
>

10.04 LTS is more important than 11.10, as it gives test coverage of a 
different window manager and the 0.9 openSSL libraries.
I'd say to drop 11.10 if anything, since it is very similar to 12.04 LTS.

If keeping only one configuration on a platform, keep the developer build since 
it has more test coverage than the production build.

This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information. If you have received it in 
error, please notify the sender immediately and delete the original. Any other 
use of the e-mail by you is prohibited.

Where allowed by local law, electronic communications with Accenture and its 
affiliates, including e-mail and instant messaging (including content), may be 
scanned by our systems for the purposes of information security and assessment 
of internal compliance with Accenture policy.

__

www.accenture.com

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


Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

2012-11-14 Thread Stephen Chu
On 11/14/12 8:37 AM, Sorvig Morten wrote:
> 10.6 is separate issue. It is getting less relevant, but still has a 
> significant market share (31%)[0]. I would say it's a bit to early to drop it.

Also 10.6 supports 32-bit machines. If 10.6 is still officially 
supported, so should 32-bit on 10.6.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms

2012-11-14 Thread Joseph Crowell
Could openSuse Build Service results be used at all?

On 15/11/2012 12:38 AM, Stephen Chu wrote:
> On 11/14/12 8:37 AM, Sorvig Morten wrote:
>> 10.6 is separate issue. It is getting less relevant, but still has a 
>> significant market share (31%)[0]. I would say it's a bit to early to drop 
>> it.
> Also 10.6 supports 32-bit machines. If 10.6 is still officially
> supported, so should 32-bit on 10.6.
> ___
> 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] Is QtConcurrent's code generator still in use?

2012-11-14 Thread Christian Kandeler
On 11/14/2012 12:17 PM, Sorvig Morten wrote:
> QtConcurrent is done. The implementation is not good enough to be used as a 
> base for further development.

Can you be a bit more specific? What are the general problems and why 
can't they be easily solved?


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


Re: [Development] Is QtConcurrent's code generator still in use?

2012-11-14 Thread Sune Vuorela
On 2012-11-14, Christian Kandeler  wrote:
> On 11/14/2012 12:17 PM, Sorvig Morten wrote:
>> QtConcurrent is done. The implementation is not good enough to be used as a 
>> base for further development.
>
> Can you be a bit more specific? What are the general problems and why 
> can't they be easily solved?

I think it is quite limited and hard to use. I recently tried and after
giving up on that, I switched a project to the ThreadWeaver library by
KDE which not only made my code simpler, it also made it much easier to
understand and having threading cote separated out.

The ThreadWeaver library is a quite simple, but yet powerful thing built
on qtcore. 

/Sune

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