Re: [Development] The final mile

[André Pönitz]

On Sun, Dec 02, 2012 at 05:11:18PM +0100, Stephen Kelly wrote:
> On Sunday, December 02, 2012 14:09:15 you wrote:
> > Hi,
> > 
> > Apologies for the top-quote, handicapped with web access right now
> > :(
> 
> I don't understand the connection between web access and top-quoting,
> but fair enough :). I assume outlook makes it impossible to bottom
> quote somehow.

Outlook web access (or "app") is more restricted than outlook.

Sure. One can edit the attribution, and add line breaks and quotation
markers manually. Or cut&paste the message to a real text editor, finish
the mail there, cut&paste back. So it is "somehow" possible, just far
from convenient.

If you know of a way how to use it properly without resorting to this
kind of workarounds, feel free to give a hint.

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

Re: [Development] The final mile

[Thiago Macieira]

On domingo, 2 de dezembro de 2012 14.09.15, Hausmann Simon wrote:
> (2) QWebElement and QWebSettings are indeed in include/QtWebKit and
> QWebView is in include/QtWebKitWidgets, i.e. the module split is present on
> the include level, too.

This, in turn, automatically means the error we found in the build is not 
specific to Mac, but a qmake problem. Granted, it might be a qmake problem due 
to some code specific to Mac (frameworks), but I don't think so.

The dependency of Qt modules comes from one of the files created during 
compilation:

[installed Qt] 
$ cd ~/qt5
$ grep depends lib64/qt5/mkspecs/modules/qt_lib_widgets.pri
QT.widgets.depends = core gui

[uninstalled Qt] 
$ cd $QTDIR
$ egrep 'depends|include' mkspecs/modules/qt_lib_widgets.pri
QT_MODULE_INCLUDE_BASE = /home/thiago/obj/qt/qt5/qtbase/include
include(/home/thiago/obj/qt/qt5/qtbase/mkspecs/modules-
inst/qt_lib_widgets.pri)
$ grep depends /home/thiago/obj/qt/qt5/qtbase/mkspecs/modules-
inst/qt_lib_widgets.pri
QT.widgets.depends = core gui

I'm rebuilding WebKit now to check what it generates.

But given the case, it's likely to be what Kai thought: an artifact of the 
buildsystem.

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


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Stephen Kelly]

On Sunday, December 02, 2012 14:09:15 you wrote:
> Hi,
> 
> Apologies for the top-quote, handicapped with web access right now :(

I don't understand the connection between web access and top-quoting, but fair 
enough :). I assume outlook makes it impossible to bottom quote somehow.

> 
> Regarding your questions I'm positive:
> 
> (1) QtWebKit and QtWebKitWidgets are using all the features of the Qt5
> build system for module creation, they behave like any other module.

Great. My recent encounter with qtactiveqt included discovering that it was 
doing some things incompatible with the generated cmake files (I still don't 
know why I get a linking error : https://codereview.qt-
project.org/#change,41330). Good to know we don't need more patched for the 
webkit stuff too.

> (2)
> QWebElement and QWebSettings are indeed in include/QtWebKit and QWebView is
> in include/QtWebKitWidgets, i.e. the module split is present on the include
> level, too.
> (3) I do see see two cmake subdirs in lib/cmake, Qt5WebKitWidgets and
> Qt5WebKit with two .cmake files each. (4) Yes, the libraries like
> lib/libQt5WebKit.* and lib/libQt5WebKitWidgets.* do exist (that's the whole
> point of the split :)

Great. I updated my own qtwebkit repo, but it did not build because somehow it 
wasn't linking to Qt5Network and WebCore properly. Maybe that's because I 
don't use qt5.git. I hacked the makefile to fix the problem.


QtWebKit: WARNING: 
/home/stephen/dev/src/qtwebkit/Source/ThirdParty/gyp/test/include_dirs/src/subdir/inc2/include2.h
 
does not include QT_BEGIN_HEADER
QtWebKit: WARNING: 
/home/stephen/dev/src/qtwebkit/Source/ThirdParty/gyp/test/include_dirs/src/subdir/inc2/include2.h
 
does not include QT_BEGIN_NAMESPACE
make[2]: Entering directory `/home/stephen/dev/build/qtbase/qtwebkit/Source'
rm -f libQt5WebKit.so.5.0.0 libQt5WebKit.so libQt5WebKit.so.5 
libQt5WebKit.so.5.0
g++ -m64 -Wl,--gc-sections -Wl,--no-undefined -Wl,--no-undefined -Wl,-
rpath,/home/stephen/dev/prefix/qtbase/lib -shared -Wl,-Bsymbolic-functions -
Wl,-soname,libQt5WebKit.so.5 -o libQt5WebKit.so.5.0.0   -L/usr/X11R6/lib64 -
L/home/stephen/dev/prefix/qtbase/lib -lQt5Network -lQt5Gui -lQt5Core -lpthread 
-Wl,-whole-archive -lWebKit1 -Wl,-no-whole-archive -
L/home/stephen/dev/build/qtbase/qtwebkit/Source/WebKit/debug -Wl,-whole-
archive -lWebKit2 -Wl,-no-whole-archive -
L/home/stephen/dev/build/qtbase/qtwebkit/Source/WebKit2/debug -Wl,-whole-
archive -lWebCore -Wl,-no-whole-archive -
L/home/stephen/dev/build/qtbase/qtwebkit/Source/WebCore/debug -lz -lXrender -
ljpeg -lpng -Wl,-whole-archive -lANGLE -Wl,-no-whole-archive -
L/home/stephen/dev/build/qtbase/qtwebkit/Source/ThirdParty/ANGLE/debug -Wl,-
whole-archive -lJavaScriptCore -Wl,-no-whole-archive -
L/home/stephen/dev/build/qtbase/qtwebkit/Source/JavaScriptCore/debug -Wl,-
whole-archive -lWTF -Wl,-no-whole-archive -
L/home/stephen/dev/build/qtbase/qtwebkit/Source/WTF/debug -licui18n -licuuc -
licudata -lQt5Gui -L/usr/X11R6/lib64 -L/home/stephen/dev/prefix/qtbase/lib -
lQt5Sql -lQt5Core -lpthread -lGL -lXext -lm -lX11 -lxslt -lxml2 -ludev -lrt
/home/stephen/dev/build/qtbase/qtwebkit/Source/WebKit/debug/libWebKit1.a(FrameLoaderClientQt.o):
 
In function 
`WebCore::FrameLoaderClientQt::startDownload(WebCore::ResourceRequest const&, 
WTF::String const&)':
FrameLoaderClientQt.cpp:
(.text._ZN7WebCore19FrameLoaderClientQt13startDownloadERKNS_15ResourceRequestERKN3WTF6StringE+0x60):
 
undefined reference to `QNetworkRequest::~QNetworkRequest()'
/home/stephen/dev/build/qtbase/qtwebkit/Source/WebKit/debug/libWebKit1.a(FrameLoaderClientQt.o):
 
In function 
`WebCore::FrameLoaderClientQt::dispatchDecidePolicyForNavigationAction(void 
(WebCore::PolicyChecker::*)(WebCore::PolicyAction), WebCore::NavigationAction 
const&, WebCore::ResourceRequest const&, 
WTF::PassRefPtr)':
FrameLoaderClientQt.cpp:
(.text._ZN7WebCore19FrameLoaderClientQt39dispatchDecidePolicyForNavigationActionEMNS_13PolicyCheckerEFvNS_12PolicyActionEERKNS_16NavigationActionERKNS_15ResourceRequestEN3WTF10PassRefPtrINS_9FormStateEEE+0x310):
 
undefined reference to `QNetworkRequest::~QNetworkRequest()'
FrameLoaderClientQt.cpp:
(.text._ZN7WebCore19FrameLoaderClientQt39dispatchDecidePolicyForNavigationActionEMNS_13PolicyCheckerEFvNS_12PolicyActionEERKNS_16NavigationActionERKNS_15ResourceRequestEN3WTF10PassRefPtrINS_9FormStateEEE+0x45f):
 
undefined reference to `QNetworkRequest::~QNetworkRequest()'
FrameLoaderClientQt.cpp:
(.text._ZN7WebCore19FrameLoaderClientQt39dispatchDecidePolicyForNavigationActionEMNS_13PolicyCheckerEFvNS_12PolicyActionEERKNS_16NavigationActionERKNS_15ResourceRequestEN3WTF10PassRefPtrINS_9FormStateEEE+0x4e0):
 
undefined reference to `QNetworkRequest::url() const'
/home/stephen/dev/build/qtbase/qtwebkit/Source/WebKit/debug/libWebKit1.a(FrameLoaderClientQt.o):
 
In function 
`WebCore::FrameLoaderClientQt::dispatchDecidePolicyForNewWindowAction(void 
(WebCore::PolicyChecker::*)(WebCore::PolicyAction), WebCore::NavigationAction

Re: [Development] The final mile

[Hausmann Simon]

Hi,

Apologies for the top-quote, handicapped with web access right now :(

Regarding your questions I'm positive:

(1) QtWebKit and QtWebKitWidgets are using all the features of the Qt5 
build system for module creation, they behave like any other module.
(2) QWebElement and QWebSettings are indeed in include/QtWebKit and 
QWebView is in include/QtWebKitWidgets, i.e. the module split is
present on the include level, too.
(3) I do see see two cmake subdirs in lib/cmake, Qt5WebKitWidgets and 
Qt5WebKit with two .cmake files each.
(4) Yes, the libraries like lib/libQt5WebKit.* and 
lib/libQt5WebKitWidgets.* do exist (that's the whole point of the split :)



Simon


From: development-bounces+simon.hausmann=digia@qt-project.org 
[development-bounces+simon.hausmann=digia@qt-project.org] on behalf of 
Stephen Kelly [stephen.ke...@kdab.com]
Sent: Sunday, December 02, 2012 1:53 PM
To: development@qt-project.org
Subject: Re: [Development] The final mile

On Sunday, December 02, 2012 12:27:18 Hausmann Simon wrote:
> Hi,
>
> I can try to add some clarifications.
>
> It is our intention to make it so that when you write
>
> QT += webkitwidgets
>

Did you also consider how you might have to change how the cmake files are
generated?

Do you now generate both lib/cmake/QtWebKit/QtWebKitConfig.cmake and
lib/cmake/QtWebKitWidgets/QtWebKitWidgetsConfig.cmake ?

Do the directories include/QtWebKitWidgets and include/QtWebKit exist and
contain corresponding headers? Eg does include/QtWebKitWidgets/QWebView and
include/QtWebKit/QWebElement exist, for example?

Do libraries like lib/libQt5WebKit.* and lib/libQt5WebKitWidgets.* exist?

If not then you may be generating bogus broken cmake files for QtWebKit now.

Please add a unit test to the webkit test system for the cmake stuff. See for
example tests/auto/cmake in the qtscript repo for how that's done in the Qt CI
system. For webkit, the cmake.pro can probably just be the same, and the
CMakeLists.txt would look something like this:


 cmake_minimum_required(VERSION 2.8)

 project(qmake_cmake_files)

 enable_testing()

 find_package(Qt5Core REQUIRED)

 include("${_Qt5CTestMacros}")

 set(Qt5_MODULE_TEST_DEPENDS Widgets)

 test_module_includes(
   WebKit QWebView
   WebKitWidgets QWebElement
 )

Thanks,

--
Stephen Kelly  | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
** Qt Developer Conference: http://qtconference.kdab.com/ **
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Stephen Kelly]

On Sunday, December 02, 2012 12:27:18 Hausmann Simon wrote:
> Hi,
> 
> I can try to add some clarifications.
> 
> It is our intention to make it so that when you write
> 
> QT += webkitwidgets
> 

Did you also consider how you might have to change how the cmake files are 
generated?

Do you now generate both lib/cmake/QtWebKit/QtWebKitConfig.cmake and 
lib/cmake/QtWebKitWidgets/QtWebKitWidgetsConfig.cmake ?

Do the directories include/QtWebKitWidgets and include/QtWebKit exist and 
contain corresponding headers? Eg does include/QtWebKitWidgets/QWebView and 
include/QtWebKit/QWebElement exist, for example?

Do libraries like lib/libQt5WebKit.* and lib/libQt5WebKitWidgets.* exist? 

If not then you may be generating bogus broken cmake files for QtWebKit now.

Please add a unit test to the webkit test system for the cmake stuff. See for 
example tests/auto/cmake in the qtscript repo for how that's done in the Qt CI 
system. For webkit, the cmake.pro can probably just be the same, and the 
CMakeLists.txt would look something like this:


 cmake_minimum_required(VERSION 2.8)

 project(qmake_cmake_files)

 enable_testing()

 find_package(Qt5Core REQUIRED)

 include("${_Qt5CTestMacros}")

 set(Qt5_MODULE_TEST_DEPENDS Widgets)

 test_module_includes(
   WebKit QWebView
   WebKitWidgets QWebElement
 )

Thanks,

-- 
Stephen Kelly  | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
** Qt Developer Conference: http://qtconference.kdab.com/ **

signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Hausmann Simon]

Hi,

I can try to add some clarifications.

In beta2 we did the most developer-visible change with reards to the WebKit
library split by simply renaming QtWebKit to QtWebKitWidgets, which affects
.pro files and #include statements that use the module syntax.

Now we implemented a split for real, where we do have two Qt 5 C++ modules,
QtWebKit and QtWebKitWidgets. Classes like QWebView, QWebPage and
QGraphicsWebView that have intricate ties to classes from QtWidgets
consequently do live in QtWebKitWidgets and their dependencies to WebCore
internals are channeled through private API that QtWebKit exports. The QtWebKit 
C++ API
also provides classes that do not have any ties to QtWidgets but do indeed 
heavily
rely on WebCore internals, such as QWebElement or QWebSettings. These classes 
now
_remain_ in the QtWebKit C++ module.

It is our intention to make it so that when you write

QT += webkitwidgets

in your .pro file, then it should imply QT += webkit, in order to maximize
source compatibility against Qt 4. This relies on people using #include
 or #include  instead of the module syntax, but
quite frankly I don't see any point in people using the module syntax in their
applications anyway.

Now it seems that on Linux and Windows this automatic dependency seems to work,
but it does seem to break down on Mac O X with frameworks. That at least would
explain the build failure in Qt Creator where the inclusion was #include 

and the .pro file said QT += webkitwidgets but a QT += webkit was necessary to
fix the build.

Does anyone know if there is a way to make this automatic dependency also work
with Mac OS X frameworks or the way we create them in Qt?


Simon


From: development-bounces+simon.hausmann=digia@qt-project.org 
[development-bounces+simon.hausmann=digia@qt-project.org] on behalf of 
Koehne Kai [kai.koe...@digia.com]
Sent: Sunday, December 02, 2012 12:20 AM
To: Thiago Macieira; development@qt-project.org
Subject: Re: [Development] The final mile

> From: development-bounces+kai.koehne=digia@qt-project.org 
> [development-bounces+kai.koehne=digia@qt-project.org] on behalf of Thiago 
> Macieira [thiago.macie...@intel.com]
>> On segunda-feira, 19 de novembro de 2012 20.09.35, Knoll Lars wrote:
>> * WebKit library split (WebKit + WebKitWidgets)
>>
>> This is a binary incompatible change, that has to go in for 5.0. Most of the
>> QtWebKit team is working on this, and I have good confidence that the
>> change will be and done in some time next week.
>
> This has apparently created source-incompatible changes which broke the
> package generation today.

Just to clarify this a bit, we had a build failure of qt-creator today in the 
qt-sdk packaging process where the compiler failed to find a "QWebSettings" 
include, although the .pro file did include "QT += webkitwidgets". The compiler 
call did actually contain -Iinclude/QtWebKitWidgets, but not 
-Iinclude/QtWebKit. This AFAIK only happened on Mac, and we're not yet sure 
what's the root cause (and whether it's a general Qt problem, or a problem with 
the way we compile Qt Creator / patch Qt on the build machines, which is a bit 
special ...).

Regards

Kai

PS: I pushed a fix that hopefully works around the issue by explicitly adding 
"QT+=webkit". So if anybody wants to give it a try locally, first revert 
https://codereview.qt-project.org/#change,41469 in qt-creator.

> Can someone post a summary of the targetted final state?
>
> If this is introducing major source incompatible changes, I'm going to request
> a new beta instead of an RC.
___
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] The final mile

[Koehne Kai]

> From: development-bounces+kai.koehne=digia@qt-project.org 
> [development-bounces+kai.koehne=digia@qt-project.org] on behalf of Thiago 
> Macieira [thiago.macie...@intel.com]
>> On segunda-feira, 19 de novembro de 2012 20.09.35, Knoll Lars wrote:
>> * WebKit library split (WebKit + WebKitWidgets)
>>
>> This is a binary incompatible change, that has to go in for 5.0. Most of the
>> QtWebKit team is working on this, and I have good confidence that the
>> change will be and done in some time next week.
>
> This has apparently created source-incompatible changes which broke the
> package generation today.

Just to clarify this a bit, we had a build failure of qt-creator today in the 
qt-sdk packaging process where the compiler failed to find a "QWebSettings" 
include, although the .pro file did include "QT += webkitwidgets". The compiler 
call did actually contain -Iinclude/QtWebKitWidgets, but not 
-Iinclude/QtWebKit. This AFAIK only happened on Mac, and we're not yet sure 
what's the root cause (and whether it's a general Qt problem, or a problem with 
the way we compile Qt Creator / patch Qt on the build machines, which is a bit 
special ...).

Regards

Kai

PS: I pushed a fix that hopefully works around the issue by explicitly adding 
"QT+=webkit". So if anybody wants to give it a try locally, first revert 
https://codereview.qt-project.org/#change,41469 in qt-creator.

> Can someone post a summary of the targetted final state?
>
> If this is introducing major source incompatible changes, I'm going to request
> a new beta instead of an RC.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Thiago Macieira]

On segunda-feira, 19 de novembro de 2012 20.09.35, Knoll Lars wrote:
> * WebKit library split (WebKit + WebKitWidgets)
> 
> This is a binary incompatible change, that has to go in for 5.0. Most of the
> QtWebKit team is working on this, and I have good confidence that the
> change will be and done in some time next week.

This has apparently created source-incompatible changes which broke the 
package generation today.

Can someone post a summary of the targetted final state?

If this is introducing major source incompatible changes, I'm going to request 
a new beta instead of an RC.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Lorn Potter]

On 20/11/2012, at 6:20 PM, Knoll Lars  wrote:

> Hi Lorn,
> 
> On Nov 20, 2012, at 1:42 AM, Lorn Potter  wrote:
> 
>> 
>> On 20/11/2012, at 6:09 AM, Knoll Lars  wrote:
>> 
>>> 
>>> The beta2 is a very good milestone towards Qt 5. We now have packages that 
>>> include the full content of what we agreed to ship, including Qt Creator. 
>>> Also our bug numbers are looking ok, with ~50 P0 and P1 bugs left for 5.0.
>> 
>> How about re-adding QSensors for 5.0?
> 
> I'm happy to re-add them for a subsequent 5.0.x release, but please 
> understand that it's too late for 5.0.0. We have been asking publicly about 
> this on the mailing list, and since nobody raised his hand for the module, it 
> was left out.
>> 

There was no mention that this meant those modules would basically be stricken 
from git and/or the build system , and made more difficult to obtain or even 
work on these modules.
I was under the impression this only meant the release _package_, not the 
development build system.

That, and the change that actually removed these modules from the build system 
did not even seek reviews from the modules maintainers. 

So I got a rude awakening when I updated the repos, and tried my usual
make module-qtsensors.




>> I also noticed that QSensors 5 is completely missing from the docs 
>> http://qt-project.org/doc/qt-5.0/modules.html
>> 
>> QSensors not even listed as an add-on module any more.
> 
> Yes, docs are currently being generated for the modules that are included, 
> but I wouldn't mind a patch that adds a link to these as external modules. 
> Longer term, I'd prefer if we make this more modular, and we can install 
> these modules including docs on the fly.
>> 
>> Neither are any of the recently 'removed' modules/classes listed there.
>> How about listing _ALL_ of Qt/modules, regardless of maintainership or 
>> 'release' status?
> 
> The infrastructure we have currently simply makes this rather difficult. But 
> some of them simply don't even make sense to list in their current status 
> (e.g. docgallery). For the others we'd have to be very careful in listing 
> them with correct status. 
>> 
>> Especially the changes to qt.pro and init-repository make finding them very 
>> difficult, and they are then doomed into obscurity of finding no maintainer.
> 
> There's a change pending by Ossi to add them to qt5.git again. I'm ok with 
> the change in principal, but would like to avoid anything that makes it 
> harder to get 5.0.0 out just now.
>> 
>> I can understand those modules where no one is going to maintain them, but 
>> please, there are a few modules that got removed that _do_ have active 
>> maintainers, just not Digia ones. QConnectivity, QSensors and QSystems for 
>> example. 
> 
> This has *nothing* to do with Digia. Many other modules we release have 
> maintainers outside of Digia as well. It has everything to do with us asking 
> on the mailing list for commitment to support a module for 5.0.0 and not 
> getting that for these modules.

Perhaps there needs to be a maintainers email list for very important emails 
such as this that might get lost in the noise.


>> 
>> Isn't BB10 supposed to become a Tier 1 platform? QSensors are a part of BB10.
> 
> Yes. I've told you that before, I'll re-iterate it: My goal is to get Sensors 
> and some of the other modules back into the official release. We've said that 
> with modularisation, modules can have different release schedules. So adding 
> them in an update to the SDK should not be a problem.
> 
> What I would however like to see for these modules is another backend apart 
> from BB10.

There is. A basic generic, a simulator and a generic linux backend. Also a wii 
controller backend WIP.


> We're now working on Android and iOS, and it would be good if we can validate 
> that the API works for these.


Android port has been using the qtmobility sensors API for some time now. iOS 
only contains accelerometer and proximity in the public API. iOS light sensor 
is current hidden within private headers. The API does not need to be validated 
against these platforms. It will work fine.

Windows 8 has sensor API's too.


> 
> Cheers,
> Lars
> 

Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures




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

Re: [Development] The final mile

[Sergio Ahumada]

On 11/20/2012 10:01 AM, Jedrzej Nowacki wrote:
> On Monday 19. November 2012 21.09.35 Knoll Lars wrote:
>> The package creation time is currently being addressed, and hopefully we'll
>> soon be able to get that time down to around 2-3 hours (from 7-8
>> currently). In addition, I'd like to ask anybody to be careful with
>> changes that might affect packaging, and to add me and Iikka as reviewers
>> for changes where you suspect that packaging might be impacted
>
> What kind of changes may affect packaging?
>
> Cheers,
>Jędrek

Some of the ones I've seen:

- Changes to qt5.git/qt.pro
- Adding new dependencies (need to install additional packages)
- Changes in configure flags
- Compilation errors not caught by CI and showing up while packaging
- Changes that break other modules (this is only caught while trying to 
integrate qt5.git)

among others

Cheers,
-- 
Sergio Ahumada
Quality Engineer - Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Jedrzej Nowacki]

On Monday 19. November 2012 21.09.35 Knoll Lars wrote:
> The package creation time is currently being addressed, and hopefully we'll
> soon be able to get that time down to around 2-3 hours (from 7-8
> currently). In addition, I'd like to ask anybody to be careful with
> changes that might affect packaging, and to add me and Iikka as reviewers
> for changes where you suspect that packaging might be impacted

What kind of changes may affect packaging?

Cheers,
  Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] The final mile

[Knoll Lars]

Hi Lorn,

On Nov 20, 2012, at 1:42 AM, Lorn Potter  wrote:

> 
> On 20/11/2012, at 6:09 AM, Knoll Lars  wrote:
> 
>> 
>> The beta2 is a very good milestone towards Qt 5. We now have packages that 
>> include the full content of what we agreed to ship, including Qt Creator. 
>> Also our bug numbers are looking ok, with ~50 P0 and P1 bugs left for 5.0.
> 
> How about re-adding QSensors for 5.0?

I'm happy to re-add them for a subsequent 5.0.x release, but please understand 
that it's too late for 5.0.0. We have been asking publicly about this on the 
mailing list, and since nobody raised his hand for the module, it was left out.
> 
> I also noticed that QSensors 5 is completely missing from the docs 
> http://qt-project.org/doc/qt-5.0/modules.html
> 
> QSensors not even listed as an add-on module any more.

Yes, docs are currently being generated for the modules that are included, but 
I wouldn't mind a patch that adds a link to these as external modules. Longer 
term, I'd prefer if we make this more modular, and we can install these modules 
including docs on the fly.
> 
> Neither are any of the recently 'removed' modules/classes listed there.
> How about listing _ALL_ of Qt/modules, regardless of maintainership or 
> 'release' status?

The infrastructure we have currently simply makes this rather difficult. But 
some of them simply don't even make sense to list in their current status (e.g. 
docgallery). For the others we'd have to be very careful in listing them with 
correct status. 
> 
> Especially the changes to qt.pro and init-repository make finding them very 
> difficult, and they are then doomed into obscurity of finding no maintainer.

There's a change pending by Ossi to add them to qt5.git again. I'm ok with the 
change in principal, but would like to avoid anything that makes it harder to 
get 5.0.0 out just now.
> 
> I can understand those modules where no one is going to maintain them, but 
> please, there are a few modules that got removed that _do_ have active 
> maintainers, just not Digia ones. QConnectivity, QSensors and QSystems for 
> example. 

This has *nothing* to do with Digia. Many other modules we release have 
maintainers outside of Digia as well. It has everything to do with us asking on 
the mailing list for commitment to support a module for 5.0.0 and not getting 
that for these modules.
> 
> Isn't BB10 supposed to become a Tier 1 platform? QSensors are a part of BB10.

Yes. I've told you that before, I'll re-iterate it: My goal is to get Sensors 
and some of the other modules back into the official release. We've said that 
with modularisation, modules can have different release schedules. So adding 
them in an update to the SDK should not be a problem.

What I would however like to see for these modules is another backend apart 
from BB10. We're now working on Android and iOS, and it would be good if we can 
validate that the API works for these.

Cheers,
Lars

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

Re: [Development] The final mile

[Lorn Potter]

On 20/11/2012, at 6:09 AM, Knoll Lars  wrote:

> 
> The beta2 is a very good milestone towards Qt 5. We now have packages that 
> include the full content of what we agreed to ship, including Qt Creator. 
> Also our bug numbers are looking ok, with ~50 P0 and P1 bugs left for 5.0.

How about re-adding QSensors for 5.0?

I also noticed that QSensors 5 is completely missing from the docs 
http://qt-project.org/doc/qt-5.0/modules.html

QSensors not even listed as an add-on module any more.

Neither are any of the recently 'removed' modules/classes listed there.
How about listing _ALL_ of Qt/modules, regardless of maintainership or 
'release' status?

Especially the changes to qt.pro and init-repository make finding them very 
difficult, and they are then doomed into obscurity of finding no maintainer.

I can understand those modules where no one is going to maintain them, but 
please, there are a few modules that got removed that _do_ have active 
maintainers, just not Digia ones. QConnectivity, QSensors and QSystems for 
example. 

Isn't BB10 supposed to become a Tier 1 platform? QSensors are a part of BB10.



Lorn Potter
Senior Software Engineer, QtSensors/QtSensorGestures




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

[Development] The final mile

[Knoll Lars]

Hi everybody,

apart from having fantastic Qt Developer Days in Berlin, we finally managed to 
get the beta2 out last week. Many thanks to all of the people that helped make 
it happen.

The beta2 is a very good milestone towards Qt 5. We now have packages that 
include the full content of what we agreed to ship, including Qt Creator. Also 
our bug numbers are looking ok, with ~50 P0 and P1 bugs left for 5.0.

There are however also a few things left. To be able to now move quickly 
towards the release candidate and the final release, we need to be from now on 
very careful in what we stage. 

First of all I'd like to have a pretty hard API freeze from now on. Anything 
that breaks source or binary compatibility, please add me as a reviewer. If 
there's not a good reason to get them in now, I'll push all such changes to 5.1.

Packaging has been one of the biggest challenges towards getting all our 
previous releases (Alpha, B1 and B2) out. The main reasons were that the 
sources changed underneath the packages, requiring adjustments as we went 
forward, combined with a very long turn around time for package creation. 

The package creation time is currently being addressed, and hopefully we'll 
soon be able to get that time down to around 2-3 hours (from 7-8 currently). In 
addition, I'd like to ask anybody to be careful with changes that might affect 
packaging, and to add me and Iikka as reviewers for changes where you suspect 
that packaging might be impacted

With regards to bug fixing, let's focus on P0 and P1 bugs, and close as many of 
them as possible. But let's simply be realistic. Qt 5.0 will have known bugs. 
But pushing the release back would not change this, as people will always find 
new ones. It is now more important to get Qt 5.0 out to create a stable basis 
for all of us to work upon.

Apart from bug fixing, there are three more items remaining that I'd like to 
address for the RC:

* WebKit library split (WebKit + WebKitWidgets)

This is a binary incompatible change, that has to go in for 5.0. Most of the 
QtWebKit team is working on this, and I have good confidence that the change 
will be and done in some time next week.

* Documentation

While the class level docs are generally speaking pretty ok, we have so far not 
done enough on the high level documentation structure and overviews.

There was/is a large effort ongoing to restructure and modularise our docs in 
the newdocs branch(es) in gerrit. Merging that branch has been delayed to after 
beta 2, but things are starting to look ok there. I believe that we need to 
have this branch merged in to make sure we have up to date docs for Qt 5, as 
the old docs still look very much like 4.x. That merge will most likely happen 
tomorrow or on Wednesday, once we have fixed the infrastructure to generate 
decent looking web pages out of them.

However, there is still significant work still to write many overview 
documents. The team in Oslo will in the next days do an extra effort to create 
these overviews. When reviewing the first set of patches, please do mainly 
review the content, not the form or language. We'll do a second iteration over 
the docs once they are in to fixup any potential style/language issues.

We'll post some more info on this tomorrow, and I'd like to invite everybody to 
have a look at http://community.kde.org/Qt5/Documentation if you want to help.

* Examples and polishing

We currently have way too many examples to be really useful, and many of them 
are not very polished. We will be doing an extra effort to polish these and 
define a good set of examples that should be accessible from our docs and 
Creator.

In addition, we'll need to do regular package testing and check our snapshots 
from the point of view of our users, to make sure Qt 5.0 has a great out of the 
box experience.


All of this work will need to happen in the next two weeks, as we're aiming at 
having everything ready to start testing RC packages by Nov 30th. It's a pretty 
tight timeline, but if we all work together, I believe we can make it happen.

Cheers,
Lars


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