[Development] Documenting 3rd party license code (with SPDX?)

[Kai Koehne]

tl;dr: Does anyone have experience with SPDX?

Qt modules contain quite some 3rd party code under various (permissible) 
licenses. We've been listening these in the
documentation, but this is certainly improvable - while the list is (hopefully) 
comprehensive, it gives users little help in where the 
3rd party code is actually used (library, plugin, platform), what to do to 
avoid it (configure arguments?), how to acknowledge 
distribution requirements ...

The list is also managed centrally in qtdoc.git, which requires a lot of effort 
to keep up to date with the other modules. 
My first step to improve the situation is therefore to move the documentation 
to where the code is actually located. 
At the same time I think it's a good idea not to just write .qdoc, but use a 
more specific format that then can be processed.

What I'd like to suggest eventually is that
- every code in our git modules where we don't have the relicensing rights for 
needs to be under a '3rdparty' folder
- every folder needs a structured document that describes things like the 
license(s), copyright, where the code originated ...

And that we then automatically process the documents to generate the 
documentation.

Anyhow, first we have to settle on a file format. So far I have had a look at 
two file formats:

* README.Chromium *

Chromium mandates that every folder under 3rdparty needs a semi-structured file 
called 'README.chromium':

https://src.chromium.org/viewvc/chrome/trunk/src/third_party/README.chromium.template

There's then a python tool that takes some of the information, and generates 
the credits information page (chrome://credits)

The file format is pretty light-weight and informal, but this has its 
drawbacks: Namely that the tool doesn't really validate much, and there 
seems to be some ongoing confusion on what exactly the individual fields should 
contain. Take e.g. URL: This is rendered in Chrome as 
a link to the 'Homepage' of the project, but a lot of documents actually link 
to individual downloads there. It's also focused on
credits page, so it would need to be extended ...

* SPDX *

SPDX (Software Package Data Exchange) "is a standard format for communicating 
the components, licenses and copyrights associated 
with a software package." The probably most popular thing they have is a list 
of standard names for different licenses

https://spdx.org/licenses/

But there's also an elaborate standard how to document 'software packages'. The 
documents can apparently both be written in Excel,
RDF (XML), and Key/Value formats, there are (Java) tools to convert them, and 
there's a lot of tooling around it. But honestly speaking I've 
troubles wrapping my mind around the standard. It seems quite heavy, and I'm 
lost how exactly to apply it to our situation. But I do see 
that, if a lot of customers/upstream distributions would like to use SPDX files 
too, using it directly in Qt might be beneficial.


So, does anyone had exposure to SPDX already, and maybe have an idea how it 
could be used for our 3rdparty directories in Qt?
Personally I'm leaning towards defining our own customized JSON format that 
uses the best things from SPDX (standardized license id's)
and README.Chromium. But I'd be glad to discuss with people interested in the 
topic :)

Thanks for reading

Kai

-- 
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

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

Re: [Development] QtWebkit to vcxproj

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of raven-worx Software
> Sent: Wednesday, May 25, 2016 4:11 PM
> To: development@qt-project.org
> Subject: [Development] QtWebkit to vcxproj
> 
> Hi,
> 
> i am trying to create a vcxproj-Project of the QtWebKit module.

Which begs the question: Why?

I'm not claiming it's not possible. But building Qt itself within Visual Studio
Is not common, let alone Qt WebKit.

Kai

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

Re: [Development] Building Always on same path?

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Reynaldo San Juan
> Sent: Thursday, June 16, 2016 3:13 PM
> To: development@qt-project.org
> Subject: [Development] Building Always on same path?
> 
> Hi
> I'm developing a litle app and
> I want to build always inside the user Home path. on Unix based systems is
> very easy puting the "~"char at the begining of the path, but o Windows "~"
> doesn't work, I used instead "%userprofile%" , like enviroment variable, but
> isn't working neither.
>
> Could you tell me how could I do that and use inside the .pro file to refer to
> enviroment vars?
>

You can write 

   $$getenv(USERPROFILE),

 or just 

   $$(USERPROFILE) 

to get the contents of %USERPROFILE%  environment variable

http://doc.qt.io/qt-4.8/qmake-advanced-usage.html#variables

> regards,
> Rey San Juan
> PD: Be nice with me, I'm a new one here :D & sorry my english.

Let me just point out that this is the mailing list where things regarding Qt 
development itself are discussed. For questions on how to use Qt, please use to 
inter...@qt-project.org

Regards

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

Re: [Development] New Qt 5.7.0 RC snapshot available

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Ralf Nolden
> [...]
> I suggest having a look at https://bugreports.qt.io/browse/QTBUG-49883
> and do some consideration how to handle those issues. If modules are
> deprecated but should still work for backwards compatibility, then there
> should be no change at all that prevents that.

There's a difference between deprecated and unsupported.

Deprecated means we don't advice you to start _new_ projects with it,
Otherwise it has the same promises as any other module.

Unsupported means it's not part of Qt anymore.

> Otherwise that module is
> "somewhat supported even if we don't like to" - which creates a really
> confusing situation for packagers and porters, but (at least I) can live with
> that as long as we get updated (tagged) release tarballs :)

QtQuick1 and QtWebKit are _not_ supported anymore since Qt 5.6. 

What we have said is that we will provide QtWebKit source packages as courtesy 
on a  best-effort basis. That is, also the QtWebKit source package under

http://download.qt.io/community_releases/5.6/5.6.0/

is not part of Qt anymore, and not supported. Use it at your own risk.
There's also no promise we can continue providing these.

> So, an updated tarball for qtquick1 for 5.6 would be really much appreciated
> (so that it works with 5.6.x and 5.7.x)

It's the first time I hear someone asking for a tarball for QtQuick1. 

I see that people are still stuck with WebKit for some use cases, because the 
architecture, OS requirements and API of WebEngine differs. For QtQuick, 
it's IMO really painless to update. Also, last time I checked, there were very 
little  Linux packages left that still require Qt Quick 1. So what's your use
case?

Regards

Kai

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

Re: [Development] Should the system proxies default setting be switched to true?

[Kai Koehne]

+1 for switching to using the system proxy settings by default.

I'm still a bit wary about the 'Windows issue' though. To cite our 
documentation [1]:

  "On Windows platforms, this function may take several seconds to execute 
depending on the configuration of the user's system."

Was that the problem with Windows versions configured for automatically 
querying for PAC files, but never getting any response?

Regards

Kai

[1]: http://doc.qt.io/qt-5/qnetworkproxyfactory.html#systemProxyForQuery

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Andy Shaw
> Sent: Wednesday, May 11, 2016 3:51 PM
> To: development@qt-project.org
> Subject: [Development] Should the system proxies default setting be
> switched to true?
> 
> For some time now we have had the means to configure Qt to use system
> proxies so that they are on by default or to turn it on via
> QNetworkProxyFactory. However, this is off by default so it is becoming a
> reoccurrence that people don't realise that it is not using the system proxies
> until later on. Potentially not until after a product has been released.
> 
> 
> The reasoning that this was not done before was due to the fact that there
> was a problem on Windows with it taking too long in some cases to get the
> information. However this seems to be solved for the most part and
> expected in some cases due to the fact that it is down to the system, but it 
> is
> just an initial start up check in this case.
> 
> 
> That said, does anyone see any problems with switching it so that we can
> now have it turned on by default from Qt 5.8? Naturally the configure option
> would stay so people can still turn it off if they wish.
> 
> 
> For reference the original thread about this can be found:
> 
> 
>   http://lists.qt-project.org/pipermail/development/2012-
> October/007037.html
> 
> 
> Andy
> ___
> 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] Does Qt 5.6 still depend on ICU?

[Kai Koehne]

> -Ursprüngliche Nachricht-
> Von: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] Im Auftrag von Alexander Nassian
> Gesendet: Sonntag, 8. Mai 2016 00:56
> An: Roland Winklmeier 
> Cc: development@qt-project.org
> Betreff: Re: [Development] Does Qt 5.6 still depend on ICU?
> 
> As far as I know Chromium also depends on ICU and without WebKit or
> WebEngine you may but need not to use ICU.

Qt WebEngine  / Chromium on Windows builds with a statically linked version 
of ICU by default though, so there's no need to ship the ICU dll's for Qt 
WebEngine - just the icudtl.dat file .

Regards

Kai

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

Re: [Development] Remember to rebuild qmake in dev

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Thursday, July 21, 2016 10:51 PM
> To: development@qt-project.org
> Subject: Re: [Development] Remember to rebuild qmake in dev
> 
> On quinta-feira, 21 de julho de 2016 18:02:51 PDT Mitch Curtis wrote:
> > It's probably worth pointing out what kind of errors we can expect
> > should we forget (so that we can recognise the problem).
> 
> The moc_predefs.h file contains qmake's help output, as opposed to a valid C
> source file. Since that file is consumed by moc itself, you're going to get 
> moc
> parsing errors.

Actually the qmake call already returns with an error code, so what you see is 
just something like

jom: D:\dev\qt\dev\msvc-2015-32\qtbase\src\testlib\Makefile.Debug 
[.moc\debug\moc_predefs.h] Error 2

with no previous error message.

Been there, done that :)

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

Re: [Development] QtCon rooms for QCS

[Kai Koehne]

I've submitted 4 'workshop' sessions, mostly as placeholders. I wouldn't mind 
replacing them with more urgent / interesting topics though, if there are ones. 
C++11 library usage would definitely be one I'm interested in myself :)

Also, the agenda overview should clearly distinguish between presentations and 
workshops ...

Regards

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Tero Kojo
> Sent: Wednesday, August 03, 2016 10:36 AM
> To: Thiago Macieira ; development@qt-
> project.org; akademy-team 
> Subject: Re: [Development] QtCon rooms for QCS
> 
> Hi,
> 
> Yes, there is a reservation of room space for topics that come up in for Qt
> contributors.
> 
> I need to figure out the best (simplest) process for how we manage that
> space. For now mailing me directly is probably the best way, as I need to add
> the topics to the event management system.
> 
> Tero
> 
> > -Original Message-
> > From: Thiago Macieira [mailto:thiago.macie...@intel.com]
> > Sent: tiistaina 2. elokuuta 2016 23.50
> > To: development@qt-project.org; akademy-team  t...@kde.org>
> > Cc: Tero Kojo 
> > Subject: Re: [Development] QtCon rooms for QCS
> >
> > On terça-feira, 2 de agosto de 2016 17:50:24 PDT Gabriel de Dietrich wrote:
> > > Hi Thiago,
> > >
> > > I’m replying on Morten’s behalf since that session was initially
> > > suggested by me and Jake.
> >
> > > It’s going to be a QtCS session. We need to discuss some recurring
> > > issues related to rendering on Mac. Other related topics may arise,
> > > but no formal presentation AFAIK.
> >
> > Thanks.
> >
> > I still need to know how to add more topics. Previously, we had a wiki
> > so we could edit.
> >
> > Tero, can you help?
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming...

[Kai Koehne]

Hi,

Unfortunately, we're having great difficulties to get patches integrated into 
Qt WebEngine in the last days, right now due to qtlocation not compiling 
(QTBUG-55229). Unless the situation resolves itself over the weekend, I'd like 
to ask for an exception for getting features into 5.8 for Qt WebEngine even 
after Monday morning.

The features still waiting to get merged are
Printing: https://codereview.qt-project.org/#/c/162928/ and following
Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/
Support for certificate transparency: 
https://codereview.qt-project.org/#/c/167275/
Support for custom QML context menu/ dialogs: 
https://codereview.qt-project.org/#/c/162263/, 
https://codereview.qt-project.org/#/c/165731/
Support for Qt Quick 2 Controls dialogs: 
https://codereview.qt-project.org/#/c/162262/

Regards

Kai


> -Original Message-
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Jani Heikkinen
> Sent: Monday, August 08, 2016 12:58 PM
> To: development@qt-project.org
> Cc: releas...@qt-project.org
> Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8
> Feature Freeze coming...
> 
> Hi all,
> 
> 
> 
> 
> Qt5.git integration in 'dev' succeed during the weekend and we have soft
> branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th
> August 2016 as well as final branching from 'dev' to '5.8'
> 
> 
> 
> 
> 
> So please start using '5.8' for changes targeted to Qt 5.8 release and 
> finalize
> ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen
> Monday 15th Aug (morning).
> 
> 
> 
> 
> Please make sure
> 
> 
> - All new modules for Qt 5.8 are in 'dev' & part of qt5.git
> 
> 
> - All mandatory new features are in 'dev' now or coming in within a week?
> 
> 
> - New feature page contains all new features etc:
> https://wiki.qt.io/New_Features_in_Qt_5.8
> 
> 
> 
> 
> We will create first src packages from latest qt5.git integration as soon as
> possible. Please check the packages immediately when available to see if
> something important is missing. Those packages should be quite close to Qt
> 5.8 alpha packages so it will be really important to check the packages now.
> 
> 
> 
> 
> br,
> 
> Jani
> 
> 
> 
> 
> 
> Jani Heikkinen
> Release Manager
> 
> The Qt Company
> Elektroniikkatie 13
> 90590 Oulu Finland
> jani.heikki...@qt.io
> +358 50 4873735
> http://qt.io 
> 
> 
>  
>  
> 
> 
> 
> 
> 

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

Re: [Development] [FYI] commit/review policy refactored

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, July 13, 2016 11:08 AM
> To: development@qt-project.org; qt-crea...@qt-project.org
> Subject: [Development] [FYI] commit/review policy refactored
> 
> just a heads-up that i (finally) split off the review policy from the commit
> policy. see https://wiki.qt.io/Review_Policy .
> if you have suggestions for improvement, please discuss them upfront on irc.

I prefer to reply here :)

The page is obviously written from the viewpoint of a maintainer. I'd prefer to 
write
It in a less intimidating way to the contributor, and make it helpful for first 
time,
inexperienced contributors.



> As a Contributor

Maybe link back to https://wiki.qt.io/Commit_Policy .

"Make sure that your commit matches the Qt Commit Policy.

> 1. Invite relevant reviewers.
> * Always invite the respective domain experts, not somebody convenient.

Scrap the 'not somebody convenient'. It's the job of the reviewer to decide 
what he can approve.

Instead, mention how one can find the 'domain expert'. Something like

 * Domain experts can usually be found by inspecting the git log, and mailing 
lists. If in doubt also add the [https://wiki.qt.io/Maintainers Maintainer] of 
an area if there is one.

> 2. Give reviewers ample time to respond.
> * Unless everyone who can be reasonably expected to have a relevant opinion 
> to offer has already done so, a full working day waiting time is the absolute 
> minimum; three days are reasonable.
> * In particular, give watchers (usually higher-level maintainers) enough time 
> to voice concerns even if you did not explicitly invite them.

The sub-points are only valid if you have a +2 already. So maybe move them down 
to a section ("If your change got approved"). Rather mention that it can take 
some working days until added people respond.

> 3. Discuss objections. Do not override a -1 unless there is a broad expert 
> consensus that the objection is unfounded.

A Contributor cannot usually 'override' a -1 - that can only be done by an 
approver. Maybe your point is though that, if you got a +2, and somebody voiced 
objections, one shouldn't stage it?

> 4. Do not ignore/fight the Early Warning System. Justify each override.
> [...]

Isn't that limited to Approvers, too?

> 5. Do not approve your own changes.
[...]

Again that's limited to Approvers, and should be in the 'As a Reviewer' 
section. 


Regards

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

Re: [Development] [QtMultimedia] Still is supported, active?

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> So while I agree that angriness is not helpful for mail list ... messages 
> like this
> are probably the seed to rethink strategy of working with bugs.

Somewhat a side remark, but the unfortunate consequence of this thinking is
that the objectively best way to get a lot of Qt developers interested in your
problem is to write e-mails that breach of etiquette (to put it mildly).

If Denis would have written a reasonable e-mail asking about the status of Qt
Multimedia (without insults, attacks, and wishing anyone to hell), we most
probably won't have this discussion.



I think Denis should end this e-mail thread by apologizing, and start a new one
in a reasonable way.

Just my 2 cents,

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

Re: [Development] Documenting 3rd party code Qt

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Wednesday, July 20, 2016 6:57 PM
> To: development@qt-project.org
> Subject: Re: [Development] Documenting 3rd party code Qt
> 
> On quarta-feira, 20 de julho de 2016 11:13:39 PDT Kai Koehne wrote:
> > I had a look at SPDX, README.Chromium, debian/copyright (btw thanks
> > for the pointer!). In the end I went for a custom format, because they
> > all seem to not quite fit for our use case. Anyhow, it's easy to
> > extend licensescanner to generate other formats, too.
> 
> What's missing from SPDX and have you tried to talk to them about adding
> the missing information?

I'm not sure whether anything particular is missing in the standard - my best
guess is we could create a syntactically valid SPDX file containing the same
information that we currently have in the proposed qt_attribution.json file 
format.

However, SPDX is a standard for "software packages" - it would probably make
more sense to add an SPDX file for QtCore or even qtbase. Using a SPDX file for
a single file in 3rdparty feels a bit like a misuse. 

Also, the tools I found to process spdx files are written in Java, which I 
certainly 
do not want to add as a build dependency. This would mean we'd write a custom 
parser for the subset of SPDX we'd support.

In the end I concluded it's just easier to have a tailored format we have full
control over, but can be used as a source for generating 
SPDX/debian_copyright/...
files as they're needed. I'd be happy to have a discussion about this with
someone interested in this.

My proposal is to use the names and matching guidelines from
https://spdx.org/licenses/ though. 


Regards

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

[Development] Documenting 3rd party code Qt

[Kai Koehne]

Hi,

A while ago I proposed to generate 3rd party code attributions out of files 
that are right beside the code, instead of hand-editing 3rdparty.html in qtdoc. 
I've now a set of patches that are IMO worth to take a look at (also because FF 
for 5.8 is coming ;)

# Information Flow

Every 3rd party code in our repositories should get a 'qt_attribution.json' 
file containing metadata about the code. When the documentation of a module is 
built, a new tool 'licensescanner' is automatically run by qmake that scans the 
sources for qt_attribution.json files, and generates a .qdoc file with pages 
for every attribution it finds. An overview of the attributions is shown on 
each modules entry page. Finally, the current 3rdparty overview page should be 
automatically generated from all modules' attribution pages.

# File Format

I had a look at SPDX, README.Chromium, debian/copyright (btw thanks for the 
pointer!). In the end I went for a custom format, because they all seem to not 
quite fit for our use case. Anyhow, it's easy to extend licensescanner to 
generate other formats, too.

The current format is documented in  https://wiki.qt.io/Qt_attribution.json .

Real-life examples for qtbase can be found in 
https://codereview.qt-project.org/#/c/160970/ .

# QDoc Extension

To be able to document and structure the 3rd party content I introduced a new 
'attribution' attribute to qdoc's \page command, and added 
\generatelist{attributions}, \generatelist{annotatedattributions} commands.

# Patches

qttools patches (licensescanner, qdoc modifications): 
https://codereview.qt-project.org/#/q/status:open+project:qt/qttools+branch:dev+topic:3rdparty,n,z
qtbase patches (qt_attributions.json files, build integration, overview pages): 
https://codereview.qt-project.org/#/q/status:open+project:qt/qtbase+branch:dev+topic:3rdparty,n,z
qtdoc patch (for general overview page): 
https://codereview.qt-project.org/#/q/status:open+project:qt/qtdoc+branch:dev+topic:3rdparty,n,z

# FAQ

Q: Why do we need such an elaborate setup? Wouldn't it be easier to just write 
.qdoc files?

Keeping the 'documentation' close to the actual sources hopefully makes sure 
they're up to date and complete. Admittedly we could also just have .qdoc files 
right beside each code snipped, and include this one. In the future I'd like to 
extend the tool though so that attribution information (say HTML) for an app 
bundling Qt can be generated. The qt_attribution.json file could also be used 
as input to 3rd party code scanners popular in the industry, or used as a 
source for generating SPDX files ... Keeping the metadata outside of .qdoc 
makes this a lot easier.

Q: What about 3rd party code in tests/examples ...?

I think they should get a qt_attribution.json file too. We have to mark though 
what actually ends up in the Qt libs, and what only ends up in tests / build 
system / host tools ... I'm still contemplating how to best document this in 
the qt_attribution.json file.

Regards

Kai

-- 
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Documenting 3rd party code Qt

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Lisandro Damián Nicanor Pérez Meyer
> Sent: Wednesday, July 20, 2016 4:04 PM
> To: development@qt-project.org
> Subject: Re: [Development] Documenting 3rd party code Qt
> 
> On miércoles, 20 de julio de 2016 11:13:39 A. M. ART Kai Koehne wrote:
> > Hi,
> [snip]
> > # File Format
> >
> > I had a look at SPDX, README.Chromium, debian/copyright (btw thanks
> > for the pointer!).
> 
> My pleasure :)
> 
> > In the end I went for a custom format, because they all seem to not
> > quite fit for our use case. Anyhow, it's easy to extend licensescanner
> > to generate other formats, too.
> 
>  That might be helpful, although the current format lacks, for example, per-
> entity copyright (yes, each contributor name).
>
> I *know* this is a big burden because I have to do it :) But if this can be
> added, even if optional, we the ones who need this info can fill these details
> on each of our reviews.

It can easily get laborious, but I don't see why we shouldn't allow something 
like

"CopyrightFiles" : [
   { "*": "Copyright (c) 1920 Joe Doe", },
   { "special_file": "Copyright (c) 2040 Jane Roe" }
]

in the format, sure. 

I'm genuinely curious though why debian/copyright needs this on a file level.  
Do you know the reasons?

Regards

Kai

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

Re: [Development] Documenting 3rd party code Qt

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> >  That might be helpful, although the current format lacks, for
> > example, per- entity copyright (yes, each contributor name).
> [...]
> I'm genuinely curious though why debian/copyright needs this on a file level.
> Do you know the reasons?

Actually re-reading " Example files paragraphs" from 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ :

> Files: *
> Copyright: 1975-2010 Ulla Upstream
> License: GPL-2+
>
> Files: debian/*
> Copyright: 2010 Daniela Debianizer
> License: GPL-2+
>
> Files: debian/patches/fancy-feature
> Copyright: 2010 Daniela Debianizer
> License: GPL-3+
> 
> Files: */*.1
> Copyright: 2010 Manuela Manpager
> License: GPL-2+
>
> [...]
> Since the license of the manual pages is the same as the other files in the 
> package, the last paragraph above could instead be combined with the first 
> paragraph, listing both copyright 
> statements in one Copyright field. Whether to combine paragraphs with the 
> same license is left to the discretion of the author of the debian/copyright 
> file.

If I got this right it says you can combine copyright lines from multiple files 
if the license is the same. So far we don't actually support differently 
licensed files in one json object (that's why e.g. 
https://codereview.qt-project.org/#/c/160970/11/src/3rdparty/angle/qt_attribution.json
 is split up in multiple objects). Hence I'm questioning whether we really need 
to support separating Copyright's per file.

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

Re: [Development] [Qt-creator] [FYI] commit/review policy refactored

[Kai Koehne]

> -Original Message-
> From: Qt-creator [mailto:qt-creator-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, July 13, 2016 12:49 PM
> To: development@qt-project.org; qt-crea...@qt-project.org
> Subject: Re: [Qt-creator] [Development] [FYI] commit/review policy
> refactored
> 
> On Wed, Jul 13, 2016 at 12:15:44PM +0200, Kai Köhne wrote:
> > The page is obviously written from the viewpoint of a maintainer. I'd
> > prefer to write It in a less intimidating way to the contributor, and
> > make it helpful for first time, inexperienced contributors.
> >
> first-timers can ask in case of doubt. this is meant to be a policy, not an 
> intro.

If we'll have a separate intro page (which is linked from here), then fine with 
me :)

> somewhat unsurprisingly, i finally took the effort to do this work because i
> witnessed several unrelated violations in the last weeks/ months.

That's what I suspected :)
 
> > > As a Contributor
> >
> > Maybe link back to https://wiki.qt.io/Commit_Policy .
> >
> it's linked from the reviewer section, which i find more logical.

Fair enough.

> > "Make sure that your commit matches the Qt Commit Policy.
> >
> > > 1. Invite relevant reviewers.
> > > * Always invite the respective domain experts, not somebody
> convenient.
> >
> > Scrap the 'not somebody convenient'. It's the job of the reviewer to decide
> what he can approve.
> >
> it's the responsibility of both sides. don't pretend that these social 
> dynamics
> don't exist.

Well, in doubt the blame is always on the approver, not on the contributor. 
Also,
it's perfectly fine to add 'convenient' people, be it only to check commit logs,
or notify them about stuff. The point is just that they shouldn't approve it if 
they're 
not 'domain experts' - which is covered in the Approver's section.

> > Instead, mention how one can find the 'domain expert'. Something like
> >
> >  * Domain experts can usually be found by inspecting the git log, and
> mailing lists. If in doubt also add the [https://wiki.qt.io/Maintainers
> Maintainer] of an area if there is one.
> >
> that's already listed in the contribution guidelines and i wanted to avoid
> excessive redundancy. i may reconsider, or move parts of the content. some
> more linking is necessary anyway.

Fine with me if there's another page that's linked.

> > > 2. Give reviewers ample time to respond.
> > > * Unless everyone who can be reasonably expected to have a relevant
> opinion to offer has already done so, a full working day waiting time is the
> absolute minimum; three days are reasonable.
> > > * In particular, give watchers (usually higher-level maintainers) enough
> time to voice concerns even if you did not explicitly invite them.
> >
> > The sub-points are only valid if you have a +2 already. So maybe move
> them down to a section ("If your change got approved"). Rather mention
> that it can take some working days until added people respond.
> >
> that's a good idea. a section about staging and re-staging is needed anyway.
> 
> > > 3. Discuss objections. Do not override a -1 unless there is a broad expert
> consensus that the objection is unfounded.
> >
> > A Contributor cannot usually 'override' a -1 - that can only be done by an
> approver. Maybe your point is though that, if you got a +2, and somebody
> voiced objections, one shouldn't stage it?
> >
> every approver is a contributor by definition. ;) 

Not every contributor is an approver though, so it makes IMO more sense to put 
stuff specific to approvers into the reviewers section.

Or prefix them with "For contributors that are also approvers:".

> but i guess "disregard" is a
> better word than "override" in this case.

Fine with me. I think 'consensus' instead of 'broad expert consensus' is enough 
too :)

> > > 4. Do not ignore/fight the Early Warning System. Justify each override.
> > > [...]
> >
> > Isn't that limited to Approvers, too?
> >
> ...
> 
> > > 5. Do not approve your own changes.
> > [...]
> >
> > Again that's limited to Approvers,
> >
> yes
> 
> > and should be in the 'As a Reviewer' section.
> >
> no. it's addressing the contributor.

A contributor that's also an approver, which is the minority.

My point is: This text reads like a proverbial stick you want to use against 
fellows that overstep their limits (as you perceive it). I'm somewhat skeptical 
that putting down draconical rules somewhere on the wiki helps on this , but 
whatever.

My fear is that this is rather read, and taken literally, by first-time/seldom 
contributors that already feel intimidated by the whole process in the first 
place ('can't I just append my patch to bugreports?'). So let's make it clear 
what they have to take care of, and what not.

Regards

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

Re: [Development] Source break policy for function overloads

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
>  We do not have SC promise only BC. We tend to not break SC without
> reason, for example we avoid juggling with header files just to "cleanup"
> stuff, but definitely we reserve right to add overloads and new functions.
> That is the current state, whatever it make sense or not is a different
> discussion.

We should fix 

https://wiki.qt.io/Qt-Version-Compatibility

then.

I agree though that we can't guarantee source compatibility in all cases
(indirect includes are one example).

We could establish a rule that methods marked with Q_SLOTS shouldn't
be overloaded. Not that this would've helped, since QTimer::setInterval is not 
marked as a slot.

Regards

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

Re: [Development] Change file process & improvement proposal

[Kai Koehne]

Looks like this discussion got stuck before reaching a conclusion ...

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, November 10, 2016 3:23 PM
> To: development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Development] Change file process & improvement proposal
> [...]
> > 1) Let's enable [ChangeLog] -tag by default in commit template. After
> > that you must remove/comment out it by purpose if you don't want add
> > it.
> >
> i really don't think this will make a positive difference. the problem is that
> many people just don't have the right audience-oriented mindset.
> we *already* have lots of garbage changelog entries, and this will just
> worsen the S/N ratio.

Actually looking through the commit logs e.g. in qtbase, I do think most 
[ChangeLog] entries are rather fine - surely some tweaking is sometimes 
necessary, but the quality of the ChangeLog entries we have is not all that bad.

What is obvious though is that a lot of commits where I would have expected a 
[ChangeLog] do not have one. What's more, a well written [ChangeLog] entry will 
help also during the review, and can serve as a sanity check when it comes to 
the right branch being targeted etc.

I therefore agree with Janne that we should encourage people to write them, and 
changing the default template is a very easy thing to do.

> > And in addition to this update sanity bot so that it will give '-1' if
> > change log entry isn't given in release branch.
> >
> this is probably not sensible. most last-minute fixes relate to recently
> introduced problems, which means that they specifically *don't* need
> changelog entries.

That might be the case until the first .0 release from the branch is done, but 
surely not afterwards.

Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0 branched_. 
Is that easy to enable/disable?

> here's what i think would actually make a difference (based on historical
> evidence within trolltech):
> https://bugreports.qt.io/browse/QTQAINFRA-933

Such a tool/infrastructure would be cool to have, indeed. It requires a lot 
more investment though than the incremental changes Jani proposed. 

I therefore suggest to implement Jani's suggestions for the time being. If we 
find out they're not effective, we can always come back and look into 
alternative processes.

1. Enable [ChangeLog] tag in commit template

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

2. Add check in sanity bot to check for missing ChangeLog entries (potentially 
only in 5.x branches after 5.x.0 is out)

(who could do this?)

Regards

Kai

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

Re: [Development] [Releasing] Change file process & improvement proposal

[Kai Koehne]

> -Original Message-
> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Thursday, January 26, 2017 12:52 PM
> To: development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
> 
> On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> > I don't know what you're saying, much less why it's supposed to be the
> > obvious interpretation.  A "tagged commit" is presumably v5.7.0 or
> > similar; why should a commit without an amends line be assumed to
> > relate to one of these ?
> >
> i used "tagged commit" as a shorthand for "a commit which is reachable from
> a tag", which should be fairly clear from the context. i.e., "git tag 
> --contains
> " returns something.

Well, I had a hard time deciphering this, too. 



Anyway, this all feels like we get side-tracked in details. To reiterate:

- We do (still) have a problem with our ChangeLog files
  * The quality of the entries, and the scope, greatly differs (between modules)
  * We do have a problem getting them in place on time for a release

Jani's proposal is to fix parts of this is to encourage committers and 
reviewers to write [ChangeLog] entries as part of the commit. This could be 
encouraged by
* Enabling the [ChangeLog] line by default in the commit template
* Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx)

For the sanity bot, either we decide that _every_ change has a [ChangeLog], or 
we try to make the bot intelligent enough to decide whether a commit needs a 
change log, or not. Parts of the discussion so far makes me think that this 
will be an uphill battle though.

So, any strong opinion against enforcing a [ChangeLog] line, with "[ChangeLog] 
-" for commits that don't need one?

Regards

Kai

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

Re: [Development] [Releasing] Change file process & improvement proposal

[Kai Koehne]

> -Original Message-
> > [...]
> > I therefore suggest to implement Jani's suggestions for the time
> > being. If we find out they're not effective, we can always come back
> > and look into alternative processes.
> >
> > 1. Enable [ChangeLog] tag in commit template
> >
> > https://codereview.qt-project.org/183244
> >
> > 2. Add check in sanity bot to check for missing ChangeLog entries
> > (potentially only in 5.x branches after 5.x.0 is out)
> 
> Why only there? All relevant changes should have it - regardless of branch.
> 
> I would actually suggest we change the sanity bot to -1 any change that has
> no [ChangeLog] entry. And we then agree on a marker that says "no
> changelog needed".
> 
> [ChangeLog] none
> 
> or similar.

This will add quite some noise - There'll always be a significant portion of 
the commits, if not the majority, which do not require a ChangeLog. 

But yeah, it's easy to check and enforce :) I could live with this, too.

Kai

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

Re: [Development] [Releasing] Change file process & improvement proposal

[Kai Koehne]

Hi,

To sum the discussion here and also on gerrit up : There's no consensus on 
making [ChangeLog] entries mandatory, or making the [ChangeLog] field enabled 
by default.

Anyhow, Ossi had an interesting third suggestion on 
https://codereview.qt-project.org/#/c/183244/:

> how about this for an idea: we add a new gerrit category "ChangeLog" which 
> needs a +1. it would be auto-set by the bot if a changelog file is touched, 
> otherwise a reviewer needs to set it. easy to implement, reliable (well, as 
> much as the reviewers), and adds no noise to the commit messages.

I understand that this would not be hard to do. This way nobody is forced to 
write changelog entries, but it requires a conscious click from the reviewer to 
say 'Yes, this does _not_ use a ChangeLog'.

Any strong opinion against this?

Kai

> -Original Message-
> From: Schumann, Spencer [mailto:spencer.schum...@echostar.com]
> Sent: Thursday, January 26, 2017 5:11 PM
> To: Kai Koehne <kai.koe...@qt.io>; Oswald Buddenhagen
> <oswald.buddenha...@qt.io>; development@qt-project.org;
> releas...@qt-project.org
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
> 
> 
> > For the sanity bot, either we decide that _every_ change has a
> > [ChangeLog], or we try to make the bot intelligent
> 
> > enough to decide whether a commit needs a change log, or not. Parts of
> > the discussion so far makes me think
> 
> > that this will be an uphill battle though.
> >
> > So, any strong opinion against enforcing a [ChangeLog] line, with
> "[ChangeLog] -" for commits that don't need one?
> 
> I doubt the decision on whether a changelog is needed could be adequately
> automated. Sometimes, even a one character change might need a detailed
> changelog.
> 
> Isn't this something that could and should be enforced via the code review
> process? If reviewers see that the changelog is missing or inadequate, they
> can reject the change.
> 
> 
> 
> 
> 
> - Spencer
> 
> 
> 
> 
> From: Releasing <releasing-bounces+spencer.schumann=echostar.com@qt-
> project.org> on behalf of Kai Koehne <kai.koe...@qt.io>
> Sent: Thursday, January 26, 2017 5:28:30 AM
> To: Oswald Buddenhagen; development@qt-project.org; releasing@qt-
> project.org
> Subject: Re: [Releasing] [Development] Change file process & improvement
> proposal
> 
> 
> 
> > -Original Message-
> > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt-
> > project.org] On Behalf Of Oswald Buddenhagen
> > Sent: Thursday, January 26, 2017 12:52 PM
> > To: development@qt-project.org; releas...@qt-project.org
> > Subject: Re: [Releasing] [Development] Change file process &
> > improvement proposal
> >
> > On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote:
> > > I don't know what you're saying, much less why it's supposed to be
> > > the obvious interpretation.  A "tagged commit" is presumably v5.7.0
> > > or similar; why should a commit without an amends line be assumed to
> > > relate to one of these ?
> > >
> > i used "tagged commit" as a shorthand for "a commit which is reachable
> > from a tag", which should be fairly clear from the context. i.e., "git
> > tag --contains " returns something.
> 
> Well, I had a hard time deciphering this, too.
> 
> 
> 
> Anyway, this all feels like we get side-tracked in details. To reiterate:
> 
> - We do (still) have a problem with our ChangeLog files
>   * The quality of the entries, and the scope, greatly differs (between
> modules)
>   * We do have a problem getting them in place on time for a release
> 
> Jani's proposal is to fix parts of this is to encourage committers and 
> reviewers
> to write [ChangeLog] entries as part of the commit. This could be encouraged
> by
> * Enabling the [ChangeLog] line by default in the commit template
> * Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx)
> 
> For the sanity bot, either we decide that _every_ change has a [ChangeLog],
> or we try to make the bot intelligent enough to decide whether a commit
> needs a change log, or not. Parts of the discussion so far makes me think that
> this will be an uphill battle though.
> 
> So, any strong opinion against enforcing a [ChangeLog] line, with
> "[ChangeLog] -" for commits that don't need one?
> 
> Regards
> 
> Kai
> 
> > ___
> > Releasing mailing list
> > releas...@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/releasing
> ___
> Releasing mailing list
> releas...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/releasing
> 

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Kai Koehne]

> -Original Message-
> [...]
> > This also implies that bug fixes should now get pushed to the 5.9
> > branch and we should close the 5.8 branch soon.
> 
> I disagree. Even if you cannot produce releases from 5.8 anymore, that's our
> stable branch. 5.9 isn't stable, yet. If you release 5.9.0, *then* you can 
> close
> 5.8. Do you really want stuff from 5.9 cherry-picked to 5.6?

Why should a patch merged into 5.8 right now be a better candidate to 
cherry-picking than one merged into 5.9? It runs through the same scrunity (CI).

IMO it's actually harmful to keep 5.8 open if we don't intend to make a release 
based on it. We keep the overhead of maintaining and merging multiple branches 
without any benefit.

My 2 cents,

Kai

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

[Development] Using semicolons in JS (QML)

[Kai Koehne]

Hi,

It’s Friday, so time for some bikeshedding ;)


As you might know, the semicolon as a statement separator in JavaScript is 
optional. That is, most of the time you can just separate commands
by newlines. There are a few pathological cases [1] though where a semicolon is 
needed. It seems the JavaScript world is divided on the topic
whether to use semicolons by default though.

Now I do not care that much about JavaScript as a language, but I do care about 
consistency in the Qt documentation and examples. Unfortunately
we didn’t seem to have made a call so far what to prefer. Even our minimal “QML 
coding conventions” at http://doc.qt.io/qt-5/qml-codingconventions.html
feature a semicolon in places, and in others no semicolon.

To make a proposal: Let’s use semicolons in imperative JS parts of QML in our 
examples and documentation.
Apart from being on the safe side regarding some pathological cases, it also 
makes the difference between declarative QML bindings  and
imperative JS code more explicit.

Now I do realize that the right side of QML bindings is actually JavaScript. 
But no, I do not want to propose that now every binding ends with a ‘;’.
A good rule of thumb might be that semicolons should be used inside either 
function X() {} or OnSignalHandler: {} blocks, or in .js files.

Thoughts?

Kai

[1]: See e.g. 
http://benalman.com/news/2013/01/advice-javascript-semicolon-haters/



--

Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

Qt World Summit 2016 | Pier 27, San Francisco, CA
Experience Exponential Potential on October 18-20
www.qtworldsummit.com

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

Re: [Development] [closed] Using semicolons in JS (QML)

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of André Somers
> Sent: Thursday, October 06, 2016 11:11 AM
> To: development@qt-project.org
> Subject: Re: [Development] [closed] Using semicolons in JS (QML)
> 
> So, now we need one of these QUIPs to document the descision if I
> understand it correctly ?

Ideally, yes. But I won't spend the time on writing a full QUIP for QML coding 
conventions, at least not now.

(Though I think there should be one, so if there are volunteers ... ;)

Regards

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

[Development] [closed] Using semicolons in JS (QML)

[Kai Koehne]

Hi,

Alright, to close this thread: It seems the majority agrees that using 
semicolons after JS statement inside a Javascript {} block is a good idea. The 
suggestion is to follow this in new code. Personally, I will point out missing 
; as defects in reviews.

Regards

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Viktor Engelmann
> Sent: Tuesday, October 04, 2016 3:51 PM
> To: development@qt-project.org
> Subject: Re: [Development] Using semicolons in JS (QML)
> 
> Am 30.09.2016 um 17:43 schrieb Shawn Rutledge:
> 
> 
>   Back in Nokia times it was said that we shouldn't use semicolons,
> because it would speed up the parsing [...]
> 
> 
> As someone who has written countless parsers, I *highly* doubt that this is
> actually true. Indenting with tabs was also believed to be *much* slower
> than indenting with spaces (which makes absolutely no sense), and that
> measurement result turned out to be caused by a bug in firebird. I bet this is
> also just an urban legend. Someone probably thought "hey - one less
> character to read - must be faster to load", but as André pointed out, the
> error recovery will most likely cost more than what you save. Unless if the
> behavior is baked into the LR(1) state-graph maybe.
> 
> Also I don't think it is good style to write code that doesn't conform to the
> actual language, just because *most* parsers correctly *guess* what you
> meant *most* of the time (except in those pathological cases...). I think that
> you should *always* tell parsers *precisely* what you mean and don't rely
> on it's guessing ability. For reference: The Mariner 1 crash (which cost $80
> million) was supposedly caused by an error that could have been caught by
> static analysis at compile time, but was just "guessed away" wrongly.
> 
> 
> Anyhow, I believe that we have spent more time on this debate than will
> ever be saved by omitting semicolons.
> 
> 
> Viktor
> 
> 
> --
> 
> 
> 
> Viktor Engelmann
> Software Engineer
> 
> The Qt Company GmbH
> Rudower Chaussee 13
> D-12489 Berlin
> viktor.engelm...@qt.io 
> +49 151 26784521
> http://qt.io
> 
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
>  
>  
> 
> 
> 
> 
>  
> Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential
> Potential on October 18-20
> www.qtworldsummit.com 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Managing branches of Qt's git modules

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Sean Harmer
> Sent: Friday, September 30, 2016 12:39 PM
> To: development@qt-project.org
> Subject: [Development] Managing branches of Qt's git modules
> 
> Hi,
> 
> just a query as to how people do bulk checkouts of different branches when
> working with the Qt git modules. It would be nice to be able to use git
> submodule foreach ... but this is a problem because not all modules use the
> same branching scheme.
> 
> So, what do people do to checkout all interesting modules to 5.7, 5.8, dev etc
> on Unix like systems and on Windows?

  git submodule foreach "git fetch && (git checkout 5.8 || git checkout master) 
"

et voila :) Feel free to append a 

  && git reset --hard @{u} && git clean -fxd

if you want a clean slate. This works also on Windows.

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

Re: [Development] Using semicolons in JS (QML)

[Kai Koehne]

>> To make a proposal: Let’s use semicolons in imperative JS parts of QML in 
>> our examples and documentation
>
> Back in Nokia times it was said that we shouldn't use semicolons, because it 
> would speed up the parsing and reduce the size of resources slightly.  (Maybe 
> you think performance isn’t impacted by small > things like that, but we are 
> at the same time investing effort into other “optimizations” for which I 
> suspect the runtime performance impact may end up being similarly small.)  So 
> I’ve been following the > no-semicolons convention ever since, except 
> occasionally when C++ habits get the better of me.


Interesting. Indeed, I wouldn't have thought it makes any measurable 
difference. IIRC we had a qml mimizer once, I guess this is still around?


> If you think it’s important, then write a reformatter tool and figure out how 
> to use it as a git hook.  We are wasting time bikeshedding about coding style 
> (do you really have nothing better to do?

>  all bugs in Qt are fixed?), and IMO the same argument applies in any kind of 
> code: if there’s no tool to do the reformatting, maybe it’s not so important.


It's certainly not that important to me that I will spend a day on writing a 
git hook that then nobody will use ;) But a lot of programmers (including me) 
tend to care about code style consistency. So I was making a suggestion that 
costs us nothing, but leads to a sllightly more consistent documentation and 
examples in then end. In the same way as I couldn't care less whether to use 
tabs or spaces, or what the right indentation level is, as long as we stick to 
one.


(And yeah, I also enjoy bikeshedding sometimes, be it at the coffee machine or 
on a mailing list, even if not 'all Qt in bugs are fixed". And honestly 
speaking I do not see an issue with this.)


> It’s just subjective and political, and not the kind of argument I’d ever 
> want to start, personally.


Well, it's an entirely voluntary discussion ;)


Kai


From: Development <development-bounces+kai.koehne=qt...@qt-project.org> on 
behalf of Shawn Rutledge <shawn.rutle...@qt.io>
Sent: Friday, September 30, 2016 5:43:57 PM
To: development@qt-project.org
Subject: Re: [Development] Using semicolons in JS (QML)

On 30 Sep 2016, at 14:19, Kai Koehne <kai.koe...@qt.io> wrote:
> To make a proposal: Let’s use semicolons in imperative JS parts of QML in our 
> examples and documentation

Back in Nokia times it was said that we shouldn't use semicolons, because it 
would speed up the parsing and reduce the size of resources slightly.  (Maybe 
you think performance isn’t impacted by small things like that, but we are at 
the same time investing effort into other “optimizations” for which I suspect 
the runtime performance impact may end up being similarly small.)  So I’ve been 
following the no-semicolons convention ever since, except occasionally when C++ 
habits get the better of me.

If you think it’s important, then write a reformatter tool and figure out how 
to use it as a git hook.  We are wasting time bikeshedding about coding style 
(do you really have nothing better to do? all bugs in Qt are fixed?), and IMO 
the same argument applies in any kind of code: if there’s no tool to do the 
reformatting, maybe it’s not so important.  It’s just subjective and political, 
and not the kind of argument I’d ever want to start, personally.

___
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] QCS2016 Session Notes - QUIPs for Qt

[Kai Koehne]

Hi,

I'd like to request a QUIP number for the handling of 3rd party code in Qt 
repositories.

Anyhow, it seems to me that we're stuck currently in the bootstrapping process
of QUIPs:

http://quips-qt-io.herokuapp.com/quip-0003.html

>The minimum QUIP boostrapping process was discussed:
>
>1. Post QUIP 1 to qt-development mailing list for discussion.
>2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has 
>since been made available)
>3. Create new git repository to hold QUIPs

So I'd like to request a gerrit repository for holding QUIPs, .e.g 
codereview.qt-project.org/qt/quips.git .

Regards

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Tero Kojo
> Sent: Monday, September 26, 2016 9:01 AM
> To: Louai Al-Khanji ; development@qt-project.org
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> 
> Hi,
> 
> This initiative is much appreciated, thank you Louai!
> Having been in the session at QtCon, I don't have any problems with the
> proposed format and process as outlined in the initial QUIPS.
> 
> I'd like to request two QUIP numbers "Qt Community Code of Conduct", and
> another one for "Code of Conduct for Qt Events".
> I guess the repo isn't there yet, do we wait on the lazy agreement process
> until it is created?
>
> Tero
> 
> > -Original Message-
> > From: Development [mailto:development-bounces+tero.kojo=qt.io@qt-
> > project.org] On Behalf Of Louai Al-Khanji
> > Sent: tiistai 20. syyskuuta 2016 1.45
> > To: development@qt-project.org
> > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt
> >
> > Hi all,
> >
> > Here are my notes from the QUIPs session. Thank you for your patience.
> > :-)
> >
> > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs.
> >
> > QUIP 1 introduces the general concept:
> >
> >   http://quips-qt-io.herokuapp.com/quip-0001.html
> >
> > QUIP 2 details the Qt governance model, it’s simply the current wiki
> > page converted into a QUIP:
> >
> >   http://quips-qt-io.herokuapp.com/quip-0002.html
> >
> > QUIP 3 is an informational QUIP containing the session notes, which
> > are repeated below:
> >
> >   http://quips-qt-io.herokuapp.com/quip-0003.html
> >
> > The heroku domain is obviously a placeholder.
> >
> > I have also attached the source files for proposed QUIPs 1, 2, and 3
> > to this e- mail.
> >
> > One item left open was licensing of the QUIPs themselves. For these I
> > propose Creative Commons CC0.
> >
> > Any and all feedback welcome.
> >
> > Cheers,
> > Louai
> >
> >  BEGIN NOTES 
> >
> > At the Qt Contributors' Summit 2016 in Berlin a session was held to
> > discuss the idea of introducing QUIPs as a new process for Qt governance.
> >
> > The general idea was introduced by looking at QUIPs 1 and 2, and by
> > looking at some Python PEPs. The general feedback was positive. An
> > attempt was made to identify the minimum set of work required to
> > bootstrap QUIP, which was the main theme of the session.
> >
> > The overall discussion is summarized below, in roughly chronological order.
> >
> > - Discussed background of QUIP, the process and the documents.
> > Referred to
> >   Python and looked at QUIP 1 and QUIP 2 which had been prepared prior
> > to the
> >   session.
> >
> >   - The idea is to have a new git repository with the QUIP text files
> >
> >   - Managed through Qt's normal work flow, currently gerrit code
> > review
> >
> >   - The maintainer of the quips repository takes on required editorial
> > duties
> > - Agreed that the text documents should be limited to 80 character lines.
> >
> > - Agreed that care must be taken to ensure that QUIPs are written in
> > "proper"
> >   English so as to be clear, understandable and concise.
> >
> > - Talked about how a new QUIP is introduced. The most important thing is
> to
> >   reserve a number, which is the identifier of any one QUIP. The title can
> >   change, and is expected to do so from time to time.
> >
> > - New QUIP documents will go through a review process like any other
> > patch to
> >   Qt. The author of the QUIP is responsible for logging this discussion in 
> > the
> >   evolving QUIP itself.
> >
> > - The important thing is to bootstrap the process. Once it is bootstrapped, 
> > it
> >   is possible to fine-tune the QUIP process through QUIPs. It is expected
> that
> >   this will happen.
> >
> > - The question of what goes into a QUIP was discussed. QUIP 1 gives a
> rough
> >   overview of the different kinds of possible QUIPs. It is expected that the
> >   content be further specified in revisions of QUIP 1 or in follow-up QUIPs.
> >
> > - Like any other part of Qt, QUIPs are living documents. They can be
> updated,
> >   amended or entirely superseded by later ones.
> >
> > - QUIP licensing was discussed. Python's PEPs are required to be
> > either placed
> >   in the public 

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, November 09, 2016 4:01 PM
> To: development@qt-project.org
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> 
> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote:
> > +1 for qt/quips, I don't think of it as a web site thing either.
> >
> well, i don't want it in qt/ - this is not a generic namespace for stuff that
> doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git
> (with an accurate status field), or be a submodule of an aggregated module.
> 
> i can offer meta/ as an alternative.

meta/quips would work for me, too. or qt-project/quips?

> or maybe qtqt/ - that one already exists, but i suspect the objections will be
> the same as to www/.

No idea what qtqt/ should stand for :)

> > Kai Koehne wrote:
> > > I'd slightly prefer
> > >
> > > qt/quips
> > >
> > > because it's not directly related to the website, even if we'll
> > > generate an html presentation out of it. We might even consider
> > > adding it to qt/qt5.git at one point ...
> >
> that makes no sense to me at all. the scope if this is certainly wider than 
> the
> qt product itself.

Why do you think so? This is the repository where we want to document processes
and design decisions for Qt, the project _and_ the product. It's surely more 
meta than
most of the modules, but we've also projects like qt/qtqa and qt/qtrepotools, 
which 
do not contain a qt module, either. 

Regards

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

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Tuesday, November 08, 2016 11:15 AM
> To: development@qt-project.org
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> 
> On Tue, Nov 08, 2016 at 09:11:23AM +, Lars Knoll wrote:
> > Yes, let’s get the repo created and this whole thing off the ground.
> >
> so, anyone has a concrete proposal for a fully qualified repository name?
> www/quips?

I'd slightly prefer

  qt/quips

because it's not directly related to the website, even if we'll generate an 
html presentation out of it. We might even consider adding it to qt/qt5.git at 
one point ...

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

Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Egor Pugin
> Sent: Wednesday, November 09, 2016 10:55 PM
> To: Harald Vistnes 
> Cc: development@qt-project.org
> Subject: Re: [Development] Problems compiling QtWebEngine in 5.8.0 beta
> 
> Probably file path is too long.
> MS improved situation since win10.1607 (up to 32k symbols) but almost
> every program today (even from MS) is not able to handle such paths.
> They require special handling.
> See https://msdn.microsoft.com/en-
> us/library/windows/desktop/aa365247(v=vs.85).aspx
> for more info.

Sigh. We've been tweaking webengine already in the past to use relative paths,
but it  seems we didn't succeed everywhere.

Yeah, please make sure that the checkout path for qtwebengine is not too deep.

Reggards

Kai


> I had same issues with cmake+msbuild invocations.
> 
> On 9 November 2016 at 23:46, Harald Vistnes 
> wrote:
> > Hi,
> >
> > I'm having problems compiling 5.8.0 beta from source. It fails when
> > making qtwebengine.
> >
> >
> > D:\qt-everywhere-opensource-src-5.8.0-
> beta\qtwebengine\src\3rdparty\ni
> > nja\ninja.exe
> > -C
> > D:/qt-everywhere-opensource-src-5.8.0-
> beta/qtwebengine/src/core/Releas
> > e_x64
> > ninja: Entering directory
> > `D:/qt-everywhere-opensource-src-5.8.0-
> beta/qtwebengine/src/core/Release_x64'
> > ninja: error:
> >
> WriteFile(obj\src\3rdparty\chromium\third_party\WebKit\Source\core\gen
> \blink\bindings\core\v8\webcore_generated.HTMLImageElementOrHTMLVi
> deoElementOrHTMLCanvasElementOrBlobOrImageDataOrImageBitmap.obj.
> rsp):
> > Unable to create file. No such file or directory
> >
> > ninja: build stopped: .
> > NMAKE : fatal error U1077:
> > 'D:\qt-everywhere-opensource-src-5.8.0-
> beta\qtwebengine\src\3rdparty\ninja\ninja.exe'
> > : return code '0x1'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 14.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '(' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: 'cd' : return code '0x2'
> > Stop.
> >
> > Environment:
> > Windows 10
> > VS2015 x64
> > Windows 10 SDK
> > ninja
> >
> > Any help would be appreciated.
> >
> > Thanks,
> > Harald
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> 
> 
> 
> --
> Egor Pugin
> ___
> 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] OpenGL Issues in Qt5.7

[Kai Koehne]

> -Original Message-
> From: Liu, Jeff (SRDC SW) [mailto:jeff1@amd.com]
> Sent: Wednesday, October 26, 2016 7:09 AM
> To: gunnar.sle...@jollamobile.com; gun...@sletta.org; Liang Qi
> <liang...@qt.io>; Kai Koehne <kai.koe...@qt.io>; development@qt-
> project.org
> Subject: RE: OpenGL Issues in Qt5.7
> 
> 
> 
> Spread to Qt mail-list to ask for help.
> 
> 
> 
> From: Liu, Jeff (SRDC SW)
> Sent: Tuesday, October 25, 2016 2:26 PM
> To: 'gunnar.sle...@jollamobile.com'; 'gun...@sletta.org'; 'liang...@qt.io';
> 'kai.koe...@qt.io'
> Subject: OpenGL Issues in Qt5.7
> 
> 
> 
> Hi Sletta, Qi and Koehne,

Hi Jeff!

> This is Jeff from AMD, recently a customer reports a game issue with AMD
> cards, but the game runs well on Nvidia card, after some debug, I find out
> that the issues are caused by Qt libraries, when Qt programs with OpenGL
> API, it doesn’t follow the OpenGL programming specification strictly, so it 
> will
> report errors on AMD platform.
> 
> Now we find out the two following issues, both issues come from Qt paint
> engine.
> 
> 1.   QTBUG-56234 - OpenGL glVertexAttribArray API usage error in
> Qt5Guid.dll
> 
> I submit a ticket to address this issue, and this issue is assigned to 
> Sletta, but
> it seems no one starts to work on it, the usage of glVertexAttribArray API is
> wrong, it is still used in the old way (OpenGL 3.0), but it apparently 
> violate the
> latest OpenGL specification (OpenGL 4.1)

Liang already commented on this one. Laszlo (the new assignee) probably
has a better idea about this, too.

> 2.   I don’t submit the ticket for the second issue yet,  Qt paint engine 
> uses
> GL_RED to upload the texture, so based on the spec, the texture will be
> (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a
> constant 0 value in AMD platform, if changed to src * mask.r, then everything
> will be correct, I will submit a ticket to address it later.

Feel free to report this, too.

> I don’t know what’s the right way to report and fix Qt issues, there may be
> more issues later in the game, so I write an email to you guys (I find your
> emails from code.qt.io), please tell me what should I do to co-work with you
> and make these issues fixed.

Reporting them on bugreports.qt.io is certainly a good start :) If you're a
commercial customer you should also go through Qt Support - often enough
the support team can help directly, or escalate things.

Regards

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

Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Konrad Rosenbaum
> Sent: Tuesday, November 29, 2016 11:03 AM
> To: development@qt-project.org
> Subject: Re: [Development] Proposal: Use -qt-zlib configuration in official
> MinGW builds
> 
> Hi,
> 
> On Monday 28 November 2016 17:11:19 Konstantin Tokarev wrote:
> > Currently, MinGW builds in Coin use -system-zlib configuration. It
> > happens because MinGW is shipped with zlib headers and libz.a.
> > However, linking zlib to several Qt modules (at least, QtCore, QtGui,
> > QtNetwork, and QtSvg) is suboptimal, while with -system-zlib one copy
> > in QtCore is shared between all modules.
> 
> Please be aware that there are quite a few Applications out there that use
> zlib independently of Qt - e.g. to encode/decode ZIP files. Unfortunately Qt
> does not expose its internal zlib headers, nor does it wrap all functionality 
> of
> zlib. So at the very least qt-zlib needs to be linked in a way that allows an
> additional version of zlib to be linked.

This shouldn't be a problem, because the symbol ones from the internal version
are prefixed with "z_". See change 1f461ac45bf in qtbase.

Regards

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

Re: [Development] Proposal: Use -qt-zlib configuration in official MinGW builds

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Konstantin Tokarev
> Sent: Monday, November 28, 2016 3:11 PM
> To: development@qt-project.org
> Subject: [Development] Proposal: Use -qt-zlib configuration in official
> MinGW builds
> 
> Hello,
> 
> Currently, MinGW builds in Coin use -system-zlib configuration. It happens
> because MinGW is shipped with zlib headers and libz.a. However, linking zlib
> to several Qt modules (at least, QtCore, QtGui, QtNetwork, and QtSvg) is
> suboptimal, while with -system-zlib one copy in QtCore is shared between all
> modules.

I think this is a good idea.

Could you create a suggestion for this on bugreports.qt.io, component 
"Packaging & Installer" (https://bugreports.qt.io/browse/QTBUG/component/19211) 
?

Thanks

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

Re: [Development] qtwebkit

[Kai Koehne]

Have you tried running qmake && jom (or nmake) manually inside the qtwebkit 
source directory?

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Harald Vistnes
> Sent: Friday, December 16, 2016 9:55 AM
> To: development@qt-project.org
> Subject: [Development] qtwebkit
> 
> Hi,
> 
> is it still possible to build the qtwebkit module manually in 5.8.0? I've 
> tried
> fetching the sources from git, but qtwebkit is not built. I guess I have to
> change some build scripts since it is obsolete, but I am not sure what needs
> to be done.
> 
> Here is what I did
> 
> git clone git://code.qt.io/qt/qt5.git  cd qt5 
> perl
> init-repository --module-subset=all,-ignore,-qtwebkit-examples,-
> qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-qtdatavis3d,-
> qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-qtdoc
> git checkout 5.8.0
> 
> configure -prefix %CD%\qtbase -opensource -shared -confirm-license -
> debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle -qt-
> libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip
> qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard -skip
> qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip
> qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -nomake tests
> 
> I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro 
> (line 29), but that did not help.
> 
> I'm on Windows 10 with VS2015. I've built qtwebkit before, so I think I have
> all dependencies installed.
> 
> What am I missing?
> 
> Thanks,
> Harald
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] qtwebkit

[Kai Koehne]

> -Original Message-
> From: Harald Vistnes [mailto:harald.vist...@gmail.com]
> Sent: Friday, December 16, 2016 10:01 AM
> To: Kai Koehne <kai.koe...@qt.io>
> Cc: development@qt-project.org
> Subject: Re: [Development] qtwebkit
> 
> Yes, nothing happens.

So there's no output from qmake? Have you checked that the webkit sources are 
actually there?

Either qmake should end with an error indicating unmet dependencies. Or 
jom/nmake with a compile error ...

Kai

> Harald
> 
> 2016-12-16 9:59 GMT+01:00 Kai Koehne <kai.koe...@qt.io
> <mailto:kai.koe...@qt.io> >:
> 
> 
>   Have you tried running qmake && jom (or nmake) manually inside
> the qtwebkit source directory?
> 
>   Kai
> 
>   > -Original Message-
>   > From: Development [mailto:development-bounces+kai.koehne
> <mailto:development-bounces%2Bkai.koehne> =qt.io@qt-
>   > project.org <http://project.org> ] On Behalf Of Harald Vistnes
>   > Sent: Friday, December 16, 2016 9:55 AM
>   > To: development@qt-project.org <mailto:development@qt-
> project.org>
>   > Subject: [Development] qtwebkit
>   >
>   > Hi,
>   >
>   > is it still possible to build the qtwebkit module manually in 5.8.0?
> I've tried
>   > fetching the sources from git, but qtwebkit is not built. I guess I
> have to
>   > change some build scripts since it is obsolete, but I am not sure
> what needs
>   > to be done.
>   >
>   > Here is what I did
>   >
>   > git clone git://code.qt.io/qt/qt5.git <http://code.qt.io/qt/qt5.git>
> <http://code.qt.io/qt/qt5.git> cd qt5 perl
>   > init-repository --module-subset=all,-ignore,-qtwebkit-examples,-
>   > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-
> qtdatavis3d,-
>   > qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-
> qtdoc
>   > git checkout 5.8.0
>   >
>   > configure -prefix %CD%\qtbase -opensource -shared -confirm-
> license -
>   > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-
> angle -qt-
>   > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors 
> -skip
>   > qtwayland -skip qtserialbus -skip qtserialport -skip
> qtvirtualkeyboard -skip
>   > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip
>   > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -
> nomake tests
>   >
>   > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro
> <http://qt.pro>  <http://qt.pro>
> 
>   > (line 29), but that did not help.
>   >
>   > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I
> think I have
>   > all dependencies installed.
>   >
>   > What am I missing?
>   >
>   > Thanks,
>   > Harald
> 
> 

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

[Development] Rules for Third-Party components in Qt 4.8 onwards

[Kai Koehne]

Hi,

I'd like to put down the rules on how we handle code in Qt that we as Qt 
contributors do not have copyright over ourselves in a QUIP:

https://codereview.qt-project.org/#/c/177201/6/quip-0004.txt

I suggest that
- Every third party component must be documented by a qt_attribution.json file
- Adding a third-party component that will become part of a Qt library, plugin 
or tool needs approval by the Chief Maintainer
- Third-party components that become part of a Qt library, plugin, or tool need 
to be mentioned in the change log of the release in a [Third-Party Code] area.

Regards

Kai

-- 
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

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

Re: [Development] Rules for Third-Party components in Qt 5.8 onwards

[Kai Koehne]

Hi,

(I'll try to answer some comments made in the gerrit review here. IMO gerrit
works great for editorial stuff, but not for more substantial things).

> [Tobias Hunger]
> I would make the homepage mandatory in the attribution file. That information 
> is critical IMHO when you want to find out more about that piece of code.

If there's a homepage, by all means, specify the "Homepage" property. I didn't 
make it mandatory though because we have code where there's just no legitimate 
upstream homepage, most often because Qt itself is the 'upstream'. Putting 
"www.qt.io" here would be possible, but also confusing ;) That's e.g. the case 
for some of the text codes, like 
http://doc-snapshots.qt.io/qt5-5.8/qtcore-attribution-qtsciicodec.html. 

> I would also suggest to add something about giving the exact revision of the 
> code (full download link, repo where the code came from and exact version 
> specification in that repo) in the commit message when initially > importing 
> the code or when updating it. For my taste it is currently too hard to find 
> out which exact versions of stuff we use.

It is very important to track the upstream version used, so that we can easily 
see when something is outdated and track custom changes done before it's 
imported.

You should not only put that in the commit message though. In 
qt_attribution.json file you should set a 'Version' field that you should set 
to the official property. This could also be e.g. an SHA if there's no marked 
upstream version. In addition, you should set the 'DownloadLocation' field that 
should link to the upstream package / installer / ...  

When creating the initial qt_attribution.json files, I was adding this 
information when it was obvious, but I didn't do much due diligence. I'd 
appreciate it if contributors/maintainers would complete the information 
wherever possible.

> [Robin Burchell on Copyright field being mandatory]
> Having the license for instance as mandatory seems quite reasonable, but I'm 
> less certain about this. Keeping it maintained could be quite a burden, and 
> for complex software I can imagine it ending up quite long. Does > it have 
> significant value? What's the purpose of it?
> 
> For example, I looked at another project I've been a significant part of, 
> started around 2002, with a fairly constant stream of random contributors. 
> There are 135 unique "Copyright" lines throughout the source, 
> although a number of these are duplicated authors with different year 
> information. The most frequently repeated lines are repeated >100 times.

I'm a bit unsure about the extra 'Copyright' field myself, especially if it 
duplicates the Copyright in the license file (like it is for the BSD licenses). 
I added it because it's sometimes requested by customers, and is also part of 
e.g. the SPDX and debian/copyright specifications [1,2].

In general, the copyright field shows the user a) when the copyright protection 
might run out and b) whom to contact in case one has questions. Also, even if 
not strictly required by some licenses, it is also acknowledging the original 
authors. So, I do think it adds value, also to the documentation.

In practical terms, often bigger projects tend to have generic acknowledgements 
like

  Copyright  the  authors

or 

  Copyright  the  and contributors

If that is done upstream, it obviously is the right thing to keep it like that 
in the qt_attribution.json file, too. I can try to find out whether it's also 
ok to consolidate on our own.

So, in summary, I'd keep the field mandatory, potentially consolidating it to 
one name. If the Copyright is also part of the License text itself (like for 
the typical BSD license), I've duplicated the lines in the past.

If we decide to keep it this way, I can try to clarify it in the QUIP.

[1]: https://spdx.org/spdx-specification-21-web-version#h.2grqrue
[2]: 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field

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

Re: [Development] Qt 5.9

[Kai Koehne]

> Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and if
> possible to 5.8 too.


The deal is that we don't want to increase the number of packages

in total.


Personally, I don't see the qualms with switching to 64 bit for MinGW

instantly. For MinGW, there are hardly any binary-only libraries that you

can't recompile, and the use case where you ship a 32 bit MinGW plugin

for an executable that is compiled with MSVC sounds a border case

to me. Also, I doubt that MinGW is popular on the embedded devices

that still might be 32 bit only.


Finally, the MinGW community is very active in shipping latest Qt in

their installers, so if you really need 32 bit you could still use binary

packages from the MSYS2 repositories.


Anyhow, the argument also goes the other way round: If we don't like

to drop 32 bit, we can advise people to use MSYS2 packages. I don't

have strong opinions about which one to prefer, but I do think that

not adding more packages is a good restriction.


My two cents


Kai



From: Development  on 
behalf of Thiago Macieira 
Sent: Wednesday, November 30, 2016 8:28:51 AM
To: development@qt-project.org
Subject: Re: [Development] Qt 5.9

On quarta-feira, 30 de novembro de 2016 07:15:31 PST Alexander Blasche wrote:
> The big problem is that there are still plenty of 32bit users because they
> truly use 32bit platforms or 3rdparty software forces them to do so. Moving
> to 64 bit excludes users without alternatives. 32 bit does not exclude.
> Yes, I know this is a chicken and egg problem but right now we have reduced
> the 32bit package count for 5.9 already. Let's not rush too much.

Then let's not drop the 32-bit mingw. But we should add the 64-bit one, and if
possible to 5.8 too.

> There are already 11 windows binary types/packages in the current setup and
> that's too many. I see some opportunity when 2013 drops out in the future.

How are there 11? There are currently 3 compilers and 2 architectures for
desktop Windows, so the maximum number possible is 6.

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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Development Info Page - 
Qt
lists.qt-project.org
To see the collection of prior postings to the list, visit the Development 
Archives. Using Development: To post a message to all the list members ...


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

[Development] QUIP-7: qt_attribution.json File Format

[Kai Koehne]

Hi,

This is a heads-up that I've moved parts of QUIP-4 (Third-Party Components in 
Qt) a while ago into a separate Implementation QUIP. The details about the 
qt_attribution.json file format are now described in proposed QUIP-7:

https://codereview.qt-project.org/#/c/147271/

Comments welcome, both for the document as well as the format itself :)

Kai

-- 
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

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

Re: [Development] QUIP-7: qt_attribution.json File Format

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Kai Koehne
> Sent: Friday, March 24, 2017 12:25 PM
> To: development@qt-project.org
> Subject: [Development] QUIP-7: qt_attribution.json File Format
> 
> Hi,
> 
> This is a heads-up that I've moved parts of QUIP-4 (Third-Party Components
> in Qt) a while ago into a separate Implementation QUIP. The details about
> the qt_attribution.json file format are now described in proposed QUIP-7:
>
> https://codereview.qt-project.org/#/c/147271/

Copy/paste error. Correct link is

https://codereview.qt-project.org/#/c/185792/

Sorry about this

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

Re: [Development] Who's responsible for 3rdparty these days (QTBUG-59586)?

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Sunday, March 19, 2017 8:01 PM
> To: development@qt-project.org
> Subject: [Development] Who's responsible for 3rdparty these days (QTBUG-
> 59586)?
> 
> The rules are that only Qt Company people can import 3rdparty code, so I
> know I am not responsible.

I don't think this is the case. Every contributor can upload patches with new 
third party code, as long as this is properly documented.

Only maintainers are allowed to approve them though, and if you want to add new 
third party code to the Qt libraries, tools or plugins you need an approval by 
Lars.

Not formally approved yet, but QUIP-4 explicitly states the rules:

https://codereview.qt-project.org/#/c/177201/

Regards

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

Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Marc Mutz
> Sent: Tuesday, April 11, 2017 2:25 PM
> To: development@qt-project.org
> Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch
> releases during H1/17
> 
> On Tuesday 11 April 2017 13:52:36 Tuukka Turunen wrote:
> > > On 11/04/2017, 14.43, "Konstantin Tokarev" 
> wrote:
> > >   Maybe it's plausible to make 5.8.1 release just for QtBase?
> >
> > No. That is not possible. This has also been discussed before.
> 
> Yes, it is possible, you've done it before. And no, it has not been 
> "discussed".
> I raised the question, and no-one answered.

When did we ever do a release of qtbase, without any other modules? 

> Why this semblance of a discussion, anyway? Why don't you just go ahead
> and pull the plug on 5.8?

Because _you_ started the discussion again. Tuukka just suggested to execute 
the decision we've made weeks ago now.

> It's not like the Qt Project (or what's left of it) has
> any say in this, you made that abundantly clear in the past.

Lars as Chief Maintainer sent out a mail about this, so this is the official 
stance of the Qt Project on this.

Seriously, can we please move on? This is in no way productive.

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

Re: [Development] syncqt.pl in C++

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Richard Moore
> Sent: Tuesday, March 07, 2017 10:44 PM
> To: Lars Knoll 
> Cc: Thiago Macieira ; Qt development mailing
> list 
> Subject: Re: [Development] syncqt.pl in C++
> 
> 
>   You're right. My wording above was misleading, I wasn't present
> myself. This is what I remembered people telling me afterwards.
> 
>   Here are the session notes:
> https://wiki.qt.io/Qt_build_systems_at_QtCon_2016
> 
> 
> ​Yep, there's also a video. 

I was hosting this session. I don't think it was recorded.

> My recollection is that there was a small vocal group
> of people pushing qbs, but that they couldn't demonstrate any actual
> advantages it had. They offered a few up, but it turned out that people had
> already done that using other tools such as cmake. ​I think the only 
> conclusion
> was that qmake is weak and that the maintainers want to stop maintaining it.

I take the blame for not preparing the session properly then. Anyhow, it was 
never intended as a decision forum in the first place.

Take this as a statement of intent. The maintainer of the Qt build system 
(Ossi) and also the qbs developers (Joerg, Christian, Jake) would like to 
switch to qbs for building Qt in the mid-term, and we have the backing of the 
Chief Maintainer (Lars) for pushing this forward. The Qt Company sees the value 
in doing so, and is therefore resourcing this.

We've been internally evaluating what's needed to get there, and will propose 
concrete steps on this mailing list at the appropriate time. We can have (and 
for sure will) have another round of discussions about whether cmake isn't the 
better alternative then. Anyhow, keep in mind that the Qt Project isn't a 
democracy, so don't expect a formal poll or so.

Regards

Kai

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

Re: [Development] QT 5.9. Issues with QWebEngine

[Kai Koehne]

Hi Sudhir,

This is best discussed on bugreports.qt.io, in a bug report for component 
"WebEngine" in project "Qt". 

Please include on how you want to set a (non-local) proxy:
- through the system settings or
- through QNetworkProxy::applicationProxy

Regards

Kai

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Sudhir Sharma
> Sent: Mittwoch, 12. Juli 2017 12:18
> To: development@qt-project.org
> Subject: [Development] QT 5.9. Issues with QWebEngine
> 
> HI,
> 
> 
> 
> QWebEngine does not take exact proxy settings from System (as done in
> internet browsers like Chrome)
> 
> Internet client is configured to use proxy for internet addresses and bypass 
> it
> for local addresses.
> 
> 
> 
> But it does not happen. QWebEngine fails to bypass proxy for local urls.
> 
> 
> 
> Scenarios:
> 
> 
> 
> -  Remove proxy in Browser. -> webengine is able to load local urls 
> but
> NOT internet URLs
> 
> -  Add proxy in browser -> webengine is able to load  internet URLs 
> but
> NOT local URLs
> 
> -  If I set the proxy in browser and check to ignore local addresses,
> browser works fine for both local and internet addresses. I am expecting
> same functionality from QWebEngine.
> 
> 
> 
> Please suggest if it is possible.
> 
> 
> 
> Regarsds,
> 
> Sudhir
> 
> 
> 
> 
> 
> 
> 
> 
> 
> http://www.mindtree.com/email/disclaimer.html

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

[Development] Give reviewers ample time to respond

[Kai Koehne]

Hi,

I'd like to remind everyone about our commit policy: 
https://wiki.qt.io/Review_Policy . In particular, it says 'Give reviewers ample 
time to respond', which is assumed to be a full working day minimum (preferably 
two days). 

That is, even if you have a +2 by an approver, you should _not_ stage 
immediately if there are other reviewers who haven't given feedback yet.

Regards

Kai

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

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

[Development] Please add [ChangeLog] entries to your commits!

[Kai Koehne]

Hi,

I just noticed that, out of the 61 commits in qtbase/5.9 that are not part of 
5.9.0, only one has a [ChangeLog] entry. 

Some of the commits are either changes to doc, or autotests, but for the rest: 
If it is not important enough to be mentioned to the user, why is the change in 
5.9?

Please be reminded that all changes that might be of interest to the end user 
should be part of the ChangeLog.  So please, whenever reviewing a change, 
please check whether a [ChangeLog] entry is in order.

Thanks

Kai

--
Kai Köhne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Please add [ChangeLog] entries to your commits!

[Kai Koehne]

> -Original Message-
> From: Mitch Curtis
> Sent: Monday, May 29, 2017 3:27 PM
> To: Kai Koehne <kai.koe...@qt.io>; development@qt-project.org
> Subject: RE: Please add [ChangeLog] entries to your commits!
> 
> > [...]
> > Please be reminded that all changes that might be of interest to the
> > end user should be part of the ChangeLog.  So please, whenever
> > reviewing a change, please check whether a [ChangeLog] entry is in order.
> 
> Do we have a set of guidelines for what is considered interesting?

I'd say anything that changes observable behavior of existing features, or new 
features.

Should get a [ChangeLog]
- new features
- fixes for bugs in released versions of Qt

Can be ignored:
- fixes in tests
- doc fixes
- pure code cleanup
- fixes for regressions introduced in not-yet-released commits

Regards

Kai 

(who considers starting a QUIP about this ...)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Coding style and C++11

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Gatis Paeglis
> Sent: Monday, September 18, 2017 12:43 PM
> To: André Hartmann ; development@qt-project.org
> Subject: Re: [Development] Qt Coding style and C++11
> 
> > I'd like to push this discussion, because if code is converted to a
> > new base, it should be clear to everyone HOW to do so.
> 
> I agree regarding consistency. If we are spending time on this, then it should
> be done properly. I think Qt Coding Conventions wiki should be moved to
> somewhere where changes can be reviewed via Gerrit.

We've a place for this: QUIPs.

http://quips-qt-io.herokuapp.com/

These can be properly reviewed and also finally approved, so having a coding 
style QUIP (for code inside Qt) there would be a good thing.

Kai 

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

Re: [Development] Future of QBS

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> Subject: Re: [Development] Future of QBS
> 
> Hi Jake,
> 
> to use your version control picture: Are we trying to sell subversion by
> showing how great that is compared to CVS and RCS, while git is just getting
> introduced into the market?
> 
> I am still missing a comparison of qbs and *current* build system options. 
> All I
> see is qbs vs. qmake and qbs vs. cmake 2.x. Neither qmake nor cmake is
> what qbs will be competing with by the time it is ready to be used in earnest.

Why do you think Qbs cannot be already used today 'in earnest'?

But yeah, switching Qt isn't something that will happen overnight.
 
> So far we excluded most possible build systems on the grounds that they do
> not support the mixed host/target builds we do. That requirement is going
> away. So we have more options now. Just to name two: Bazel promises great
> scalability and reliability, meson claims to be simple and fast. Even CMake
> made a lot of progress since version 2.x.

At this point in time I'm afraid this will bring us directly into the 'curse of 
choice' dilemma [1]. The best way to make sure we stay on qmake for the 
foreseeable future is to bring up more and more alternatives to the table, and 
all consider them as equal contenders.

I think it was actually Jake who asked about Meson @ the Qt Con. The only one 
in the room who claimed to have any experience were you, and you said 'you 
played with it'. Which aspect of Meson do you suggest to look into specifically?

We've been investing into qbs since a while, and have been open about our plans 
for building Qt itself with it. Even if there is no official decision by the Qt 
Project to switch yet (and I think this can only be done once we have a full 
port working), I think it's only fair for the people involved to acknowledge 
that qbs is the most likely contender. So, if someone cares about the Qt build 
system, I suggest to at least try out qbs, and provide feedback, especially if 
you have experience with other build systems.

> I would also appreciate getting some numbers to back up the claims made
> about qbs.

Which claims specifically?

Kai
 
[1]: https://www.psychotactics.com/the-curse-of-choice/ . Yeah, just the first 
search hit ...
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Speeding up the review process (was: PostgreSQL cross compile for Pi)

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Martin Smith
> [...]
> I am a member of the Qt documentation team, and I am often included as a
> reviewer for code changes that also include changes to qdoc comments. I
> always assume I am meant to review only the documentation, so if the
> documentation is ok, I give the change a +1 and add a comment that I only
> reviewed the documentation.
> 
> Is this the right way to do it? Maybe it should be formalized in the system.

Yes, I think this is the right way. 

Writing the comment is the key here. We just have -2, -1, +1, +2 available, so 
a '+1' can mean everything from 'I had barely a look' to 'I just checked parts 
of it' to 'I think the patch is flawless, but just maybe someone else wants to 
review it, too' .

So, given the limited options, let's just state explicitly what you mean when 
giving a review. While at it, consider also to mention positive things, so 
people don't feel like they only ever get negative feedback.

My 2 cents,

Kai

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

Re: [Development] Repository Request: qt/licensing

[Kai Koehne]

> -Original Message-
> [ ..]
> Would it perhaps be possible for configure to just look in "well known"
> locations in the system where the online installer can place them (or place a 
> file
> that contains the path to licheck) ?

That's a good idea, though the online installer has always been optional. But 
yeah,
we can make this easier for this setup then.

> > then all we have to add to qtbase is the .release-timestamp file to
> > mark the date of a release.
> 
> Can you determine the time of the release from the release tag perhaps? git
> describe can be used to find the "nearest" tag and the tag has a date.

Maybe, I'll need to study this a bit more. For now, adding the 
.release-timestamp just looked the most straighforward solution to me.

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

Re: [Development] Repository Request: qt/licensing

[Kai Koehne]

> -Original Message-
> [...]
> Can .pro files test for commercial vs. oss licenses?  If so, and you create a 
> non-
> Qt project repo, couldn't some .pro in qtbase retrieve licheck, like QtCreator
> does here: http://code.qt.io/cgit/qt-creator/qt-
> creator.git/tree/qtcreator.pro#n123?
> 
> Is that an acceptable solution?  Seems like it would work here, although I 
> think
> the time stamp generation and commercial licenses would need to be added to
> qtbase (I think).

Thanks, that's actually an interesting idea. Obvious downside is that you need 
network access ... but you can argue that, if people are using git, they most 
likely have it 

Alright, seems I need to get back to the drawing board and experiment a bit. 
The suggestions for getting the licheck executables distributes so far are

- host the licheck executables outside of a qt-project.org repository, and let 
users clone it from there
- let them be downloaded by the online installer
- fetch them via qmake 

I'll look into each one of them. Meanwhile, consider the request for the 
repository withdrawn for now.

Thanks

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

[Development] Repository Request: qt/licensing

[Kai Koehne]

Hi,

I'd like to request the creation of a repository "qt/licensing" on 
codereview.qt-project.org. This will become an optional git submodule of qtbase 
(checkout: qtbase/licensing). 

The repository will contain the Licenses and binary files (licheck*) that are 
so far only in our commercial source packages. The goal is to allow proper 
commercial builds from git, see also 
https://bugreports.qt.io/browse/QTBUG-5.

As such, the repository should be readable by everyone, but write access should 
be limited to The Qt Company.

Kai

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

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

Re: [Development] Repository Request: qt/licensing

[Kai Koehne]

> As such, the repository should be readable by everyone, but write access 
> should be limited to The Qt Company.
>
> I don’t understand how would that solve the issue.  Wouldn’t this repo need 
> to be cloned and then (somehow) merged with qtbase?

Yes, it would be a git submodule of qtbase.


> If public

> read/download access if not a concern, wouldn’t it make more sense to just 
> add licheck and the licenses to qtbase repo?


That would indeed be the easiest. I proposed a separate submodule because
a) binary checkins will blow up repository content over time, which we should 
avoid for central modules like qtbase.

b) people that want to just use the opensource version or a tech preview 
version can just ignore the submodule.


Alternatively, the submodule can also be a qt5.git submodule, instead of a 
qtbase one. The logic in qtbase could still locate a repository relative to 
qtbase.


Kai


From: Stottlemyer, Brett (B.S.) <bstot...@ford.com>
Sent: Friday, May 18, 2018 4:45:20 PM
To: Kai Koehne; development@qt-project.org
Subject: Re: [Development] Repository Request: qt/licensing

On 5/18/18, 10:36 AM, "Development on behalf of Kai Koehne" 
<development-bounces+bstottle=ford@qt-project.org on behalf of 
kai.koe...@qt.io> wrote:

Hi,

I'd like to request the creation of a repository "qt/licensing" on 
codereview.qt-project.org. This will become an optional git submodule of qtbase 
(checkout: qtbase/licensing).

The repository will contain the Licenses and binary files (licheck*) that 
are so far only in our commercial source packages. The goal is to allow proper 
commercial builds from git, see also 
https://bugreports.qt.io/browse/QTBUG-5.

As such, the repository should be readable by everyone, but write access 
should be limited to The Qt Company.

I don’t understand how would that solve the issue.  Wouldn’t this repo need to 
be cloned and then (somehow) merged with qtbase?  If public read/download 
access if not a concern, wouldn’t it make more sense to just add licheck and 
the licenses to qtbase repo?

Brett

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

Re: [Development] Repository Request: qt/licensing

[Kai Koehne]

> From: Development  on 
> behalf of Thiago Macieira 

>
> Is the source code for licheck going to be added to the repository?

No, I'd only add the binaries.

> If not, then the binary cannot be added to the a Qt Project repository.

With "Qt Project repository" I guess you mean any git submodule of qt5.git, and 
further submodules? Or is this just the hosting on codereview.qt-project.org 
that you're concerned about?

Just for clarification: The official source packages contain the licheck 
executables already. My aim is that a git checkout and the source packages we 
provide contain the very same content.

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

[Development] Changing maintainership for Qt Creator modules

[Kai Koehne]

Hi,

I haven't actively worked on Qt Creator since a while, and would therefore like 
to step down as the maintainer for the Qt Creator modules I'm still listed for 
in https://wiki.qt.io/Maintainers:


Debugging & Profiling / QML 

I propose Ulf Hermann <ulf.herm...@qt.io> as replacement.


Project Management & Targets / QML 

I propose Thomas Hartmann <thomas.hartm...@qt.io> as replacement.


Regards

Kai

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

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

Re: [Development] Did we have to remove cmake's qt5_use_modules?

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> The Qt promise is to maintain not only source code, but upward binary
> compatibility until a major version.
> 
> When said promise is broken immediately after a major version release, as it
> was the case just after Qt5 release to fix an oversight, this is not harmful.
> 
> When it happens years after release, and this is indeed the case here for
> deprecated modules, and was also the case with the switch away from Webkit,
> it can be a major problem not just for distributions, but for many projects 
> that
> depend on it and did not budget a major change.

Overall I do think we're on the very conservative side when it comes to 
removing things. We're still dragging modules along that were deprecated in Qt 
5.0 already ... Qt WebKit was somewhat special in that a) it was quite big, and 
b) it's often used in a security critical setup. But eventually Konstantin 
volunteered to revive qtwebkit, so I guess it's ok now?

> To maintain source and binary compatibility, deprecated modules should not
> be removed until QT6. I do not even understand why there is a debate about
> this.

Note that the case in question is about deprecated functionality in the build 
system, not about removing any Qt modules. So the BC guarantee doesn't apply 
here. 

Kai

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

Re: [Development] Using Native web view on OS X

[Kai Koehne]

> Am I correct in understanding that you are saying that prebuilt Qt packages 
> cannot be used to submit to the app store,
> And that anyone who wishes to use Qt to develop an app on OSX and submit to 
> the app store must be savvy enough to
> Build from source, and locate this thread in the dev newsgroup, and then 
> apply the patch specified?


Let's keep in mind that this is about apps using Qt WebView and Qt WebEngine, 
not about the rest of Qt.

> Wasn't this thread started by someone that was frustrated after having gone 
> through that exact process?
>
> We use QtWebEngine on Windows, and it works well, but do not use it on Mac or 
> iOS because of the App Store requirements. (We are a commercial customer)


We tried to make Qt WebEngine on macOS to be compliant with the Mac App Store 
for some time. In Qt 5.9 there's a configure switch for it: 
-appstore-compliant. Anyhow, unfortunately we found out that this is not 
feasible anymore with newer Chromium versions, so we had to drop that for Qt 
5.10 and future versions. But even in Qt 5.9 it was a (compile time) opt-in, 
because you effectively loose functionality which might not be what you want.


> I was frustrated by a similar decision with Qt Multimedia where the default 
> backend on Windows was changed From
> AVFoundation (Which can play x264 encoded video out of the box) to DirectShow 
> (which cannot).
>
> In both cases, this decision pushes users away from Qt because it does not 
> 'just work' as expected, and also
> makes it necessary to compile Qt to get basic functionality working.
> (IMHO, it should not be necessary for most end users to compile Qt)


This is indeed a goal. But this is about tradeoffs: Unfortunately we don't have 
'the perfect' backend that covers all use cases for Qt WebView on macOS right 
now.

> Qt has gone to very great lengths with Qt Creator and the examples that 'just 
> work' out of the box, which in my Opinion is fantastic!
> Although QtWebEngine is wonderful, it seems to me that given the App Store 
> requirements that we must use the native WebView, that it might be wise, and

> benefit Qt as a whole to reconsider this decision.


Indeed, and we agreed to solve this properly by introducing a plugin based 
architecture: https://codereview.qt-project.org/#/c/207651/


It's just not something you want to do in a patch level release, because 
stability.


Regards

Kai



From: Development  on 
behalf of Steve Schilz 
Sent: Thursday, January 25, 2018 9:05:47 PM
To: development@qt-project.org
Subject: Re: [Development] Using Native web view on OS X

> 22.01.2018, 18:37, "Alberto Mardegan" :
>   Hi all!
>   ??I've developed a desktop application which uses the WebView QML
>   module, with the hope of publishing it in the Apple store. However,
>   unless I am seriously mistaken, this is just not possible (or maybe the
>   documentation needs some serious love).
>
>   No matter what I try, it seems that QtWebEngine is always required!
>
>   If I simply remove QtWebEngine from my Qt installation, building the
>   application succeeds but then when I run it I get the same error as in
>   https://bugreports.qt.io/browse/QTBUG-63107
A QML application that is using Webview will crash on 
...
bugreports.qt.io
No reviews matched the request. Check your Options in the drop-down menu of 
this sections header.


>
>   If I look at src/webview/qtwebviewfunctions.cpp it looks like the
>   decision to use the native webview vs QtWebEngine is done at runtime,
>   but for some reason it looks like one still needs to have QtWebEngine
>   available in order for QtWebView to build successfully. With the obvious
>   consequence that one won't be able to publish one's app into the Apple
>   store.
>
>   Is there some reason why the QtWebEngine support library isn't dlopen'ed
>   at runtime? Can I file a bug about that?
>
>   From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable
>   is required to use native backend.
>
>   [1] https://codereview.qt-project.org/#/c/162337/
Qt - Gerrit Code Review
codereview.qt-project.org
Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet 
Qt; Qt Repository Browser


>
>
> Ciao,
? ?Alberto

?On 22/01/2018 18:49, Konstantin Tokarev wrote:
?From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment 
 variable is required to use native backend.

?[1] https://codereview.qt-project.org/#/c/162337/
Qt - Gerrit Code Review
codereview.qt-project.org
Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet 

Re: [Development] Symbol clashes with static Qt libraries

[Kai Koehne]

Alright, so it seems we have to prefix the symbols we can't hide by static or 
anonymous namespaces ...

For logging categories, I'd like to start using 'qlc' as prefix. See also 
change https://codereview.qt-project.org/#/c/235631/ for qtbase.

Ossi pointed out in the review that, because it is a private symbol, the 'qt_' 
prefix would be more correct. Anyhow, that just gets too long ... So I'm asking 
whether anybody objects making an exception for logging categories.

Regards

Kai

> -Original Message-
> From: Development 
> On Behalf Of Thiago Macieira
> Sent: Tuesday, July 31, 2018 4:58 PM
> To: development@qt-project.org
> Subject: Re: [Development] Symbol clashes with static Qt libraries
> 
> On Tuesday, 31 July 2018 05:46:44 PDT Simon Hausmann wrote:
> > I favor (a) along with the existing test, because of the issues
> > Giuseppe outlined with (b) and I'm sceptical about how realistic (c) is for 
> > us.
> 
> We will not be able to get (c) working everywhere. I remember trying objcopy
> some years ago messing with symbol properties and I know I wasn't successful.
> I don't remember what I was trying, though, so this is not a showstopper for
> our current problem. Just don't get your hopes up.
> 
> I think we need (a) and we can apply (c) if possible.
> 
> > If we wanted to make this test work again (and produce errors with
> > your logging category examples), then we would need a configuration in
> > the CI that builds on Linux without ELF visibility. At least that's
> > one of the ways it could be done with minimal effort.
> 
> Why can't the test run on .a files?
> 
> > It however does not protect us from the issue on Windows and macOS,
> > but it covers the cross-platform code.
> 
> nm exists on both too. We won't get it on MSVC, though.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Symbol clashes with static Qt libraries

[Kai Koehne]

Hi,

I'm wondering how we can avoid symbol clashes in static Qt libs + user code.

Reason why I'm looking into this is https://bugreports.qt.io/browse/QTBUG-67692 
: We have the convention to name logging categories (which are actually 
functions) with 'lc', such as 'lcCanvas'. Since logging categories shouldn't be 
exported, this is fine for dynamic libs. However, for static builds of Qt, the 
symbol might clash with symbols of the same name from other libraries / user 
code, potentially resulting in linker errors.

(And no, we can't mark the logging category objects as static / in an anonymous 
namespace because they can be pre-declared by Q_DECLARE_LOGGING_CATEGORY).

Note also that the logging categories are by far not the only non-prefixed 
symbols that might cause clashes when statically linking. See 
https://paste.kde.org/poeiwjlw3 for all symbols in qtbase/lib/Qt5*.a that don't 
contain a q or Q , for a static Qt build of mine.

I can think of 3 approaches to tackle this:

a) Prefix all symbols with 'q', like we do for exported symbols.

This requires some bigger patches. See e.g. 
https://codereview.qt-project.org/#/c/235631/ for renaming all logging 
categories to 'qlc*' in qtbase.

b) Advise people to always configure static Qt in a namespace (-qtnamespace).

This should fix it for symbols at least in our own code. Maybe we should make 
it even the default for static builds in Qt 6?

c) Look into tricks like 'objcopy --localize-hidden' to hide symbols.

This would probably require some major hackery in the build system. No idea 
whether this is supported also on other platforms, and how hard it would be to 
pull it off. I'm not volunteering 
 
I guess I'm not the first one who looks into this, so I'm happy to hear 
advice/opinions 

Kai

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Qt Linguist should tell how many strings are in a file

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> [...]
> The closest I got was using some web service that we were able to export from
> (https://lokalise.co/ ?). Also having a built-in google translate button 
> would be
> very helpful for the provisional translations.

So did you use localise.co in the end? If so, how did you organize the data
Import and export?

For Qt Linguist itself: Nobody has been working on it lately. It does what it 
does, 
but extending it is not in the current development focus. Anyhow,
if anybody fancies spending some time on it, be welcome to do so 

However, for more complicated setups I'd expect that people would use 
other tools, probably using lconvert to convert .ts files back and forth 
between standard formats like XLIFF. But we haven't been advertising
this much.

Regards

Kai

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

Re: [Development] Qt Linguist should tell how many strings are in a file

[Kai Koehne]

> -Original Message-
> [...]
> It was unfortunately a combination of lokalise.co and my scripts. The
> owner/opertator/developer of lokalise was very helpful in adjusting his 
> service
> which apparently supported Qt 3 to Qt4's format. He complained about issues
> with the XML, which I later also experienced when writing my merge scripts.
> We used lokalize to get the translations from the translators and all that 
> entails
> (user management, scope, etc)

Would be good to know exactly what the issues are.

> I would expect that Qt would adopt/focus on GNU gettext/PO files in the
> future?

Well, you can use gettext already right now, for your own translations.

Anyhow, I doubt that we can change the existing tooling in Qt to gettext 
without breaking user code. And given our focus on compatibility, I don't see 
this happen any time soon.

Regards

Kai

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

[Development] QML API Review

[Kai Koehne]

Hi,

In addition to the C++ API review that Edward has been pushing, we also need to 
review new/changed QML API.

Most of our QML API is actually defined in C++, so one way to review them is 
diffing the corresponding .h files; however, because they are private (in the 
C++ sense), every module is free to place these files in different locations. 
It also misses the information on how exactly the type is registered in the end 
(think of qmlRegisterXXX).

Fortunately, we have another way to inspect QML API: The plugins.qmltypes files 
that every plugin is supposed to ship alongside. The prime use of these files 
is to make syntax highlighting and code completion in Qt Creator possible. 
However, it turns out it's also a very concise way of reviewing new API, so 
let's use it for that .

The .qmltypes files need to be updated manually. I've now run the update for 
all the .qmltypes files I could find and upload the change for review (see also 
https://bugreports.qt.io/browse/QTBUG-70264 and linked patches). I suggest to 
use these patches as the basis for reviewing the QML API. Different from C++, I 
suggest that if you're happy with the API, please +2 it - The patch will 
actually be merged in the end.

Note that some the plugins.qmltypes files got updated in between, and therefore 
the patches do not show the full diff to version 5.11. Other plugins.qmltypes 
files didn't see an update in 5.11, something we should really avoid in the 
future ☹ In these cases a separate review might be necessary.

Anyhow, it turns out that most developers don't update the plugins.qmltypes 
files, so I suggest to establish this as the new norm, and update them only 
before the release, as part of the API review process.

An alternative would be to make sure that the .qmltypes files are up to date 
directly before the API review, and include them as part of the C++ diff. 
Anyhow, this would require us to _not_ instantly fix things in the .qmltypes 
file when it gets updated, but first check in the plugins.qmltypes file as is - 
something that can be difficult to accept. So maybe it's just easier to have 
this as separate diffs.

Regards

Kai

PS: I intend to codify this 
http://quips-qt-io.herokuapp.com/quip-0010-API-review.html , but first wanted 
to establish a consensus.

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] QtCS 2018: Third-party and security policy

[Kai Koehne]

Hi,

I've been creating https://codereview.qt-project.org/#/c/233962/2 to pin down 
what I assume is consensus so far. This is an update to QUIP-4 
(https://quips-qt-io.herokuapp.com/quip-0004.html), which regulates how we 
handle Third-Party Components in Qt.

I also added a paragraph that all newly reported known security vulnerabilities 
in Third-Party Modules should go through the Qt Project security mailing list. 

Kai

PS: Notes from the session at the Qt Contributor Summit are available at 
https://wiki.qt.io/QtCS2018_Third-Party_Sources_Policy_and_Security


> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Thiago Macieira
> Sent: Monday, June 11, 2018 1:18 PM
> To: development@qt-project.org
> Subject: Re: [Development] QtCS 2018: Third-party and security policy
> 
> On Monday, 11 June 2018 10:56:42 CEST EXT Eike Ziller wrote:
> > If we are about to release Qt Creator with LLVM/Clang 6.0, and
> > LLVM/Clang
> > 6.1 is released, this has good chances to introduce bugs. Aside from
> > that, updating the binaries that we ship is an effort, since they are
> > profile optimized etc etc. If instead LLVM/Clang 7.0 should be
> > released, Qt Creator might not even compile anymore. The probability
> > that some functionality is broken increases even more. After we fix
> > all these issues (it’s 1-2 weeks later now than the original schedule), a 
> > new
> version of sqlite is released.
> 
> Good point about chasing a moving target.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] API breackage in Qt3D

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> Subject: Re: [Development] API breackage in Qt3D
> 
> El 1 mar. 2018 6:11 a.m., "Sean Harmer"   > escribió:
> 
> 
>   Animation and Extras are tech preview. The rest are stable.
> 
> 
> Ok, so we have probably misunderstood that part.

I also think this should be documented more explicitly:

https://codereview.qt-project.org/#/c/216892/

Reviews are welcome 

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

[Development] Maintainers: Make sure QML import in documentation and plugins.qmltypes are up to date for 5.11

[Kai Koehne]

Hi,

If your respective module has a QML import and there's new API / a new import 
version, please make sure now that both the documentation and the tooling 
support accommodates for that. 



For documentation, it is usually enough to bump the import in the "\qmlmodule 
XXX major.minor" declaration, and in the module description. See e.g. 
https://codereview.qt-project.org/#/c/226631/1 .

This will make sure that the 'landing page' of your module recommends the 
latest import, and that documentation for every single qml type will start with 
the latest up to date import statement.



plugins.qmltypes is the mechanism how Qt Creator knows about new types and 
properties. That is, if it doesn't get updated, the new import and new types, 
properties and methods will be underlined as unknown in Qt Creator.

To update it, it is usually enough to run 

  [n]make qmltypes

In the build folder where the plugins.qmltypes file belongs to.  This is btw 
also a good way to do an API review. In particular, to check whether all new 
properties, signals ... have a proper REVISION / are properly versioned.


Regards

Kai

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

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

Re: [Development] Qt API review process (was: Re: Qt 5.11 Alpha released)

[Kai Koehne]

(comment below)

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Jani Heikkinen
> Subject: [Development] Qt API review process (was: Re: Qt 5.11 Alpha
> released)
> 
> Hi all,
> 
> We have API review ongoing for Qt 5.11. For me our process for that is a bit
> unclear; At which point we can say the review is really done? There are
> comments in the reviews but then pretty much nothing... At some there is -1,
> few +1 but that's it. I think we should clarify the process so that we can 
> more
> easily see the status there. That's why I propose following:
> 
> 1) API review for the module is ready when there is '+2'  (from Module/Chief
> Maintainer)
> 2) During the review reviewer must add 'Code Review -1/-2' if there is
> something which should be corrected before we can agree API review to be
> ready. And vice versa: if API seems to be OK +1 should be added to indicate 
> API
> is reviewed.
> 3) Reviewer needs to create a bug report about the findings. That makes it
> easier to follow up & we can add needed ones in the release blocker list.
>* These bug reports should be added in review's comment field as well. And 
> if
> one is something which really needs to be fixed before release reviewer should
> add the issue in release blocker list.
> 4) API review for module needs to be updated in gerrit until it gets '+2'. 
> After
> that no more updates. That way we can link the approved review in releasing
> wiki for the evidence :D

I would rather create a task in JIRA for the review itself, with priority 1 
and appropriate fixVersion. Any subsequent findings could be made subtasks of
this task. 

This automatically makes the API review part of the blockers list, and makes 
sure
everyone understands that this needs to be done before a release.

Regards

Kai

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

Re: [Development] Qt 5.12 beta2 released

[Kai Koehne]

> -Original Message-
> From: Development  project.org> On Behalf Of Mark De Wit
> Sent: Wednesday, October 17, 2018 9:10 AM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.12 beta2 released
> 
> What is the criteria for blocker?   It would be great if WebEngine were usable
> again for people behind proxies (my last usable Qt release is 5.9)...
> 
> https://bugreports.qt.io/browse/QTBUG-69281  is marked as P1 but not
> targeted at 5.12?

For bugs, we do set the 'fix version' only for bugs that will potentially delay 
the release. 

Anyhow, the bug is being worked on, and will most likely be fixed both in 5.11 
branch and for 5.12.0. You can already give the patches a try if you want to 

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

[Development] Dropping remaining support of qtquick1

[Kai Koehne]

Hi,

Can we drop the last remaining traces of qtquick1 from qtbase?

Remember that qtquick1 is not part of Qt anymore since Qt 5.6. Anyhow, some 
people might still compiled it compiled with later versions on their own ... 
Right now it doesn't compile for me with 5.12, but I haven't investigated why.

The last remaining support for Qt Quick 1 are in the build system 
(qml1_module.prf, qml1_plugin.prf), QLibraryInfo::ImportsPath, qmake 
($$QT_INSTALL_IMPORTS), and finally in QObject and QWidget (handling of 
QAbstractDeclarativeData::destroyed_qml1).

We could remove these already in 5.12, in 5.13, or wait for Qt 6. I'd prefer 
5.12 if nobody objects 

Regards

Kai

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

The Future is Written with Qt
www.qtworldsummit.com

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

Re: [Development] Qt6: Adding UTF-8 storage support to QString

[Kai Koehne]

> -Original Message-
> From: Development  On Behalf Of Tor
> Arne Vestbø
> Sent: Friday, January 18, 2019 4:27 PM
> To: Jedrzej Nowacki 
> Cc: Thiago Macieira ; development@qt-
> project.org
> Subject: Re: [Development] Qt6: Adding UTF-8 storage support to QString
> 
> Picking up on this:
> 
> If we plan to standardise on our Qt source code being UTF8, can we please
> allow QString(“Tor Arne Vestbø") without going through
> QLatin1Literal/QStringLiteral/QLatin1String/etc etc?

I think you're touching two different things here:

1. We generally compile Qt code with QT_NO_CAST_FROM_ASCII that disables the 
QString(const char *) overload. And we do that so that you have to make it 
explicit whether you really want to do the implicit conversion from UTF-8 to 
UTF-16, use QStringLiteral() to encode it as UTF-16 at compile time, or rather 
have it translated with a  tr() call.

I think for Qt code explicit is better than implicit, so I actually would stay 
with QT_NO_CAST_FROM_ASCII.

2. We require all Qt source code to be ASCII only. This is AFAIK mostly because 
of the editor in Visual Studio, who's even in its latest incarnation doesn't 
have a global option to save files in UTF-8 instead of 
.

Here I'm not sure anymore whether being conservative buys us much. VS after all 
has a heuristic to open a UTF-8 encoded file correctly, so the problem mostly 
is that people might create a new file with non-UTF-8 content, or copy it from 
another project.

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] gnuwin32 in qt5.git

[Kai Koehne]

> -Original Message-
> From: Development  On Behalf Of
> [...]
> Would it make sense to use a package manager like Conan to provide third
> party dependencies as well as Qt modules in source and prebuilt binary form?
> That could solve the availability issue and would probably simplify the build
> flow as well.

Conan.io and Vcpkg are hot candidates, indeed. IMO we need something that
- Works natively on all development platforms
- Has a strong ecosystem which we can benefit from
- Supports both building locally, as well as providing pre-build binaries

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Kai Koehne]

> -Original Message-
> From: Development  On Behalf Of ekke
> Sent: Wednesday, January 23, 2019 9:45 AM
> To: development@qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
> 
> seems this time it's a rocky path to release Qt 5.12.1

We're still struggling with a change in configure that made system library 
paths absolute - good for local installations, but problematic for the binary 
packages, which are supposed to work in different setups:

 https://bugreports.qt.io/browse/QTBUG-72903

Kai

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

Re: [Development] CMake && QtCreator cross-compilation for ARM fails

[Kai Koehne]

> -Original Message-
> [...]
> > > The Qt Company has been looking for "employees" to work on Qbs for
> > > month before dropping it, apparently nobody responded, or something...
> >
> > Then that would pretty much explain why they cannot maintain it in the
> > long run.
> 
> You are right, and it would be nice to have official statements on that. What
> did really happen?

We indeed had a dedicated position open for quite some time. Anyhow, the 
deprecation of Qbs was ultimately a business decision, not something directly 
related to hiring.

Kai

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

Re: [Development] automated bulk change closing old issues in the "Need more info" state

[Kai Koehne]

> -Original Message-
> From: Development  project.org> On Behalf Of Uwe Rathmann
> Sent: Monday, November 19, 2018 4:10 PM
> To: development@qt-project.org
> Subject: [Development] automated bulk change closing old issues in the "Need
> more info" state
> 
> Hi all,
> 
> I just received 2 messages about: automated bulk change closing old issues in
> the "Need more info" state.
> 
> - https://bugreports.qt.io/browse/QTBUG-68874
> - https://bugreports.qt.io/browse/QTBUG-66264
> 
> I have no idea why they have been set to "Need more info" - actually one of
> them has been explicitly answered, but the developer does not follow up.

Then it's good that the bot pointed the wrong state out. Please move the bugs
back to open state (as you apparently did already). Next time you answer,
consider clicking "Provide missing info", instead of just commenting [1].

> ( There might be other good reasons closing these bugs, but waiting for more
> info is definitely not the case )
> 
> I guess my bugs are not the only ones and if you don't want to lose a lot of
> valuable reports this way better stop an revert this bulk changes.
>
> Why should anyone continue reporting bugs, when all what happens is, that
> they are put on hold and finally closed automatically ?

Don't shoot the messenger  Your bugs where in a 'need more info' state,
which a lot of searches exclude, and might have therefore gotten less attention.
 If you have a bug in the 'Need more info" state and it's unclear to you what
information is missing, just ask.

Kai

[1]: I agree that the workflow is suboptimal there, but that's apparently what 
JIRA offers.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Changes to maintainership of the Qt build system (including qmake)

[Kai Koehne]

Hi,

Oswald Buddenhagen has recently left the Qt Company, and also wanted to step 
down from his current maintainership in the build system area. IMO he did a 
tremendous job in maintaining both qmake and the Qt build system in the last 
years, so thank you Ossi! 

This obviously leaves a hole in our list of maintainers. Given that there's no 
natural successor yet who can take over all of the areas, I'm proposing to 
leave the official maintainer role vacant for now.

Anyhow, that doesn't mean that issues won't be triaged or fixed ! For now, 
Joerg Bornemann (joerg.bornem...@qt.io, IRC jobor) and me (kai.koe...@qt.io, 
IRC kkoehne) will take over the handling of the issues in the JIRA components 
"Build System", "Build Tools: Other", and "Build tools: qmake" as part of a 
virtual "Build System Team". This team is now also the default assignee for 
issues in these component. If you feel you can help out in these areas too, 
please reach out to us!

Regards

Kai

PS: We've also a vacant position in this area: 
https://www.qt.io/open-positions/software-engineer-tooling-1543483062

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

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

Re: [Development] Qt 5.12 and debug/warnings messages

[Kai Koehne]

> -Original Message-
> [...]
> So I've supposed the Qt 5.12.0 release (MSVC2017 / 32bit) have been build
> with QT_NO_WARNING_OUTPUT and QT_NO_DEBUG_OUTPUT.

That's not the case, at least for the official packages. QT_NO_WARNING_OUTPUT, 
QT_NO_DEBUG_OUTPUT anyway does only affect the code it was compiled with. That 
is, qDebug() in your own code shouldn't be affected if Qt itself was compiled 
with QT_NO_XXX_OUTPUT.

> Once again, with previous Qt release, all works as expected.

Please try to create a minimal example, and add it to a Qt Support or 
bugtracker ticket.
 
Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Good idea to update Windows 10 to 1809 - Redstone 5?

[Kai Koehne]

> -Original Message-
> From: Development  On Behalf Of
> Tony Sarajärvi
> Sent: Thursday, January 17, 2019 2:23 PM
> To: development@qt-project.org
> Subject: [Development] Good idea to update Windows 10 to 1809 - Redstone
> 5?
> 
> Hi
> 
> We have this thing that we like to try to update things to the latest. But
> regarding Windows 10 I was told we shouldn't perhaps do that, because Qt's
> code will select and different path depending on the API levels available from
> Windows.

Qt WebEngine in Qt 5.13 will require a newer version of Windows 10, so it's 
high time to update Windows 10 in our CI.

If we really start depending on stuff from a newer Windows 10 SDK, I guess we'd 
notice when testing on Windows 7, which we AFAIK test for before a release.
 
My 2 cents,

Kai

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

Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes files

[Kai Koehne]

Somewhat related: I suggest to stop listening all changes in the commit message 
template. See e.g.

https://codereview.qt-project.org/#/c/253950/

This makes the commit message unnecessarily long, and also means that, if you 
grep though git log history for a specific change, you hit the changelog commit 
too.

I guess the idea was to give anyone working on the change log an idea what 
commit might be worth documenting. Anyhow, it seems not every reviewer removes 
the list before submitting, and frankly speaking it should be easy enough for 
everyone to run e.g. 'git log v5.12.1..5.12.2' themselves.

Kai

> -Original Message-
> From: Development  On Behalf Of
> Cristián Maureira-Fredes
> Sent: Thursday, February 21, 2019 12:47 PM
> To: Mitch Curtis ; Jani Heikkinen ;
> development@qt-project.org
> Subject: Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes
> files
> 
> Hello,
> 
> so, we agree the Go one (qtqa) is the recommended one?
> 
> Time ago, I was directed to this one:
> http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-
> tools/create_changelog.pl
> and ended up suggesting this one as a replacement for the Qt for Python
> project: https://codereview.qt-project.org/#/c/252162/
> 
> I understand it is better to focus on one script and improve it so that's why 
> I
> would like to know which is the preferred option.
> 
> Cheers
> 
> 
> From: Development  on behalf of
> Mitch Curtis 
> Sent: 21 February 2019 11:46
> To: Jani Heikkinen; development@qt-project.org
> Subject: Re: [Development] Maintainers, your action needed: Qt 5.12.2 changes
> files
> 
> > -Original Message-
> > From: Jani Heikkinen
> > Sent: Thursday, 21 February 2019 11:06 AM
> > To: Mitch Curtis ; development@qt-project.org
> > Subject: RE: [Development] Maintainers, your action needed: Qt 5.12.2
> > changes files
> >
> > > -Original Message-
> > > From: Mitch Curtis 
> > > Sent: torstai 21. helmikuuta 2019 11.21
> > > To: Mitch Curtis ; Jani Heikkinen
> > > ; development@qt-project.org
> > > Subject: RE: [Development] Maintainers, your action needed: Qt
> > > 5.12.2 changes files
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Development  On Behalf
> > > Of
> > > > Mitch Curtis
> > > > Sent: Thursday, 21 February 2019 9:33 AM
> > > > To: Jani Heikkinen ;
> > > > development@qt-project.org
> > > > Subject: Re: [Development] Maintainers, your action needed: Qt
> > > > 5.12.2 changes files
> > > >
> > > > > -Original Message-
> > > > > From: Development  On
> > Behalf
> > > > Of
> > > > > Jani Heikkinen
> > > > > Sent: Thursday, 21 February 2019 9:19 AM
> > > > > To: development@qt-project.org
> > > > > Subject: [Development] Maintainers, your action needed: Qt
> > > > > 5.12.2 changes files
> > > > >
> > > > > Hi,
> > > > > Initial ones here: https://codereview.qt-
> > > > > project.org/#/q/message:%22Add+changes+file+for+Qt+5.12.2%22,n,z
> > > > >
> > > > > Please take it over, do needed modifications and get '+2' during
> > > > > this
> > > week.
> > > >
> > > > Do we have a script that generates the change logs? I see that
> > > > qtbase has entries for bug fixes with the task number:
> > > >
> > > > http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.12.1/?h=v5.
> > > > 12
> > > > .1
> > > >
> > > > I'd like to get the same for the modules that I maintain. I'm
> > > > guessing that one was done manually, but I'd like to try to
> > > > automate it (even if it still requires some manual editing afterwards).
> > > >
> > > > I checked qtrepotools.git but didn't find anything. Simon created
> > > > one, but says that it's not the same one in use by the release team:
> > > >
> > > > http://code.qt.io/cgit/qt/qtqa.git/tree/src/createchangelog
> > >
> > > Replying to myself to say that this tool works really well, and is
> > > very easy to use (especially with
> > > https://codereview.qt-project.org/#/c/253973/). Can the initial
> > > change logs
> > be created with it?
> >
> > We will test this and use it in coming releases if it works better
> > that current one
> 
> For what it's worth, the only negative difference I saw was that it
> (createchangelog) generates this:
> 
> Qt 5.12.2 is a bug-fix release. It maintains both forward and backward
> compatibility (source and binary) with Qt 5.12.1.
> 
> whereas the current one generates this:
> 
> Qt 5.12.2 is a bug-fix release. It maintains both forward and backward
> compatibility (source and binary) with Qt 5.12.0 through 5.12.1.
> 
> Doesn't seem that important though?
> 
> > br,
> > Jani
> >
> > >
> > > > > br,
> > > > > Jani Heikkinen
> > > > > Release Manager
> > > > > ___
> > > > > Development mailing list
> > > > > Development@qt-project.org
> > > > > https://lists.qt-project.org/listinfo/development
> > > > ___
> > > > Development mailing list
> > > > 

Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started

[Kai Koehne]

> -Original Message-
> From: Development  On Behalf Of
> Mark De Wit
> Sent: Wednesday, January 30, 2019 11:13 AM
> To: development@qt-project.org
> Subject: Re: [Development] HEADS-UP: Branching from '5.12' to '5.12.1' started
> 
> Selecting MSVC 2015 64-bit + Qt WebEngine for 5.12.1 in the installer does not
> give me WebEngine.  Is that intentional?  

Yes, this is intentional. Qt WebEngine in 5.12 only supports MSVC 2017, that 
was the case already for Qt 5.12.0.

> Should the installer perhaps warn
> that the selected combination is unsupported?

Maybe, though getting a warning every time might be a bit too much, too. Also, 
I'm not sure how and whether such a warning can be implemented ...

At least the description of the Qt WebEngine module says

  On Windows, the module is only available under MSVC 2017

Kai 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QUIP-13 for Qt Examples and Demos

[Kai Koehne]

Hi,

It seems reviewers are mostly happy with the current state of QUIP-13 - the 
latest 2 changes where just editorial:

  https://codereview.qt-project.org/#/c/246288/

Unless someone still has fundamental objections I'd like to merge this soon. We 
can always reiterate on details in follow-up commits.

Regards

Kai

> -Original Message-
> From: Development  On Behalf Of
> Kai Koehne
> Sent: Thursday, November 22, 2018 11:26 AM
> To: development@qt-project.org
> Subject: [Development] QUIP-13 for Qt Examples and Demos
> 
> Hi,
> 
> I'd like to propose writing  QUIP for requirements for our examples and demos.
> There's a lot of 'common knowledge' floating around, and some wiki pages:
> 
> https://wiki.qt.io/Documentation_Style_for_Examples
> https://wiki.qt.io/Writing_Qt_Examples
> 
> But I'd actually like to propose some additional requirements for the demos we
> re-introduced for Qt 5.12, and I'm missing a good place to discuss / decide 
> upon
> this  So I tried to create a QUIP-13 :
> 
> https://codereview.qt-project.org/#/c/246288/
> 
> Note that so far I didn't really come around to describe the documentation 
> side
> (how the documentation of an example or demo should be set up etc). Patches
> are welcome 
> 
> Regards
> 
> Kai
> 
> --
> Kai Koehne, Senior Manager R | The Qt Company
> 
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331
> B
> 
> The Future is Written with Qt
> www.qtworldsummit.com
> 
> ___
> Development mailing list
> developm...@lists.qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development