Re: [Development] Patches in JIRA (Was: (no subject))

[Craig.Scott]

On 21/12/2011, at 6:16 PM, Alan Alpert wrote:

> On Wed, 21 Dec 2011 16:52:54 ext craig.sc...@csiro.au wrote:
>> On 21/12/2011, at 5:14 PM, Robin Burchell wrote:
>>> On Wed, Dec 21, 2011 at 2:57 AM,   wrote:
 On 21/12/2011, at 12:19 PM,   
> wrote:
> Posting patches to the JIRA bugreporting system is contrary to the
> terms of use for that system.
> https://bugreports.qt.nokia.com/secure/TermsAndConditions.html Don't
> do this.
 
 I know I'll probably be shot down immediately, but.
 
 This is one of the more annoying things about the changes that have been
 going on with Qt.
>>> 
> [...]
>>> [ that having been said, I agree that it's really annoying, but I
>>> can't really see a nice method to solve this, other than possibly
>>> directing them to accept the CLA on gerrit the first time they upload
>>> a patch to JIRA, but that's going to require customisations.. and in
>>> the end, it's probably better to focus on streamlining the
>>> contribution & review process we have first ]
>> 
>> I'd actually suggest the reverse. I would hope that it would be a
>> relatively non-disruptive change to make JIRA aware of who has accepted
>> the CLA and who hasn't. It should be possible to do this without any
>> developers having to know about it. If that is done, then there are no
>> more steps required to allow anyone who wants to submit a patch to do so.
>> In contrast, getting the contribution process in place for gerrit looks
>> like more work and targets a smaller number of users (everyone could
>> submit a patch, but only those willing to learn the process would submit
>> via gerrit).
> 
> Even if it's an easy change, do we even want those patches via JIRA? For 
> trivial patches  I don't think the CLA applies anyways, for non-trivial 
> patches there needs to be discussion and code-review (and CI at the very 
> least). Gerrit is what does this for us at the moment, and it's much better 
> suited for it than JIRA. 

Yes it applies to trivial patches too (at least, I've had trivial patches 
redirected to the git merge request process in the past). I don't really see 
the down side here. You are choosing between no patch at all and a patch that 
the maintainer can choose to use or not. Nothing lost, but potentially 
something gained.

There will still be discussion and code review when whoever picks up the patch 
puts it through the gerrit system. It's not replacing the process, it's about 
giving the maintainer a more advanced starting point to fix the issue.

> 
> I can't imagine that there are many high-quality, large submissions, all 
> ready 
> to merge, from a submitter that doesn't know git/gerrit yet. If gerrit really 
> is that hard to use, wouldn't it be better (and probably easier) to fix 
> gerrit 
> than duplicate its functionality in JIRA?

It's not just gerrit, it's also git and understanding the repository structure. 
Plenty of people still like svn, for instance, and maybe their day job doesn't 
require them to know git or gerrit or the internals of Qt beyond the small bit 
they investigate for a bug that's relevant to them. I would not be so hasty as 
to assume that just because a developer hasn't worked out git/gerrir/repo 
structure, their work won't be of a high quality. The size of the submission 
isn't really important here.


--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia



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

Re: [Development] ../../bin/mkv8snapshot: No such file or directory

[kai.koehne]

> -Original Message-
> From: development-bounces+kai.koehne=nokia@qt-project.org
> [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
> Behalf Of ext Robin Burchell
> Sent: Wednesday, December 21, 2011 7:32 AM
> To: Dave Mateer
> Cc: development@qt-project.org
> Subject: Re: [Development] ../../bin/mkv8snapshot: No such file or directory
> 
> hi,
> 
> On Tue, Dec 20, 2011 at 8:59 PM, Dave Mateer
>  wrote:
> > I configured using:
> >
> >    ./configure -developer-build -prefix "." -debug -nomake examples
> > -nomake tests -no-webkit
> 
> i've not built on OS X for ages, but that -prefix looks possibly wrong to me.
> qt5/README[1] says:
> 
> ./configure -prefix $PWD/qtbase -opensource -confirm-license
> 
> (obviously, -developer-build etc you might want to tack onto that)
> 
> Where is this page? I guess it probably needs updating.

I guess it was http://developer.qt.nokia.com/wiki/Building_Qt_5_from_Git . My 
fault, I just recently changed the configure line in there to not use 
-nokia-developer. The behavior of "-prefix '.'" of course depends on the 
current working directory, so it makes a difference if you run configure inside 
qtbase, or in the parent directory. Anyway, -developer-build is all that is 
needed, I changed the wiki accordingly ...
 
> [1]: https://qt.gitorious.org/qt/qt5/blobs/master/README
> ___
> 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] Patches in JIRA (Was: (no subject))

[Alan Alpert]

On Wed, 21 Dec 2011 16:52:54 ext craig.sc...@csiro.au wrote:
> On 21/12/2011, at 5:14 PM, Robin Burchell wrote:
> > On Wed, Dec 21, 2011 at 2:57 AM,   wrote:
> >> On 21/12/2011, at 12:19 PM,   
wrote:
> >>> Posting patches to the JIRA bugreporting system is contrary to the
> >>> terms of use for that system.
> >>> https://bugreports.qt.nokia.com/secure/TermsAndConditions.html Don't
> >>> do this.
> >> 
> >> I know I'll probably be shot down immediately, but.
> >> 
> >> This is one of the more annoying things about the changes that have been
> >> going on with Qt.
> > 
[...]
> > [ that having been said, I agree that it's really annoying, but I
> > can't really see a nice method to solve this, other than possibly
> > directing them to accept the CLA on gerrit the first time they upload
> > a patch to JIRA, but that's going to require customisations.. and in
> > the end, it's probably better to focus on streamlining the
> > contribution & review process we have first ]
> 
> I'd actually suggest the reverse. I would hope that it would be a
> relatively non-disruptive change to make JIRA aware of who has accepted
> the CLA and who hasn't. It should be possible to do this without any
> developers having to know about it. If that is done, then there are no
> more steps required to allow anyone who wants to submit a patch to do so.
> In contrast, getting the contribution process in place for gerrit looks
> like more work and targets a smaller number of users (everyone could
> submit a patch, but only those willing to learn the process would submit
> via gerrit).

Even if it's an easy change, do we even want those patches via JIRA? For 
trivial patches  I don't think the CLA applies anyways, for non-trivial 
patches there needs to be discussion and code-review (and CI at the very 
least). Gerrit is what does this for us at the moment, and it's much better 
suited for it than JIRA. 

I can't imagine that there are many high-quality, large submissions, all ready 
to merge, from a submitter that doesn't know git/gerrit yet. If gerrit really 
is that hard to use, wouldn't it be better (and probably easier) to fix gerrit 
than duplicate its functionality in JIRA?

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] (no subject)

[Craig.Scott]

On 21/12/2011, at 5:14 PM, Robin Burchell wrote:

> On Wed, Dec 21, 2011 at 2:57 AM,   wrote:
>> 
>> On 21/12/2011, at 12:19 PM,   
>> wrote:
>> 
>>> Posting patches to the JIRA bugreporting system is contrary to the terms of 
>>> use for that system.
>>> https://bugreports.qt.nokia.com/secure/TermsAndConditions.html
>>> Don't do this.
>> 
>> I know I'll probably be shot down immediately, but.
>> 
>> This is one of the more annoying things about the changes that have been 
>> going on with Qt.
> 
> This isn't new. Ever since I've been wanting to submit patches, pretty
> much, JIRA - at least officially - hasn't been an option for legal
> reasons, because it bypasses the CLA. The CLA is the primary reason
> why patches can't be accepted from other sources, as far as I
> understand it.

I've hit that wall too with patches I submitted. Even if you've accepted the 
CLA though, your patches still are not accepted via JIRA, which is annoying 
since it's really just a book keeping problem at that point. All the legal 
stuff is settled (you've accepted the CLA) but how does JIRA know that when you 
try to upload a patch? How does an issue assignee know that the patch you've 
provided is legally safe for them to incorporate into Qt? It would be great if 
someone knew of a way to mark users as having accepted the CLA or not and only 
allowing them to upload patches if they had accepted it. Maybe even go so far 
as having to accept the CLA for uploading any attachment to a bug, but that 
might be annoying for people who just want to report a bug with a screenshot 
but not also contribute a fix (and I'd expect there would be a non-trivial 
number of people wanting to do that). Any JIRA ninjas on the list who have 
ideas for how this could be done?


> 
> [ that having been said, I agree that it's really annoying, but I
> can't really see a nice method to solve this, other than possibly
> directing them to accept the CLA on gerrit the first time they upload
> a patch to JIRA, but that's going to require customisations.. and in
> the end, it's probably better to focus on streamlining the
> contribution & review process we have first ]


I'd actually suggest the reverse. I would hope that it would be a relatively 
non-disruptive change to make JIRA aware of who has accepted the CLA and who 
hasn't. It should be possible to do this without any developers having to know 
about it. If that is done, then there are no more steps required to allow 
anyone who wants to submit a patch to do so. In contrast, getting the 
contribution process in place for gerrit looks like more work and targets a 
smaller number of users (everyone could submit a patch, but only those willing 
to learn the process would submit via gerrit).

Don't get me wrong, the contribution and review process is a great idea. What 
I'd really like to see though is the ability for the average developer to 
submit a patch to JIRA and for the maintainer to be able to then merge in the 
patch if they are happy with it. The alternative is that the patch is not 
submitted at all and the maintainer has to come up with the patch themselves. 
If you are worried that the maintainer would get overloaded with patches, well 
they can always ignore them until they are ready to deal with them - this is no 
different to the patches not having been submitted in the first place, which is 
what the current situation will result in anyway.

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia



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

Re: [Development] ../../bin/mkv8snapshot: No such file or directory

[Robin Burchell]

hi,

On Tue, Dec 20, 2011 at 8:59 PM, Dave Mateer  wrote:
> I configured using:
>
>    ./configure -developer-build -prefix "." -debug -nomake examples
> -nomake tests -no-webkit

i've not built on OS X for ages, but that -prefix looks possibly wrong
to me. qt5/README[1] says:

./configure -prefix $PWD/qtbase -opensource -confirm-license

(obviously, -developer-build etc you might want to tack onto that)

Where is this page? I guess it probably needs updating.

[1]: https://qt.gitorious.org/qt/qt5/blobs/master/README
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Deprecation of qMalloc/qFree/qRealloc

[Robin Burchell]

Hi,

I've submitted two changes last night:
- http://codereview.qt-project.org/#change,11562 - deprecating
qMalloc/qFree/qRealloc
- http://codereview.qt-project.org/#change,11563 - removing all uses
of them from QtBase

My justification for this change is pretty simple - the only real
reason to have these as far as I know is that it makes it possible to
swap out memory allocation across Qt, but, there are usually other
ways to accomplish this as the commit message notes, and it's rather
unfair to impose an additional function call on all uses of these for
something which isn't used in the majority of cases.

Once these changes go in, I'm happy to submit changes (if any) to other modules.

Thanks,

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

Re: [Development] (no subject)

[Robin Burchell]

On Wed, Dec 21, 2011 at 2:57 AM,   wrote:
>
> On 21/12/2011, at 12:19 PM,   wrote:
>
>> Posting patches to the JIRA bugreporting system is contrary to the terms of 
>> use for that system.
>> https://bugreports.qt.nokia.com/secure/TermsAndConditions.html
>> Don't do this.
>
> I know I'll probably be shot down immediately, but.
>
> This is one of the more annoying things about the changes that have been 
> going on with Qt.

This isn't new. Ever since I've been wanting to submit patches, pretty
much, JIRA - at least officially - hasn't been an option for legal
reasons, because it bypasses the CLA. The CLA is the primary reason
why patches can't be accepted from other sources, as far as I
understand it.

[ that having been said, I agree that it's really annoying, but I
can't really see a nice method to solve this, other than possibly
directing them to accept the CLA on gerrit the first time they upload
a patch to JIRA, but that's going to require customisations.. and in
the end, it's probably better to focus on streamlining the
contribution & review process we have first ]
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] (no subject)

[Craig.Scott]

On 21/12/2011, at 12:19 PM,   wrote:

> Posting patches to the JIRA bugreporting system is contrary to the terms of 
> use for that system.
> https://bugreports.qt.nokia.com/secure/TermsAndConditions.html
> Don't do this.

I know I'll probably be shot down immediately, but.

This is one of the more annoying things about the changes that have been going 
on with Qt. Previously, it was enough to understand how to build Qt from 
source, then find the bugs that are affecting you and contribute a fix via 
posting it to JIRA. Granted, someone else would have to merge in that code into 
Qt and make sure it went through all the CI systems, etc., but for the average 
developer, this arrangement was not a significant barrier to helping fix things 
that were broken. With the new system, we are asking such people to learn a 
whole lot more just to get their patch submitted for someone to even look at. 
Previously, you could download a source tarball and that was about as hard as 
it got. With the new system, you need to be conversant with git and gerrit, 
plus understand the repository structure. These are barriers that probably mean 
higher quality contributions, but they also filter out the efforts of those who 
do not have the time or are not willing to learn the new
  things.

I think the all-or-nothing nature of this shift is unfortunate and I'd really 
encourage some thought on how we might be able to accept patches from people 
who are willing to do the work to find and fix bugs (that's the real value 
here, remember), but not necessarily to also put in the time to work out how to 
use the new infrastructure. I'm sure plenty of people (most?) on this list are 
happy with the new system, but I for one am concerned at just how much more 
complicated it is now to get a relatively simple patch incorporated if you are 
an average developer. I'm sure processes and documentation will likely be 
streamlined as we all move forward, but let's also be aware that we are losing 
some useful contributors as well.



> 
> -Original Message-
> From: development-bounces+mark.keir=nokia@qt-project.org 
> [mailto:development-bounces+mark.keir=nokia@qt-project.org] On Behalf Of 
> ext Dave Mateer
> Sent: Tuesday, December 20, 2011 11:59 PM
> To: development@qt-project.org
> Subject: [Development] (no subject)
> 
> I have several patches to Qt4 that I have posted on the bug tracker. Now that 
> the new contribution model is in place, I wanted to submit those as patches.
> I'm not very familiar with git (we use SVN), and am having trouble at the 
> following step on the "Qt Contributions Guidelines" page:
> 
>   > Qt 4: Add a git remote called "gerrit" in your cloned repository, which
>   > points to the Qt 4 project on codereview.qt-project.org. Note there is
>   > currently no Qt 4 reviews on codereview.qt-project.org so proposals should
>   > still go to Gitorious.
> 
> I have absolutely no idea what that means. I looked through the git manual 
> and think I see how to create a remote, but I am not sure what to put as the 
> target. I do not see any Qt4 project on the codereview site, only Qt5.
> 
> Could someone please explain what the above statement means and perhaps just 
> include the git command I need to run to fulfill the requirement?
> 
> Thanks!
> 
> Dave
> ___
> 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

--
Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia



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

Re: [Development] (no subject)

[mark.keir]

Posting patches to the JIRA bugreporting system is contrary to the terms of use 
for that system.
https://bugreports.qt.nokia.com/secure/TermsAndConditions.html
Don't do this.

-Original Message-
From: development-bounces+mark.keir=nokia@qt-project.org 
[mailto:development-bounces+mark.keir=nokia@qt-project.org] On Behalf Of 
ext Dave Mateer
Sent: Tuesday, December 20, 2011 11:59 PM
To: development@qt-project.org
Subject: [Development] (no subject)

I have several patches to Qt4 that I have posted on the bug tracker. Now that 
the new contribution model is in place, I wanted to submit those as patches.
I'm not very familiar with git (we use SVN), and am having trouble at the 
following step on the "Qt Contributions Guidelines" page:

  > Qt 4: Add a git remote called "gerrit" in your cloned repository, which
  > points to the Qt 4 project on codereview.qt-project.org. Note there is
  > currently no Qt 4 reviews on codereview.qt-project.org so proposals should
  > still go to Gitorious.

I have absolutely no idea what that means. I looked through the git manual and 
think I see how to create a remote, but I am not sure what to put as the 
target. I do not see any Qt4 project on the codereview site, only Qt5.

Could someone please explain what the above statement means and perhaps just 
include the git command I need to run to fulfill the requirement?

Thanks!

Dave
___
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] ../../bin/mkv8snapshot: No such file or directory

[Dave Mateer]

I'm attempting to build Qt5 on Mac OS X 10.6.8 to submit some patches.
I am following the instructions on the "Building Qt 5 from Git" page,
but am getting stuck on a build error.

I configured using:

./configure -developer-build -prefix "." -debug -nomake examples
-nomake tests -no-webkit

Here is the tail of my output from `make`:

g++ -c -pipe -fconstant-cfstrings -O2 -w -fvisibility=hidden
-fvisibility-inlines-hidden -arch x86_64 -Xarch_x86_64
-mmacosx-version-min=10.5 -fPIC -DQT_SHARED -DQT_NO_WAYLAND
-DQT_NO_XCB -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DV8_SHARED
-DBUILDING_V8_SHARED -DENABLE_DEBUGGER_SUPPORT
-DENABLE_VMSTATE_TRACKING -DENABLE_LOGGING_AND_PROFILING -DNDEBUG
-DV8_TARGET_ARCH_X64 -DQT_NO_DEBUG -DQT_HAVE_MMX -DQT_HAVE_3DNOW
-DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_HAVE_SSE3
-DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1 -DQT_HAVE_SSE4_2
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/macx-g++ -I.
-I../../include -I.rcc/debug-shared -I../3rdparty/v8/src
-I.moc/release-shared -o .obj/release-shared/libraries.o
generated-release/libraries.cpp
g++ -c -pipe -fconstant-cfstrings -O2 -w -fvisibility=hidden
-fvisibility-inlines-hidden -arch x86_64 -Xarch_x86_64
-mmacosx-version-min=10.5 -fPIC -DQT_SHARED -DQT_NO_WAYLAND
-DQT_NO_XCB -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS
-DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DV8_SHARED
-DBUILDING_V8_SHARED -DENABLE_DEBUGGER_SUPPORT
-DENABLE_VMSTATE_TRACKING -DENABLE_LOGGING_AND_PROFILING -DNDEBUG
-DV8_TARGET_ARCH_X64 -DQT_NO_DEBUG -DQT_HAVE_MMX -DQT_HAVE_3DNOW
-DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_HAVE_SSE3
-DQT_HAVE_SSSE3 -DQT_HAVE_SSE4_1 -DQT_HAVE_SSE4_2
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/macx-g++ -I.
-I../../include -I.rcc/debug-shared -I../3rdparty/v8/src
-I.moc/release-shared -o .obj/release-shared/experimental-libraries.o
generated-release/experimental-libraries.cpp
../../bin/mkv8snapshot generated-release/snapshot.cpp
make[3]: ../../bin/mkv8snapshot: No such file or directory
make[3]: *** [generated-release/snapshot.cpp] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [release-all] Error 2
make[1]: *** [sub-v8-make_default-ordered] Error 2
make: *** [module-qtbase-make_default] Error 2
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLatin1Constant and QtContacts / QtOrganizer

[Thiago Macieira]

On Tuesday, 20 de December de 2011 15.57.21, Robin Burchell wrote:
> On Tue, Dec 20, 2011 at 3:54 PM, Harald Fernengel
>
>  wrote:
> > I thought about optimizing ::fromUtf8, but since we need to iterate
> > character by character to convert the char* to utf16, the length of the
> > string should be rather irrelevant?
>
> having the length would at least allow you to semi-sensibly reserve()
> a size that's at least close to what the utf16 size would be, though,
> wouldn't it?

Yes. A UTF-8 encoded string is always the same length or longer than the UCS-4
or UTF-16 string, just as the UTF-16 one is the same length or longer than the
UCS-4 one.

Having the length allows us to do one malloc only. Without it, we'll need to
realloc several times to grow.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] QLatin1Constant and QtContacts / QtOrganizer

[Robin Burchell]

On Tue, Dec 20, 2011 at 3:54 PM, Harald Fernengel
 wrote:
> I thought about optimizing ::fromUtf8, but since we need to iterate character
> by character to convert the char* to utf16, the length of the string should be
> rather irrelevant?

having the length would at least allow you to semi-sensibly reserve()
a size that's at least close to what the utf16 size would be, though,
wouldn't it?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QLatin1Constant and QtContacts / QtOrganizer

[Harald Fernengel]

Hi,

On Tuesday 20 December 2011 15:41:46 ext Thiago Macieira wrote:
> On Tuesday, 20 de December de 2011 13.37.54, harald.fernen...@nokia.com 
wrote:
> > Hi,
> > 
> > > The difference is that QLatin1String will make an inline call to
> > > strlen(latin1data), which the compiler may be able to optimise. Then
> > > again, we could make the same in QString::fromLatin1... any takers?
> > 
> > review?
> > 
> > http://codereview.qt-project.org/#change,11530
> 
> Done. The same could be done for QString::fromUtf8.

I thought about optimizing ::fromUtf8, but since we need to iterate character 
by character to convert the char* to utf16, the length of the string should be 
rather irrelevant?

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

Re: [Development] QLatin1Constant and QtContacts / QtOrganizer

[Harald Fernengel]

Hi,

On Tuesday 20 December 2011 13:17:20 ext Thiago Macieira wrote:
> The difference is that QLatin1String will make an inline call to
> strlen(latin1data), which the compiler may be able to optimise. Then again,
> we could make the same in QString::fromLatin1... any takers?

http://codereview.qt-project.org/#change,11530

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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Thiago Macieira]

On Tuesday, 20 de December de 2011 15.22.13, David Faure wrote:
> On Tuesday 20 December 2011 11:18:21 lars.kn...@nokia.com wrote:
> > To some extent Linux distributions have always done that as well, and I
> > still remember something called qt-copy in KDEŠ ;-)
>
> I see no relation at all. qt-copy was for the convenience of kde developers,
> definitely not for anyone else to build upon.
> And, there was nobody selling support for it, either.
>
> And, there was a #define to distinguish it from upstream qt, allowing ifdefs
> if necessary.

That's still a "vendor branch". Anything that is not the pristine releases the
Qt Project makes is a vendor branch. If you make the sources available for
others, you should make it clear that the sources are modified. The GPL and
LGPL require that anyway.

The extent of the "making it clear" of course depends on how well known your
branch is, how many changes and how likely it is for people to use them.
Adding a patch or two to fix bugs, probably doesn't need much. Putting on an
SCM server where hundreds or thousands of people will use, required READMEs,
#defines, etc. Selling commercial support and licenses, more so -- even the
logos are changed.

Linux distributions patching Qt should also do that, but then again, they
patch all their software, so it's not like we wouldn't know.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] QLatin1Constant and QtContacts / QtOrganizer

[Thiago Macieira]

On Tuesday, 20 de December de 2011 13.37.54, harald.fernen...@nokia.com wrote:
> Hi,
>
> > The difference is that QLatin1String will make an inline call to
> > strlen(latin1data), which the compiler may be able to optimise. Then
> > again, we could make the same in QString::fromLatin1... any takers?
>
> review?
>
> http://codereview.qt-project.org/#change,11530

Done. The same could be done for QString::fromUtf8.

I have some thoughts on improving the conversion code, as we've said before we
wanted the QString "const char*" methods to convert using UTF-8 instead of
Qt2-compat fromAscii. If we do that, those methods should be inlined as well
so the string length could be calculated by the compiler.

Also note that C++11's u8"Literal string" produces a "const char *". There is
no char type for UTF-8, like UTF-16 and UTF-32.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Qt Commercial 4.8.0 release delta to LGPL version

[David Faure]

On Tuesday 20 December 2011 11:18:21 lars.kn...@nokia.com wrote:
> On 12/16/11 8:37 PM, "ext David Faure"  wrote:
> >On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote:
> >> So now there is total of 108 improvements and bug fixes available in Qt
> >> Commercial 4.8.0 that are not part of the LGPL release.
> >
> >While I understand the reasons, I want to state that this is going to
> >make
> >support a mess.
> >
> >Both versions are called 4.8.0, but do not contain the same code.
> >
> >So when someone says "With Qt-4.8.0 I have the following issue", it will
> >never
> >be clear which 4.8.0 this is about, we'll have to educate everyone to say
> >in
> >addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't the version
> >number be different, when the code is different, instead? E.g. 4.8.0c.
> >That
> >doesn't fit into the numerical QT_VERSION, but at least qmake -query and
> >every
> >other location which shows a qt version number (packages, qt creator,
> >etc.)
> >would show clearly 4.8.0c instead of 4.8.0.
> 
> To some extent Linux distributions have always done that as well, and I
> still remember something called qt-copy in KDEŠ ;-)

I see no relation at all. qt-copy was for the convenience of kde developers, 
definitely not for anyone else to build upon.
And, there was nobody selling support for it, either.

And, there was a #define to distinguish it from upstream qt, allowing ifdefs if 
necessary.

-- 
David Faure | david.fa...@kdab.com | KDE/Qt Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions

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

Re: [Development] V8's location

[Stephen Kelly]

On Monday, December 12, 2011 10:30:31 you wrote:
> Stephen Kelly said:
> > On Wednesday, November 09, 2011 13:54:37 Thiago Macieira wrote:
> > > On Friday, 28 de October de 2011 12:38:38 lars.kn...@nokia.com wrote:
> > > > We've been moving this lib quite a bit already. If we move it
> > > > again, I'd prefer it would end up at it's final location. The
> > > > move was done before we had the decision to keep QtCore
> > > > independent of V8 and to separate the QJS* classes and the QML
> > > > engine into it's own module.
> > > > 
> > > > With the above decision it might make sense to move V8, the QJS*
> > > > classes and the QML engine all into the same shared library.
> > > > 
> > > > Kent & Aaron, any thoughts?
> > > 
> > > Since they don't seem to have an opinion, can we please move it to
> > > top-level inside qt5.git?
> > > 
> > > I've just caught a bad commit in my tree that updates the commit
> > > link to v8 and I'm trying to fix it with an interactive rebase.
> > 
> > Bump. This is a recurring problem with newcomers trying to build qtbase.
> > They don't know to do the git submodule magic or use -no-v8, so the
> > build fails.
> I think this can be easily mitigated by having qmake check if the
> sources exist, rather than simply assuming that they do.
> e.g. http://codereview.qt-project.org/10934 .

This apparently didn't work. 

At least, I've just had someone else fail to build Qt because 

./configure -nomake examples -nomake demos -nomake tests  -opensource -
confirm-license

failed to create a top-level Makefile. People don't read error messages that 
don't terminate the script and that still leave this message at the end:

Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into /usr/local/Qt-5.0.0

If v8 is to remain a submodule of qtbase (I still don't see why), and you want 
to make ./configure report an error, you'll have to terminate the script when 
you encounter the error and make sure not to print a message saying 'Just run 
make'.

Especially because the current error message is still output when -no-v8 *is* 
used.

https://bugreports.qt.nokia.com/browse/QTBUG-23206

So the person seeing the error message has to know whether they can ignore it 
or not. Not useful. Rather than fix the script, it's probably easier to just 
remove the submodule and fix all the problems associated with it at once.

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

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] (no subject)

[Frans Klaver]

>> Could someone please explain what the above statement means and perhaps just
>> include the git command I need to run to fulfill the requirement?
>
> To add remotes, you want something like:
>  git remote add nameofremote gitrepourl
> for instance,
>  git remote add github_backup g...@github.com:rburchell/foo.git
>  git push github_backup master
>
> would add a new remote to my current repository, and sync the 'master'
> branch up to it

You might also want to read through the git community book[1] at
times. It's quite useful in getting you going on git.

[1]http://book.git-scm.com/index.html
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] (no subject)

[Robin Burchell]

Hi Dave,

Welcome! Enjoy your stay. :)

On Tue, Dec 20, 2011 at 2:59 PM, Dave Mateer  wrote:
> I have absolutely no idea what that means. I looked through the git manual and
> think I see how to create a remote, but I am not sure what to put as the
> target. I do not see any Qt4 project on the codereview site, only Qt5.

As the comment implies - for the moment, Qt 4 isn't in gerrit, only Qt
5. There are hopes to change this in the near future, as is being
discussed on the list at the moment
(http://lists.qt-project.org/pipermail/development/2011-December/000908.html).
I'd personally recommend waiting a few days and seeing what the
outcome of that discussion is, if you still want to target Qt 4.

> Could someone please explain what the above statement means and perhaps just
> include the git command I need to run to fulfill the requirement?

To add remotes, you want something like:
  git remote add nameofremote gitrepourl
for instance,
  git remote add github_backup g...@github.com:rburchell/foo.git
  git push github_backup master

would add a new remote to my current repository, and sync the 'master'
branch up to it
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] (no subject)

[Jonas M. Gastal]

On Tuesday 20 December 2011 08:59:25 Dave Mateer wrote:
> I have several patches to Qt4 that I have posted on the bug tracker. Now
> that the new contribution model is in place, I wanted to submit those as
> patches. I'm not very familiar with git (we use SVN), and am having trouble
> at the following step on the "Qt Contributions Guidelines" page:
> 
>   > Qt 4: Add a git remote called "gerrit" in your cloned repository, which
>   > points to the Qt 4 project on codereview.qt-project.org. Note there is
>   > currently no Qt 4 reviews on codereview.qt-project.org so proposals
> should > still go to Gitorious.
> 
> I have absolutely no idea what that means. I looked through the git manual
> and think I see how to create a remote, but I am not sure what to put as
> the target. I do not see any Qt4 project on the codereview site, only Qt5.
> 
> Could someone please explain what the above statement means and perhaps just
> include the git command I need to run to fulfill the requirement?
> 
> Thanks!
> 
> Dave
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Qt4 is currently not in gerrit. I think what you need to do is create a 
gitorious clone, push your changes to it and then create a merge request.

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

[Development] (no subject)

[Dave Mateer]

I have several patches to Qt4 that I have posted on the bug tracker. Now that
the new contribution model is in place, I wanted to submit those as patches.
I'm not very familiar with git (we use SVN), and am having trouble at the
following step on the "Qt Contributions Guidelines" page:

  > Qt 4: Add a git remote called "gerrit" in your cloned repository, which
  > points to the Qt 4 project on codereview.qt-project.org. Note there is
  > currently no Qt 4 reviews on codereview.qt-project.org so proposals should
  > still go to Gitorious.

I have absolutely no idea what that means. I looked through the git manual and
think I see how to create a remote, but I am not sure what to put as the
target. I do not see any Qt4 project on the codereview site, only Qt5.

Could someone please explain what the above statement means and perhaps just
include the git command I need to run to fulfill the requirement?

Thanks!

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

Re: [Development] QLatin1Constant and QtContacts / QtOrganizer

[harald.fernengel]

Hi,

> The difference is that QLatin1String will make an inline call to
> strlen(latin1data), which the compiler may be able to optimise. Then again, we
> could make the same in QString::fromLatin1... any takers?

review?

http://codereview.qt-project.org/#change,11530

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

Re: [Development] Feature freeze date?

[Stephen Kelly]

On Thursday, December 15, 2011 06:40:35 lars.kn...@nokia.com wrote:
> Hi everybody,
> 
> sorry for not answering earlier. I actually wanted to bring the topic up
> myself, but just didn't get it out so far. I've simply been traveling a
> bit too much (I'm currently in Tokyo for the local Qt Developer event,
> after we had a great one in Beijing two days ago with round 1100
> participants).
> 
> So let me try to summarize my thoughts on the the feature freeze date,
> what it means and how to move from there.
> 
> The feature requirements wiki page is a great initiative. But as Thiago
> said: let's really limit it to the things that can't be done in 5.1. If a
> it's something that can be done in a binary compatible way, it should not
> be on the list.

As far as I know, nothing on the list so far could be in 5.1 (except maybe 
Q_GLOBAL_STATIC - that was undocumented in Qt4 so it's 'new' API anyway).

https://wiki.qt-project.org/5.0_Feature_Targets

Even saying that though, I am certain that the list is incomplete.

One thing that comes to mind is relying on ICU for unicode and locale data, 
which was brought up on the mailing list but is not on the wiki. json support 
is another, but as new API that could go into 5.1. They're just things that 
you recently brought up, but I'm certain other people have features they want 
that can not go into 5.1 (is there on going event dispartcher work? Does 
declarative want to have a synchronous schedule with Qt base for the 5.0 
release?).

And if they don't get in before feature freeze (eg the new QUrl, json support, 
ref counted quit), then we simply do without them for Qt5 just like we did 
without them in Qt4.

> 
> Once we have the list, let's go through it and do some estimations of what
> it requires. But let's avoid falling into the trap of requiring a perfect
> world/solution. No matter how much time we give ourselves, we won't be
> able to do everything we maybe would like to do, and we'll have to cut of
> at some point.

Yes. We would need to actually have a target list before we can know what is 
not going to make the target though and what is unrealistic.

> It doesn't make sense to freeze BC before the final 5.0.0 release, so
> let's not do that. As long as your change is source compatible, we can do
> binary incompatible changes almost until the end.

I think it depends on whether a set of new virtual methods create a 
significany part of the API, but yes, that's more covered by API freeze than 
BC freeze anyway, so not freezing BC before 5.0.0 sounds good.

> 
> 
> I believe we need to stick with the feature freeze timeline by end of
> January. I know that this hasn't been a huge amount of time for externals
> to get their changes in, but we have finished most of the fundamental
> changes that were needed for 5.0. Jan 31st is a Tuesday, so my proposal
> would be Feb 3rd.

I believe we need to enumerate the targets before we schedule a freeze. 
Scheduling it before knowing what is targetted and whether it's a plausible 
target is only going to lead to people trying to rush the feature in or things 
like 'Just +2 it so that it gets in before freeze. We can fix it later', which 
would run counter to the reason for having a freeze anyway. 

We need to have feature targets before scheduling feature freeze.

I actually think I can meet my targets personally, but I don't want to work to 
the bone to get it done and then have others break freeze for things that they 
bring up in mid February 'because we need it'.

> I also still believe strongly that we need to aim for a Qt 5.0 release by
> next Summer. It is important that we get 5.0 out as fast as we can to
> establish a new baseline for Qt development. If we want to be able to keep
> that date we need to start freezing things soon.

Sure. But we can't just say 'soon' and pick an arbitrary date without knowing 
what we're targetting.

Should we also send a message that everyone should prefer to work on things 
that can only go into 5.0 and can not go into 5.1 to prioritize that? (such as 
the json APIs).

> In case you feel there is a change that *has* to go into 5.0, but that you
> think you'll not be able to finish until the feature freeze I'd like
> people to speak up on this list as soon as possible and we'll then figure
> out how to handle them.

Not only if you think you won't make the freeze deadline, but if you still 
have features you want to integrate, please put them on the wiki.


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

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] Qt Commercial 4.8.0 release delta to LGPL version

[marius.storm-olsen]

On 12/20/2011 06:10 AM, ext Sergio Ahumada wrote:
>> Unfortunately moving it into gerrit is not as easy as one might think as
>> the testing infrastructure is somewhat different between Qt 4.x and Qt 5.
>> We could move Qt 4.x into gerrit very fast, but would loose the CI on it.
>> If we want to keep CI, there's some work that needs to happen first.
>> Sergio and Rohan know the details here.
>>
>> Cheers,
>> Lars
>
> Basically we need to integrate (or something like it):
>
> http://codereview.qt-project.org/9872
> http://codereview.qt-project.org/11460
> http://codereview.qt-project.org/11462
>
> and we need to make the tests to pass or mark them as insignificant (I
> already have a patch for this).
>
> We have some other options (to start with, improving over time):
>
> - No CI et al, direct submit [1] =>  now
>
> - CI with some platforms (linux, windows, mac) enforcing compilation
> only =>  a week ?
>
> - CI with some platforms (linux, windows, mac) enforcing compilation and
> autotests = couple of weeks ?
>
> - CI with the current platforms in enforcing mode (macosx 10.6, macosx
> 10.7, winxp msvc2008, win7 msvc2008, win7 msvc2010, linux g++, linux
> icc) =>  months ?


I really don't want 4.x out there without *anything*, so lets skip the 
step with direct submits. We don't do it for Qt 5, so we definitely 
shouldn't do it for Qt 4.

I think we could go ahead with a multi-phase process though.

So, we'd start with enforcing compilation on the desktop platforms, 
which means ~1 weeks worth of work to get it migrated and up and running 
with CC (Continuous Compilation ;)

Then 1 week later we can add the autotests too, so we get CI.

Then, as we are able to adapt the other platforms, we add them when they 
are available until we cover all the platforms we have currently for Qt 4.

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

Re: [Development] QLatin1Constant and QtContacts / QtOrganizer

[Thiago Macieira]

On Monday, 19 de December de 2011 23.08.11, Mathias Hasselmann wrote:
> +1 - QLatin1String is painful to use: You cannot really store references
> to it, you constantly get trouble from C++ not being able to resolve
> which of its cast operators shall be used (QString vs. QLatin1String).
> Also I never really got is purpose: To enable comparison and hashing of
> QtContact's string keys, and to make sure those strings don't waste
> memory on heap, it would have been sufficient to use QString::
> fromRawData() to initialize those constants.

When to use:

QString::fromRawData:

* You already have the data in UTF-16 format
* You can guarantee that the lifetime of said data is longer than the lifetime
of the QString and all its implicit copies

QLatin1String:

* Your string is in Latin 1 (if your source code is in UTF-8, then your string
is in US-ASCII)
* You're calling a method in QString that *does* have a QLatin1String overload
* And it's not the QString constructor

QStringLiteral:

* It's a string literal in your source code (it MUST be a literal)
* You're going to use it where only a QString serves, like calling methods
that take QString or you're creating a QString object

QString::fromXXX and QTextCodec::toUnicode:

* All other cases where either the encoding doesn't match above and you need
to create a QString copy.


You could use QLatin1String with a non-literal in the same way you'd use
QString::fromRawData.

That is, such as this:

QString str = QString::fromLatin1(latin1data);
QString str = QLatin1String(latin1data);

The difference is that QLatin1String will make an inline call to
strlen(latin1data), which the compiler may be able to optimise. Then again, we
could make the same in QString::fromLatin1... any takers?


Do not do this:

if (str == QStringLiteral("latin 1 string literal"))
reason: QStringLiteral takes strlen(data) + 18 bytes more space
use: QLatin1String

str = QString::fromLatin1("%1 %2").arg(foo, bar);
reason: QString::fromLatin1 will need to allocate memory
use: QStringLiteral

QImage f(QLatin1String("foo.png"));
reason: will allocate memory for something that doesn't change
use: QStringLiteral

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


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] Qt Commercial 4.8.0 release delta to LGPL version

[Sergio Ahumada]

>> So anyway, the summary of my thoughts on solving this would be:
>> - get 4.x into Gitorious ASAP
>> - get the changes into 4.x (can probably be ongoing while the above
>> isn't finished, but will be helped)
>> - cherry-pick them into Qt 5 (in any way possible) to make sure work
>> isn't lost or duplicated, since I assume that your customers will be
>> asking about Qt 5 sooner rather than later :)
>>
>> ...and we're back to working as one big, happy family in Gerrit :)
>
> Yes, that's the plan, except that we'll get 4.x into gerrit instead of
> gitorious ;-)
>
> Unfortunately moving it into gerrit is not as easy as one might think as
> the testing infrastructure is somewhat different between Qt 4.x and Qt 5.
> We could move Qt 4.x into gerrit very fast, but would loose the CI on it.
> If we want to keep CI, there's some work that needs to happen first.
> Sergio and Rohan know the details here.
>
> Cheers,
> Lars

Hi,

Basically we need to integrate (or something like it):

http://codereview.qt-project.org/9872
http://codereview.qt-project.org/11460
http://codereview.qt-project.org/11462

and we need to make the tests to pass or mark them as insignificant (I 
already have a patch for this).

We have some other options (to start with, improving over time):

- No CI et al, direct submit [1] => now

- CI with some platforms (linux, windows, mac) enforcing compilation 
only => a week ?

- CI with some platforms (linux, windows, mac) enforcing compilation and 
autotests = couple of weeks ?

- CI with the current platforms in enforcing mode (macosx 10.6, macosx 
10.7, winxp msvc2008, win7 msvc2008, win7 msvc2010, linux g++, linux 
icc) => months ?

Cheers,

[1]: those who agree then will have to step up and fix the failures when 
the CI comes back online :)
-- 
Sergio Ahumada
Mobile Phones Middleware - Quality Engineering
http://wikis.in.nokia.com/QtQualityEngineering
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[André Pönitz]

On Tuesday 20 December 2011 12:25:32 ext lars.kn...@nokia.com wrote:
> Unfortunately moving it into gerrit is not as easy as one might think as
> the testing infrastructure is somewhat different between Qt 4.x and Qt 5.
> We could move Qt 4.x into gerrit very fast, but would loose the CI on it.

Losing CI for a while seems to be a reasonable price for a quick move to
gerrit. There was a long phase without in the past already, and it's not
the Qt didn't work back then...

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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Turunen Tuukka]

On 20.12.2011 13.25, "lars.kn...@nokia.com"  wrote:

>On 12/16/11 6:16 AM, "ext Robin Burchell"  wrote:
>
>>Hi Tuukka,
>>
>>(now that I've left some hours to digest this...)
>>
>>2011/12/15 Turunen Tuukka :
>>> So now there is total of 108 improvements and bug fixes available in Qt
>>> Commercial 4.8.0 that are not part of the LGPL release. I want to
>>>underline
>>> that this is not the intended way of differentiating our offering.
>>>Going
>>> forward I hope that we can be more aligned. I would like to see most of
>>>the
>>> current delta integrated to Qt by the time of 4.8.1, if it is possible.
>>
>>First: let me say thanks for bringing this up sooner rather than
>>later. That is certainly quiet a backlog (in a bad way), and one that
>>should be addressed ASAP, if not yesterday :). It's also pleasing to
>>hear that you want to work to bring these changes back to the Qt
>>Project.
>>
>>In my opinion, there's two issues that need addressing here.
>>
>>The first (already brought up) is gerrit. Gitorious' merge requests
>>are painful for everyone involved, so they're just going to slow you
>>down. Once things get into Gerrit, assuming they work in a similar
>>fashion to Qt 5, I think you'll find that changes can get pushed
>>forward a fair bit easier (especially assuming you know the right
>>people to poke for reviews, which I expect you do for the most part).
>>
>>The second is that these changes have been going to Qt 4.8. Some
>>people seem to have assumed this was an issue, but I'm not entirely
>>sure this was correct, as I seem to recall that Ossi had a magical
>>script to somehow mangle changes from 4.x into Qt 5.x[1] - and if that
>>is the case, there really isn't much further problem I think. If this
>>script doesn't do what I'm hoping, then we're going to have to figure
>>out how to get this work into Qt 5 with the minimum of pain (meaning
>>as soon as possible), before merging becomes impossible or at least
>>impractical.
>>
>>So anyway, the summary of my thoughts on solving this would be:
>>- get 4.x into Gitorious ASAP
>>- get the changes into 4.x (can probably be ongoing while the above
>>isn't finished, but will be helped)
>>- cherry-pick them into Qt 5 (in any way possible) to make sure work
>>isn't lost or duplicated, since I assume that your customers will be
>>asking about Qt 5 sooner rather than later :)
>>
>>...and we're back to working as one big, happy family in Gerrit :)
>
>Yes, that's the plan, except that we'll get 4.x into gerrit instead of
>gitorious ;-)
>
>Unfortunately moving it into gerrit is not as easy as one might think as
>the testing infrastructure is somewhat different between Qt 4.x and Qt 5.
>We could move Qt 4.x into gerrit very fast, but would loose the CI on it.
>If we want to keep CI, there's some work that needs to happen first.
>Sergio and Rohan know the details here.
>
>Cheers,
>Lars
>
>


If it takes more than a couple of weeks to get 4.8 into Gerrit, then it
would be great if some (or all) of the pending merge requests to 4.8 could
be handled using the old system still.

Many of our contributions are quite straightforward, similar to the ones
that have already been accepted earlier in 4.8 development.

And I assume there are also others who want to have their fixes in 4.8.1
and need to know if it is best to wait for Gerrit or go ahead with the old
system.

Yours,

--
Tuukka Turunen
Director, Qt Commercial R&D
Digia Plc
Piippukatu 11, 40100 Jyväskylä, Finland

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

Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)

[lars.knoll]

On 12/16/11 8:48 PM, "ext Thiago Macieira" 
wrote:

>On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote:
>> One idea is to have an automated process that propose the changes to
>> be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes
>> of what has been done to update the Qt5 sha1, e.g.
>> http://codereview.qt-project.org/11239), but at this stage is just an
>>idea.
>
>I still prefer merges, the Qt 4 way. This is something we'll need to
>figure out 
>by the time we branch 5.0 from 5.1.

Me as well. We can do merges in gerrit, but we should probably not try to
automate them.

Cheers,
Lars

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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[lars.knoll]

On 12/16/11 6:16 AM, "ext Robin Burchell"  wrote:

>Hi Tuukka,
>
>(now that I've left some hours to digest this...)
>
>2011/12/15 Turunen Tuukka :
>> So now there is total of 108 improvements and bug fixes available in Qt
>> Commercial 4.8.0 that are not part of the LGPL release. I want to
>>underline
>> that this is not the intended way of differentiating our offering. Going
>> forward I hope that we can be more aligned. I would like to see most of
>>the
>> current delta integrated to Qt by the time of 4.8.1, if it is possible.
>
>First: let me say thanks for bringing this up sooner rather than
>later. That is certainly quiet a backlog (in a bad way), and one that
>should be addressed ASAP, if not yesterday :). It's also pleasing to
>hear that you want to work to bring these changes back to the Qt
>Project.
>
>In my opinion, there's two issues that need addressing here.
>
>The first (already brought up) is gerrit. Gitorious' merge requests
>are painful for everyone involved, so they're just going to slow you
>down. Once things get into Gerrit, assuming they work in a similar
>fashion to Qt 5, I think you'll find that changes can get pushed
>forward a fair bit easier (especially assuming you know the right
>people to poke for reviews, which I expect you do for the most part).
>
>The second is that these changes have been going to Qt 4.8. Some
>people seem to have assumed this was an issue, but I'm not entirely
>sure this was correct, as I seem to recall that Ossi had a magical
>script to somehow mangle changes from 4.x into Qt 5.x[1] - and if that
>is the case, there really isn't much further problem I think. If this
>script doesn't do what I'm hoping, then we're going to have to figure
>out how to get this work into Qt 5 with the minimum of pain (meaning
>as soon as possible), before merging becomes impossible or at least
>impractical.
>
>So anyway, the summary of my thoughts on solving this would be:
>- get 4.x into Gitorious ASAP
>- get the changes into 4.x (can probably be ongoing while the above
>isn't finished, but will be helped)
>- cherry-pick them into Qt 5 (in any way possible) to make sure work
>isn't lost or duplicated, since I assume that your customers will be
>asking about Qt 5 sooner rather than later :)
>
>...and we're back to working as one big, happy family in Gerrit :)

Yes, that's the plan, except that we'll get 4.x into gerrit instead of
gitorious ;-)

Unfortunately moving it into gerrit is not as easy as one might think as
the testing infrastructure is somewhat different between Qt 4.x and Qt 5.
We could move Qt 4.x into gerrit very fast, but would loose the CI on it.
If we want to keep CI, there's some work that needs to happen first.
Sergio and Rohan know the details here.

Cheers,
Lars



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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[lars.knoll]

On 12/15/11 9:23 PM, "ext Olivier Goffart"  wrote:

>On Thursday 15 December 2011 11:53:12 sinan.tanil...@nokia.com wrote:
>> Hi,
>> 
>> Thank you for you summary Tuukka.
>> 
>> We hope to move Qt 4 to Gerrit soon. This should enable faster handling
>>of
>> contributions.
>
>Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8?
>
>I also see a lot of commit in Qt 4.8 that are not in Qt5. This is a
>problem.

Yes, having fixes in 4.8 that are not in 5 is a problem. However the
policy so far was to put the fix into 4.8 and forward port to 5.0. The way
to do that was to add the 4.8 repository to Qt5 using git alternate and
cherry-pick -x. IIRC, we even had a script to check for fixes that haven't
been forward ported to Qt 5.

Cheers,
Lars

>
>
>
>
>> 
>> Best regards,
>> Sinan Tanilkan
>> Mobile Phones Middleware - Integration and Quality Engineering
>> http://wikis.in.nokia.com/QtQualityEngineering
>> 
>> From: development-bounces+sinan.tanilkan=nokia@qt-project.org
>> [development-bounces+sinan.tanilkan=nokia@qt-project.org] on behalf
>>of
>> ext Turunen Tuukka [tuukka.turu...@digia.com] Sent: Thursday, December
>>15,
>> 2011 12:21 PM
>> To: development@qt-project.org
>> Subject: [Development] Qt Commercial 4.8.0 release delta to LGPL version
>> 
>> 
>> Hi All,
>> 
>> Qt 4.8.0 and Qt Commercial 4.8.0 have been released today. I wanted to
>>send
>> you e-mail about the delta between these.
>> 
>> We have worked hard with 4.8 to improve it for desktop and embedded
>> platforms according to the needs of commercial licensees. We have fixed
>>a
>> lot of bugs and included support to new platforms. While doing these, we
>> have made close to 200 contributions in the past few months, but
>> unfortunately not all these have yet been merged in to Qt.
>> 
>> So now there is total of 108 improvements and bug fixes available in Qt
>> Commercial 4.8.0 that are not part of the LGPL release. I want to
>>underline
>> that this is not the intended way of differentiating our offering. Going
>> forward I hope that we can be more aligned. I would like to see most of
>>the
>> current delta integrated to Qt by the time of 4.8.1, if it is possible.
>> 
>> Yours,
>> 
>> --
>> Tuukka Turunen
>> Director, Qt Commercial R&D
>> Digia Plc
>> Piippukatu 11, 40100 Jyväskylä, Finland
>> 
>> 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

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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[lars.knoll]

On 12/16/11 8:37 PM, "ext David Faure"  wrote:

>On Thursday 15 December 2011 11:21:41 Turunen Tuukka wrote:
>> So now there is total of 108 improvements and bug fixes available in Qt
>> Commercial 4.8.0 that are not part of the LGPL release.
>
>While I understand the reasons, I want to state that this is going to
>make 
>support a mess.
>
>Both versions are called 4.8.0, but do not contain the same code.
>
>So when someone says "With Qt-4.8.0 I have the following issue", it will
>never 
>be clear which 4.8.0 this is about, we'll have to educate everyone to say
>in 
>addition if this is 4.8.0-LGPL or 4.8.0-Commercial. Couldn't the version
>number be different, when the code is different, instead? E.g. 4.8.0c.
>That 
>doesn't fit into the numerical QT_VERSION, but at least qmake -query and
>every 
>other location which shows a qt version number (packages, qt creator,
>etc.) 
>would show clearly 4.8.0c instead of 4.8.0.


To some extent Linux distributions have always done that as well, and I
still remember something called qt-copy in KDEŠ ;-)


Cheers,
Lars

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

Re: [Development] Qt Commercial 4.8.0 release delta to LGPL version

[Anttila Janne]

> From: Thiago Macieira 
> On Monday, 19 de December de 2011 09.40.44, David Faure wrote:
> > > What should this do for something like 4.8.0c? Better to not confuse
> > > things
> > > and to leave the version number as it was. In practice, I'd be surprised
> > > if
> > > there was much confusion caused by Digia supplying a customised 4.8.0
> > > which
> > > includes just fixes. If people are using Digia's 4.8.0 version, I suspect
> > > they are also likely to report bugs they find to Digia instead of to the
> > > general Qt bug tracker anyway.
> >
> > I disagree.
> > They will post questions to forums, to consultants, on blog posts, etc. etc.
> 
> Anyone may produce a "vendor branch" and release it, so long as they clearly
> mark it as a patched version of the official Qt.
> 
> "Qt Commercial 4.8.0" sounds to me like it's clearly marked.
> 
Hi,

Since we intend to keep QtCommerial versions backward and forward compatible 
the equivalent open source release, we need keep the same version numbers as 
open source releases. First I would like to point out that there are already 
many places where "Commercial" is mentioned in our releases, to list a few of 
them:
- Release packages has "commercial" in filename
- License texts starts with "Qt Commercial",  license headers in all source 
files are Qt Commercial specific
- Changes, INSTALL, README files and all documentation footers speak about 
"Qt Commercial"
- Most places where Qt icon is used, we use QtCommercial icon (Including 
installers, demo launcher, about Qt dialog, etc). The QtCommrcial icon is 
basically the Qt icon with added "Commercial" string 
- Our Windows "start menu" mention "Commercial"

So I think it should be already quite clear for our customers that they are 
using commercial version instead of open source one. But of course there is 
room for improvement, and the following ideas raised here are fine for us:

1. We will add QT_COMMERCIAL definition to our releases in future
2. We will add "Commercial" texts to places where QT_VERSION_STR is shown, so 
that for example aboutQt, qmake -v, etc would say: "...Qt Commmercial version 
4.8.0..."
3. We will not change either QT_VERSION or QT_VERSION_STR. This because there 
are (and can be) places where these are assumed to contain numeric only 
information

To ease our maintenance burden, we would like do change #2 so that we introduce 
a new QT_STR, QT_PRODUCT_NAME_STR (or whatever) definition, which is then used 
instead of hard coded "Qt" string in all relevant places. 

Would that approach be OK and enough for everybody?

-- 
Janne Anttila 
Architect, Qt Commercial R&D
Digia Plc
Sepänkatu 20, FIN - 90100 OULU
E-mail: janne.antt...@digia.com
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] QLatin1Constant and QtContacts / QtOrganizer

[lars.knoll]

Great, that's good to hear. I think I've seen it in some other places in
the former Qt Mobility modules as well though.

Cheers,
Lars

On 12/19/11 11:42 PM, "Zhu Xizhi (Nokia-MP/Tampere)" 
wrote:

>Hi,
>
>We're actually removing the usage of QLatin1Constant in QtContacts,
>QtOrganizer, and QtVersit.
>It's copied just as a temporary solution during the modularization of
>these modules.
>
>
>Xizhi Zhu (Steven)
>
>Software Engineer @ Qt Development Frameworks
>Nokia
>
>Mobile: +358 (0)50 480 1247
>
>From: development-bounces+xizhi.zhu=nokia@qt-project.org
>[development-bounces+xizhi.zhu=nokia@qt-project.org] on behalf of ext
>Mathias Hasselmann [math...@openismus.com]
>Sent: Tuesday, December 20, 2011 12:08 AM
>To: Knoll Lars (Nokia-MP/Oslo)
>Cc: development@qt-project.org; Rose Todd (Nokia-M/Alpharetta)
>Subject: Re: [Development] QLatin1Constant and QtContacts / QtOrganizer
>
>Am Montag, den 19.12.2011, 19:18 + schrieb lars.kn...@nokia.com:
>> On 12/14/11 11:01 AM, "ext todd.r...@nokia.com" 
>> wrote:
>>
>> >I'm in the early stages of trying to port a Qt4.7 app that uses
>> >qt-mobility to Qt5.  Today I noticed compile errors caused by the
>> >duplication of qlatin1constant.h in both of these
>> > modules.
>> >
>> >The problem shows when you write an app that uses both the QtContacts
>>and
>> >the QtOrganizer modules.   Headers within the QtContacts module will
>> >sometimes include the QtOrganizer version of qlatin1constant.h (or
>> >vice-versa depending on the app's include path
>> > ordering).  The use of namespaces in these headers is what leads to
>>the
>> >errors.
>> >
>> >There's several solutions, and I guess it'd be best if the
>> >QLatin1Constant functionality was moved to a core library, but until
>>then
>> >can we at least have the headers *within* the Contacts and Organizer
>> >modules include qlatin1constant.h in an unambiguous manner?
>>
>> I'm actually wondering whether this class still makes sense in Qt 5.
>>We've
>> done some changes to QLatin1String to make it more suitable and have
>> QStringLiteral in addition. That should make the need for this class
>> mostly go away IMO.
>
>+1 - QLatin1String is painful to use: You cannot really store references
>to it, you constantly get trouble from C++ not being able to resolve
>which of its cast operators shall be used (QString vs. QLatin1String).
>Also I never really got is purpose: To enable comparison and hashing of
>QtContact's string keys, and to make sure those strings don't waste
>memory on heap, it would have been sufficient to use QString::
>fromRawData() to initialize those constants.
>
>Ciao,
>Mathias
>
>--
>Mathias Hasselmann 
>http://openismus.com/
>
>___
>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