date:20200127

On Monday, 27 January 2020 22:37:47 PST Benjamin TERRIER wrote:
> You might have missed the info because it is in the blog post, but not in
> Lars email:
> 
> There will be no more open source offline installer.

Thanks, I stand corrected.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Bogdan Vatra via Development

În ziua de marți, 28 ianuarie 2020, la 08:37:47 EET, Benjamin TERRIER a scris:
> Le mar. 28 janv. 2020 à 03:22, Thiago Macieira 
> 
> a écrit :
> > On segunda-feira, 27 de janeiro de 2020 14:47:46 PST NIkolai Marchenko
> > 
> > wrote:
> > > Assuming we have a VM that is restricted to connecting to the internet,
> > 
> > we
> > 
> > > previously could dump the installer there and install Qt.
> > > Now, we need to have an intermediary PC with the same OS to first
> > > install
> > > the binaries via online installer and then copy those binary files to
> > 
> > that
> > 
> > > first VM.
> > > 
> > > This is an extraneous and completely artificial step for absolutely no
> > > reason other than TQtC paywalling them, which is ridiculous.
> > 
> > Previously, you anonymously downloaded the offline installer from another
> > machine, then copied it over to the VM, and installed there.
> > 
> > Now you're going to download the offline installer from another machine
> > after
> > typing your password, then copy over to the VM and install there.
> > 
> > What's the hurdle?
> 
> You might have missed the info because it is in the blog post, but not in
> Lars email:
> 
> There will be no more open source offline installer.
> 
> For binaries, open source users will only have access to the online
> installer that will require a Qt Account.

  Folks, you have to understand that The Qt Company must pay its developers!
  I really don't bother if there will be offline installers only for commercial 
customers. Or if they will require an username to download from the 
online installer. Right now I'm not typing my user & pass just because the 
pass it's randomly generated and I'm too lazy to open my passwords app to get 
it.

  What I'm worried about is that there will be a 5.15 fork after TQC will 
close that branch. That fork will be necessary because you can't just switch 
projects like KDE from Qt 5 to Qt 6 overnight, it will take years to do it!
In all these years, all linux distributions that will ship Qt 5, will need 
regular updates with bug fixes, and because Qt 5.15 branch it's closed they 
will have to use either a "community" fork where all these distros will share 
their bugfixes or they will have their own patches. This means, it will be bad 
for TQC, because if these patches are not contributed via gerrit (CLA), TQC 
can't use them for commercial customers.

Cheers,
BogDan.

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

Re: [Development] Changes to Qt offering

Den tis 28 jan. 2020 kl 08:01 skrev Elvis Stansvik :
>
> Den tis 28 jan. 2020 kl 03:19 skrev Thiago Macieira 
> :
> >
> > On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich 
> > wrote:
> > > I would expect a significant negative effect on the quality of Qt
> > > shipped in Linux distributions and thus negative effect on the
> > > Qt-based applications and Qt reputation.
> >
> > That is debatable since most Linux distributions do not align with the Qt
> > LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid, but 
> > for
> > all other LTSes, open source Linux distros seem to choose whichever version
> > was latest at the time they reached feature-freeze.
> >
> > Current versions in:
> > * Debian stable: 5.11.3
> > * Debian oldstable: 5.7.1
> > * Fedora 31: 5.12.5
> > * Fedora 30: 5.12.1
> > * Fedora 29: 5.11.1
> > * Fedora 28: 5.10.1
> > * CentOS 8.1: 5.11.1
> > * openSUSE 15: 5.9.4 (15.1 now has 5.9.7)
> > * openSUSE 42.3: 5.6.2
> > * openSUSE 42.2: 5.6.1
> > * (K)Ubuntu 19.10: 5.12.4
> > * Ubuntu 18.10: 5.11.1
> > * Ubuntu 18.04 LTS: 5.9.5
> > * Ubuntu 16.04 LTS: 5.5.1
> > * KDE Neon: 5.13.2
> > * Manjaro 18.1.0: 5.13.0
> >
> > There are a couple of alignments with Qt LTS above but they could be
> > coincidences. openSUSE 15 was released around 6 months after the 5.10.0
> > release (and less than 3 after 5.10.1, which is when they seem to make
> > upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought 
> > Fedora
> > 31 was trying to align, but then I went to search for the current version 
> > and
> > F32-in-development has already upgraded out of the LTS to 5.13.2.
> >
> > Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only
> > legitimate, intentional alignment on a Qt LTS. If that's confirmed, it would
> > be the first, after 4 years of having LTS releases.
>
> I think they are intending to try to get Qt 5.14.1 packaged for Ubuntu
> 20.04. At least that's what I've seen from the discussions in
> #ubuntu-qt on freenode. So they will be de-aligning if they get that
> done on time.

Forgot links to back up my claim:

Dec 12: https://irclogs.ubuntu.com/2019/12/12/%23ubuntu-qt.html
Jan 8: https://irclogs.ubuntu.com/2020/01/08/%23ubuntu-qt.html

Elvis

>
> Elvis
>
> >
> > So it's completely understandable to have concluded that the LTS releases
> > weren't useful to Linux distributions.
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel System Software Products
> >
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Den tis 28 jan. 2020 kl 03:19 skrev Thiago Macieira :
>
> On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich wrote:
> > I would expect a significant negative effect on the quality of Qt
> > shipped in Linux distributions and thus negative effect on the
> > Qt-based applications and Qt reputation.
>
> That is debatable since most Linux distributions do not align with the Qt
> LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid, but for
> all other LTSes, open source Linux distros seem to choose whichever version
> was latest at the time they reached feature-freeze.
>
> Current versions in:
> * Debian stable: 5.11.3
> * Debian oldstable: 5.7.1
> * Fedora 31: 5.12.5
> * Fedora 30: 5.12.1
> * Fedora 29: 5.11.1
> * Fedora 28: 5.10.1
> * CentOS 8.1: 5.11.1
> * openSUSE 15: 5.9.4 (15.1 now has 5.9.7)
> * openSUSE 42.3: 5.6.2
> * openSUSE 42.2: 5.6.1
> * (K)Ubuntu 19.10: 5.12.4
> * Ubuntu 18.10: 5.11.1
> * Ubuntu 18.04 LTS: 5.9.5
> * Ubuntu 16.04 LTS: 5.5.1
> * KDE Neon: 5.13.2
> * Manjaro 18.1.0: 5.13.0
>
> There are a couple of alignments with Qt LTS above but they could be
> coincidences. openSUSE 15 was released around 6 months after the 5.10.0
> release (and less than 3 after 5.10.1, which is when they seem to make
> upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought Fedora
> 31 was trying to align, but then I went to search for the current version and
> F32-in-development has already upgraded out of the LTS to 5.13.2.
>
> Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only
> legitimate, intentional alignment on a Qt LTS. If that's confirmed, it would
> be the first, after 4 years of having LTS releases.

I think they are intending to try to get Qt 5.14.1 packaged for Ubuntu
20.04. At least that's what I've seen from the discussions in
#ubuntu-qt on freenode. So they will be de-aligning if they get that
done on time.

Elvis

>
> So it's completely understandable to have concluded that the LTS releases
> weren't useful to Linux distributions.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Le mar. 28 janv. 2020 à 03:22, Thiago Macieira 
a écrit :

> On segunda-feira, 27 de janeiro de 2020 14:47:46 PST NIkolai Marchenko
> wrote:
> > Assuming we have a VM that is restricted to connecting to the internet,
> we
> > previously could dump the installer there and install Qt.
> > Now, we need to have an intermediary PC with the same OS to first install
> > the binaries via online installer and then copy those binary files to
> that
> > first VM.
> >
> > This is an extraneous and completely artificial step for absolutely no
> > reason other than TQtC paywalling them, which is ridiculous.
>
> Previously, you anonymously downloaded the offline installer from another
> machine, then copied it over to the VM, and installed there.
>
> Now you're going to download the offline installer from another machine
> after
> typing your password, then copy over to the VM and install there.
>
> What's the hurdle?
>

You might have missed the info because it is in the blog post, but not in
Lars email:

There will be no more open source offline installer.

For binaries, open source users will only have access to the online
installer that will require a Qt Account.



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

Re: [Development] Changes to Qt offering

On segunda-feira, 27 de janeiro de 2020 15:16:35 PST Kevin Kofler wrote:
> Thiago Macieira wrote:
> > All security fixes are made available to everyone, for all Qt versions
> > that they affect, provided it's still a supported Qt version
> > (or it was easy to make the fix).
> 
> How will this work for QtWebEngine? There are a few dozen security fixes at
> each QtWebEngine point release, how will you make those available? And is a
> version in commercial-only LTS mode even "still a supported Qt version"?
> (Because QtWebEngine with its dozens of security fixes definitely does not
> qualify for the "or it was easy to make the fix" clause.)

With QtWebEngine, you really ought to upgrade to the next minor series, except 
for 5.15. The team retains compatibility with a couple of older versions (I 
don't know the exact policy) and this seems to me like the most indicated 
solution.

> For intermediate LTS releases such as 5.12, there is the option to just
> upgrade to 5.n+1 (e.g., 5.13) instead (where currently those releases will
> even compile against the LTS Qt, and sometimes even against older Qt
> branches, with no changes), but this is not an option for 5.15 (unless
> QtWebEngine 6.0 will be buildable as 5.16 somehow – it would likely not only
> need to build against Qt 5.15, but also need to lie about its major version
> number). So we really need a plan to provide security fixes for QtWebEngine
> 5.15 for a reasonable amount of time (until at least the major network-
> facing consumers such as Falkon, KMail, etc. are all ported to Qt 6).

5.15 needs to be addressed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Changes to Qt offering

On segunda-feira, 27 de janeiro de 2020 14:30:56 PST Giuseppe D'Angelo via 
Development wrote:
> Il 27/01/20 22:52, Thiago Macieira ha scritto:
> > All security fixes are made available to everyone, for all Qt versions
> > that
> > they affect, provided it's still a supported Qt version (or it was easy to
> > make the fix).
> 
> I asked before, and got no reply: how, by whom, hosted where?

That I don't know yet. We have so few security issues that we don't really 
have a process for producing security advisories.

I'm just saying that the security policy hasn't changed.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Changes to Qt offering

On segunda-feira, 27 de janeiro de 2020 14:47:46 PST NIkolai Marchenko wrote:
> Assuming we have a VM that is restricted to connecting to the internet, we
> previously could dump the installer there and install Qt.
> Now, we need to have an intermediary PC with the same OS to first install
> the binaries via online installer and then copy those binary files to that
> first VM.
> 
> This is an extraneous and completely artificial step for absolutely no
> reason other than TQtC paywalling them, which is ridiculous.

Previously, you anonymously downloaded the offline installer from another 
machine, then copied it over to the VM, and installed there.

Now you're going to download the offline installer from another machine after 
typing your password, then copy over to the VM and install there.

What's the hurdle?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Changes to Qt offering

On segunda-feira, 27 de janeiro de 2020 14:48:17 PST Alexander Akulich wrote:
> I would expect a significant negative effect on the quality of Qt
> shipped in Linux distributions and thus negative effect on the
> Qt-based applications and Qt reputation.

That is debatable since most Linux distributions do not align with the Qt 
LTSes. Kevin's question of 5.15 support while 6.0 is coming is valid, but for 
all other LTSes, open source Linux distros seem to choose whichever version 
was latest at the time they reached feature-freeze.

Current versions in:
* Debian stable: 5.11.3
* Debian oldstable: 5.7.1
* Fedora 31: 5.12.5
* Fedora 30: 5.12.1
* Fedora 29: 5.11.1
* Fedora 28: 5.10.1
* CentOS 8.1: 5.11.1
* openSUSE 15: 5.9.4 (15.1 now has 5.9.7)
* openSUSE 42.3: 5.6.2
* openSUSE 42.2: 5.6.1
* (K)Ubuntu 19.10: 5.12.4
* Ubuntu 18.10: 5.11.1
* Ubuntu 18.04 LTS: 5.9.5
* Ubuntu 16.04 LTS: 5.5.1
* KDE Neon: 5.13.2
* Manjaro 18.1.0: 5.13.0

There are a couple of alignments with Qt LTS above but they could be 
coincidences. openSUSE 15 was released around 6 months after the 5.10.0 
release (and less than 3 after 5.10.1, which is when they seem to make 
upgrades) and Ubuntu 18.04 was a month earlier than openSUSE. I thought Fedora 
31 was trying to align, but then I went to search for the current version and 
F32-in-development has already upgraded out of the LTS to 5.13.2.

Ubuntu snapshot for 20.04 is on 5.12.6. That seems to me to be the only 
legitimate, intentional alignment on a Qt LTS. If that's confirmed, it would 
be the first, after 4 years of having LTS releases.

So it's completely understandable to have concluded that the LTS releases 
weren't useful to Linux distributions.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Kevin Kofler

Thiago Macieira wrote:
> All security fixes are made available to everyone, for all Qt versions
> that they affect, provided it's still a supported Qt version
> (or it was easy to make the fix).

How will this work for QtWebEngine? There are a few dozen security fixes at 
each QtWebEngine point release, how will you make those available? And is a 
version in commercial-only LTS mode even "still a supported Qt version"? 
(Because QtWebEngine with its dozens of security fixes definitely does not 
qualify for the "or it was easy to make the fix" clause.)

For intermediate LTS releases such as 5.12, there is the option to just 
upgrade to 5.n+1 (e.g., 5.13) instead (where currently those releases will 
even compile against the LTS Qt, and sometimes even against older Qt 
branches, with no changes), but this is not an option for 5.15 (unless 
QtWebEngine 6.0 will be buildable as 5.16 somehow – it would likely not only 
need to build against Qt 5.15, but also need to lie about its major version 
number). So we really need a plan to provide security fixes for QtWebEngine 
5.15 for a reasonable amount of time (until at least the major network-
facing consumers such as Falkon, KMail, etc. are all ported to Qt 6).

Kevin Kofler

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Kevin Kofler

Alexander Akulich wrote:
> I would expect a significant negative effect on the quality of Qt
> shipped in Linux distributions and thus negative effect on the
> Qt-based applications and Qt reputation.
> 
> A maintainer can assume a bit more backporting, but let's have some
> retrospective on the current LTS:
> Compared to Qt 5.12.2, the new Qt 5.12.3 provides almost 200 bug fixes
> [1]. Compared to Qt 5.12.3, the new Qt 5.12.4 provides around 250 bug
> fixes [2]. This fifth patch release to Qt 5.12 LTS contains almost 280 bug
> fixes [3]. This sixth patch release for Qt 5.12 LTS series contains more
> than 50 bug fixes [4].
> 
> The number of commits is much more than the number of closed bug reports.
> If the last open Qt 5 minor version will have three releases (5.15.0,
> 5.15.1, 5.15.2) then it is sensible to assume that the commercial Qt
> branch will have at least 1000 commits on top of the public one. It is
> barely possible for a single maintainer or a single community-driven
> distribution to backport that many commits.

+1, and this will be especially a major issue for 5.15 where we distributors 
cannot just upgrade to 5.16 instead because there will be no Qt 5.16. We 
cannot just replace Qt 5 with Qt 6, but will have to ship both for a 
significant amount of time.

Kevin Kofler

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Giuseppe D'Angelo via Development


Il 27/01/20 23:15, Cristián Maureira-Fredes ha scritto:

Hello David,

On 1/27/20 11:00 PM, David Edmundson wrote:

All security fixes are made available to everyone, for all Qt versions that
they affect, provided it's still a supported Qt version (or it was easy to
make the fix).


If we could have that explicitly in writing from TQC, that would mean a lot.


The blog post states:

"We are changing our process in R to push all bug fixes to the main
development branch first, and then backport selected bug fixes back into
stable release branches. This process ensures that the latest version of
Qt will always contain all bug fixes. This process change was discussed
during the last Qt Contributor Summit – we communicate the exact process
details when Qt 5.15 will be released. Otherwise, development processes
and the governance model will not change."

This means that you still have access to all the fixes for 5.15
that happen after 5.15.2-3, since they will be on the dev branch.


I've already commented on this and got no replies


https://lists.qt-project.org/pipermail/development/2020-January/038344.html


First and foremost, this is not true in general: dev is Qt 6. A patch 
that doesn't apply to Qt 6 will therefore not land on dev at all. A 
patch to Qt 6 that also involves Qt 5 will need to be cherry picked, and 
that may cause extra burden (conflicts), but Lars said:



Backporting bug fixes is something that the Qt Company will take care of for 
these LTS branches.


=> What does the "these" refer to here? Any LTS branch or private 
(commercial only) LTS branches?


Conversely, someone still using Qt 5 may produce a patch for a bugfix 
for 5.15. If that bug also affects Qt 6, such a patch shall be rejected 
as per policy. If the producer of the fix doesn't care about Qt 6 (for 
the time being) and doesn't want to invest the time to get the fix there 
first, then Qt 5 shall remain without the fix, again as per policy.


(Yes, unfortunately the situation is unfortunate given 5.15 is LTS _and_ 
the next one is Qt 6, a major break forward, so there's extra trouble here.)


Let me ask again: is the 5.15 branch remaining open source and open for 
submissions on gerrit, and simply the _releases_ made out of it will be 
commercial-only releases (not open source)? If yes, is everyone simply 
going to cherry pick in such public branch, pretty much just like today, 
and anyone can clone and build it from git as open source? If not, what 
happens to the public 5.15 branch after 5.15 switches to commercial only?




If there is a bug on 5.15 and not on 6.0,
a fix will be pushed to the dev branch, then cherry pick to the
commercial LTS version, but the patch will still be there, so you
can just added to your local Qt version.


dev == Qt 6; the fix will have to be pushed on the 5.15 branch, assuming 
(see the question above and in the other mails I've sent) it stays open.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On Tue, 28 Jan 2020 at 00:43, Benjamin TERRIER  wrote:
>
>
>
> On Mon, 27 Jan 2020 at 23:23, Ville Voutilainen  
> wrote:
>>
>>
>> Correct. Necessary for specific purpose seems to be what article 5
>> requires, and then you get explicit consent for that
>> specific purpose, and GDPR's articles 5 and 6 are covered (of course
>> the rest of article 5's requirements need to be covered).
>> You're not necessarily going to like that specific purpose (or the
>> outcome of all this, including the consent query),
>> but GDPR requirements don't seem too difficult to fulfil, and there's
>> nothing particular in the new offering that would
>> instantly and obviously go even close to violating GDPR, based on my
>> layman reading of it. I don't think GDPR
>> will change the course of the offering, so if you want to change that
>> course, I think you need a different avenue
>> of argumentation.
>
>
> Well it depends on how you interpret the GDPR, a strict interpretation is 
> that since The Qt Company does
> not technically needs email addresses to distribute binary packages, 
> requiring users' email addresses
> does violates the GDPR.
>
> A loose interpretation is that The Qt Company does require the email 
> addresses for its business model and it is enough to
> be GDPR compliant.
>
> I guess we will not know which is the correct one until there is a trial with 
> a ruling of the CJEU.
> Until then I do not see the GDPR changi any company business model and 
> offering.

Article 5 doesn't say "technically". I did read it, and I think your
interpretation, and description of what is strict
and what is loose, is highly subjective.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Alexander Akulich

I would expect a significant negative effect on the quality of Qt
shipped in Linux distributions and thus negative effect on the
Qt-based applications and Qt reputation.

A maintainer can assume a bit more backporting, but let's have some
retrospective on the current LTS:
Compared to Qt 5.12.2, the new Qt 5.12.3 provides almost 200 bug fixes [1].
Compared to Qt 5.12.3, the new Qt 5.12.4 provides around 250 bug fixes [2].
This fifth patch release to Qt 5.12 LTS contains almost 280 bug fixes [3].
This sixth patch release for Qt 5.12 LTS series contains more than 50
bug fixes [4].

The number of commits is much more than the number of closed bug reports.
If the last open Qt 5 minor version will have three releases (5.15.0,
5.15.1, 5.15.2) then it is sensible to assume that the commercial Qt
branch will have at least 1000 commits on top of the public one. It is
barely possible for a single maintainer or a single community-driven
distribution to backport that many commits.

[1] https://www.qt.io/blog/2019/04/17/qt-5-12-3-released
[2] https://www.qt.io/blog/2019/06/17/qt-5-12-4-released-support-openssl-1-1-1
[3] https://www.qt.io/blog/qt-5.12.5-released
[4] https://www.qt.io/blog/qt-5.12.6-released

On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>
> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the 
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part of a 
> release is in the future going to be restricted to commercial customers. All 
> bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
> Backporting bug fixes is something that the Qt Company will take care of for 
> these LTS branches. We’ve seen over the past that LTS support is something 
> mainly required by large companies, and should hopefully help us get some 
> more commercial support for developing Qt further.
>
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a lower 
> priced product for small businesses. That small business product is btw not 
> limited to mobile like the one Digia had some years ago, but covers all of Qt 
> for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t be 
> any changes to Open Governance or the open development model.
>
> Best regards,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Assuming we have a VM that is restricted to connecting to the internet, we
previously could dump the installer there and install Qt.
Now, we need to have an intermediary PC with the same OS to first install
the binaries via online installer and then copy those binary files to that
first VM.

This is an extraneous and completely artificial step for absolutely no
reason other than TQtC paywalling them, which is ridiculous.

On Tue, Jan 28, 2020 at 12:46 AM Thiago Macieira 
wrote:

> On segunda-feira, 27 de janeiro de 2020 08:36:58 PST NIkolai Marchenko
> wrote:
> > Now every machine that needs qt libraries needs to be connected to the
> > internet if it doesn't pay. No expections.
> > This is a completely ridiculous bullshit move.
>
> Sorry, Nikolai, but WTF are you talking about?
>
> What does having to be connected have to do with anything? Previously, you
> didn't need a password to download, now you do. Either way, to *download*
> you
> need to be connected to the Internet.
>
> If the VM isn't connected, then it assumes it is getting the files from
> somewhere else, like a network share or the host machine. Why can't you
> download there and then copy over the same way you do today? Use the
> password
> to download the binary from another machine, then copy over.
>
> And if you can get files there, you can get a small .txt file with the
> password there.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Giuseppe D'Angelo via Development


Il 27/01/20 23:31, Benjamin TERRIER ha scritto:
The wiki states that "5.15 is 'dev' in the Qt 5 series", so my 
understanding is that all fixes, even those for the commercial LTS will 
need to go through the public 5.15 branch.


The wiki is wrong. Let's please not open the discussion about the status 
of the wiki. "dev" is Qt 6, "5.15" is the last Qt 5 branch (5.15).


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 23:23, Ville Voutilainen 
wrote:

>
> Correct. Necessary for specific purpose seems to be what article 5
> requires, and then you get explicit consent for that
> specific purpose, and GDPR's articles 5 and 6 are covered (of course
> the rest of article 5's requirements need to be covered).
> You're not necessarily going to like that specific purpose (or the
> outcome of all this, including the consent query),
> but GDPR requirements don't seem too difficult to fulfil, and there's
> nothing particular in the new offering that would
> instantly and obviously go even close to violating GDPR, based on my
> layman reading of it. I don't think GDPR
> will change the course of the offering, so if you want to change that
> course, I think you need a different avenue
> of argumentation.
>

Well it depends on how you interpret the GDPR, a strict interpretation is
that since The Qt Company does
not technically needs email addresses to distribute binary packages,
requiring users' email addresses
does violates the GDPR.

A loose interpretation is that The Qt Company does require the email
addresses for its business model and it is enough to
be GDPR compliant.

I guess we will not know which is the correct one until there is a trial
with a ruling of the CJEU.
Until then I do not see the GDPR changi any company business model and
offering.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Hi Cristián,

surely, everyone is technically able to cherry-pick and backport bug fixes
into their local Qt versions but not everybody has resources and/or
knowledge to do so.

I personally think this could be an inflection point into forking the Qt 5
"Community Edition", with all binary builds supported and maintained by the
community not affiliated with The Qt Company. There could be a Non-TQC Qt
5.15 Community LTS with backported bug fixes and maybe even new features.
As already mentioned in this thread, the free-to-download binary releases
would be the first thing to appear as soon as the Qt account will be
required.

Of course, there is always Qt Commercial offering but there could be
smaller 3rd party companies offering the same but for less money. It's a
free market but it would a split in the community, and  I personally see
this as a bad thing that can happen to the Qt Framework.

Cheers
Dmitriy

On Mon, Jan 27, 2020 at 11:16 PM Cristián Maureira-Fredes <
cristian.maureira-fre...@qt.io> wrote:

> Hello David,
>
> On 1/27/20 11:00 PM, David Edmundson wrote:
> >> All security fixes are made available to everyone, for all Qt versions
> that
> >> they affect, provided it's still a supported Qt version (or it was easy
> to
> >> make the fix).
> >>
> > If we could have that explicitly in writing from TQC, that would mean a
> lot.
>
> The blog post states:
>
> "We are changing our process in R to push all bug fixes to the main
> development branch first, and then backport selected bug fixes back into
> stable release branches. This process ensures that the latest version of
> Qt will always contain all bug fixes. This process change was discussed
> during the last Qt Contributor Summit – we communicate the exact process
> details when Qt 5.15 will be released. Otherwise, development processes
> and the governance model will not change."
>
> This means that you still have access to all the fixes for 5.15
> that happen after 5.15.2-3, since they will be on the dev branch.
>
>
> > I can easily envision a situation that affects only Qt5.15, but not
> > Qt6.0 at which point it's not covered by what has been suggested
> > officially so far as there would be nothing to cherry-pick.
> >
> > David
>
> If there is a bug on 5.15 and not on 6.0,
> a fix will be pushed to the dev branch, then cherry pick to the
> commercial LTS version, but the patch will still be there, so you
> can just added to your local Qt version.
>
> The Qt Contributors Summit discussion can be found here too:
> https://wiki.qt.io/Qt_Contributors_Summit_2019_-_Branch_Policy
>
>
> Cheers
>
> --
> Dr. Cristián Maureira-Fredes
> R Manager
>
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> https://qt.io
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 23:29, Ville Voutilainen 
wrote:

> On Tue, 28 Jan 2020 at 00:17, Cristián Maureira-Fredes
>  wrote:
> >
> > Hello David,
> >
> > On 1/27/20 11:00 PM, David Edmundson wrote:
> > >> All security fixes are made available to everyone, for all Qt
> versions that
> > >> they affect, provided it's still a supported Qt version (or it was
> easy to
> > >> make the fix).
> > >>
> > > If we could have that explicitly in writing from TQC, that would mean
> a lot.
> >
> > The blog post states:
> >
> > "We are changing our process in R to push all bug fixes to the main
> > development branch first, and then backport selected bug fixes back into
> > stable release branches. This process ensures that the latest version of
> > Qt will always contain all bug fixes. This process change was discussed
> > during the last Qt Contributor Summit – we communicate the exact process
> > details when Qt 5.15 will be released. Otherwise, development processes
> > and the governance model will not change."
> >
> > This means that you still have access to all the fixes for 5.15
> > that happen after 5.15.2-3, since they will be on the dev branch.
>
> The dev branch bug fixes don't necessarily apply cleanly to 5.15.
>
> > > I can easily envision a situation that affects only Qt5.15, but not
> > > Qt6.0 at which point it's not covered by what has been suggested
> > > officially so far as there would be nothing to cherry-pick.
> > >
> > > David
> >
> > If there is a bug on 5.15 and not on 6.0,
> > a fix will be pushed to the dev branch, then cherry pick to the
> > commercial LTS version, but the patch will still be there, so you
> > can just added to your local Qt version.
>
> And this sort of fixes might also not apply cleanly, or even exist at
> all, if 6 doesn't have the bug.
> 6 is dev, dev is 6, dev is not some perpetual 5.x+6.x upstream master
> branch.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


The wiki states that "5.15 is 'dev' in the Qt 5 series", so my
understanding is that all fixes, even those for the commercial LTS will
need to go through the public 5.15 branch.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Giuseppe D'Angelo via Development


Il 27/01/20 22:52, Thiago Macieira ha scritto:

All security fixes are made available to everyone, for all Qt versions that
they affect, provided it's still a supported Qt version (or it was easy to
make the fix).


I asked before, and got no reply: how, by whom, hosted where?

Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Den mån 27 jan. 2020 kl 23:16 skrev Cristián Maureira-Fredes
:
>
> Hello David,
>
> On 1/27/20 11:00 PM, David Edmundson wrote:
> >> All security fixes are made available to everyone, for all Qt versions that
> >> they affect, provided it's still a supported Qt version (or it was easy to
> >> make the fix).
> >>
> > If we could have that explicitly in writing from TQC, that would mean a lot.
>
> The blog post states:
>
> "We are changing our process in R to push all bug fixes to the main
> development branch first, and then backport selected bug fixes back into
> stable release branches. This process ensures that the latest version of
> Qt will always contain all bug fixes. This process change was discussed
> during the last Qt Contributor Summit – we communicate the exact process
> details when Qt 5.15 will be released. Otherwise, development processes
> and the governance model will not change."
>
> This means that you still have access to all the fixes for 5.15
> that happen after 5.15.2-3, since they will be on the dev branch.
>
>
> > I can easily envision a situation that affects only Qt5.15, but not
> > Qt6.0 at which point it's not covered by what has been suggested
> > officially so far as there would be nothing to cherry-pick.
> >
> > David
>
> If there is a bug on 5.15 and not on 6.0,
> a fix will be pushed to the dev branch, then cherry pick to the
> commercial LTS version, but the patch will still be there, so you
> can just added to your local Qt version.

Sorry if I'm misunderstanding something, but what if the bug only
exists in 5.15, not in dev? I think that's the situation David is
thinking of.

Elvis

>
> The Qt Contributors Summit discussion can be found here too:
> https://wiki.qt.io/Qt_Contributors_Summit_2019_-_Branch_Policy
>
>
> Cheers
>
> --
> Dr. Cristián Maureira-Fredes
> R Manager
>
> The Qt Company GmbH
> Erich-Thilo-Straße 10
> D-12489 Berlin
> https://qt.io
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On Tue, 28 Jan 2020 at 00:17, Cristián Maureira-Fredes
 wrote:
>
> Hello David,
>
> On 1/27/20 11:00 PM, David Edmundson wrote:
> >> All security fixes are made available to everyone, for all Qt versions that
> >> they affect, provided it's still a supported Qt version (or it was easy to
> >> make the fix).
> >>
> > If we could have that explicitly in writing from TQC, that would mean a lot.
>
> The blog post states:
>
> "We are changing our process in R to push all bug fixes to the main
> development branch first, and then backport selected bug fixes back into
> stable release branches. This process ensures that the latest version of
> Qt will always contain all bug fixes. This process change was discussed
> during the last Qt Contributor Summit – we communicate the exact process
> details when Qt 5.15 will be released. Otherwise, development processes
> and the governance model will not change."
>
> This means that you still have access to all the fixes for 5.15
> that happen after 5.15.2-3, since they will be on the dev branch.

The dev branch bug fixes don't necessarily apply cleanly to 5.15.

> > I can easily envision a situation that affects only Qt5.15, but not
> > Qt6.0 at which point it's not covered by what has been suggested
> > officially so far as there would be nothing to cherry-pick.
> >
> > David
>
> If there is a bug on 5.15 and not on 6.0,
> a fix will be pushed to the dev branch, then cherry pick to the
> commercial LTS version, but the patch will still be there, so you
> can just added to your local Qt version.

And this sort of fixes might also not apply cleanly, or even exist at
all, if 6 doesn't have the bug.
6 is dev, dev is 6, dev is not some perpetual 5.x+6.x upstream master branch.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On Tue, 28 Jan 2020 at 00:04, Benjamin TERRIER  wrote:
>> >> I know, but since there's no free right to download binaries, GDPR
>> >> doesn't prevent getting explicit consent before allowing
>> >> a download. Would you like me to give people more ideas? :)
>> > GDPR states that data collection shall be "limited to what is necessary".
>> > Requiring explicit consent for the user to provide data is not enough to 
>> > be GDPR compliant.
>> > The required data has to be "necessary".
>>
>> That is one of six lawful bases for processing data. There are five
>> others. GDPR doesn't require all six
>> to apply, it requires at least one.
>
>
> I believe you are talking about article 6, I am talking about article 5 which 
> does not have this "at least one" clause.

Correct. Necessary for specific purpose seems to be what article 5
requires, and then you get explicit consent for that
specific purpose, and GDPR's articles 5 and 6 are covered (of course
the rest of article 5's requirements need to be covered).
You're not necessarily going to like that specific purpose (or the
outcome of all this, including the consent query),
but GDPR requirements don't seem too difficult to fulfil, and there's
nothing particular in the new offering that would
instantly and obviously go even close to violating GDPR, based on my
layman reading of it. I don't think GDPR
will change the course of the offering, so if you want to change that
course, I think you need a different avenue
of argumentation.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Cristián Maureira-Fredes

Hello David,

On 1/27/20 11:00 PM, David Edmundson wrote:
>> All security fixes are made available to everyone, for all Qt versions that
>> they affect, provided it's still a supported Qt version (or it was easy to
>> make the fix).
>>
> If we could have that explicitly in writing from TQC, that would mean a lot.

The blog post states:

"We are changing our process in R to push all bug fixes to the main 
development branch first, and then backport selected bug fixes back into 
stable release branches. This process ensures that the latest version of 
Qt will always contain all bug fixes. This process change was discussed 
during the last Qt Contributor Summit – we communicate the exact process 
details when Qt 5.15 will be released. Otherwise, development processes 
and the governance model will not change."

This means that you still have access to all the fixes for 5.15
that happen after 5.15.2-3, since they will be on the dev branch.

> I can easily envision a situation that affects only Qt5.15, but not
> Qt6.0 at which point it's not covered by what has been suggested
> officially so far as there would be nothing to cherry-pick.
> 
> David

If there is a bug on 5.15 and not on 6.0,
a fix will be pushed to the dev branch, then cherry pick to the 
commercial LTS version, but the patch will still be there, so you
can just added to your local Qt version.

The Qt Contributors Summit discussion can be found here too:
https://wiki.qt.io/Qt_Contributors_Summit_2019_-_Branch_Policy

Cheers

-- 
Dr. Cristián Maureira-Fredes
R Manager

The Qt Company GmbH
Erich-Thilo-Straße 10
D-12489 Berlin
https://qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Kevin Kofler

Lars Knoll wrote:
> One is a change in policy regarding the LTS releases, where the LTS part
> of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first. Backporting bug fixes is something that the Qt Company
> will take care of for these LTS branches. We’ve seen over the past that
> LTS support is something mainly required by large companies, and should
> hopefully help us get some more commercial support for developing Qt
> further.

So you are going to leave Qt 5.x Free Software users with no short-term 
upgrade path, because 5.15 LTS will be reserved to commercial customers 
only? From a distribution standpoint, this is absolutely ridiculous and 
hostile. We are not going to get all software ported to Qt 6 instantly.

Most distributions are still forced to ship software depending on Qt 4 now. 
Fedora even still ships software depending on Qt 3! For both Qt 3 and 4, 
there was a period where Qt was still providing at least bug fixes for the 
software, which was important to help the transition. We really need that to 
happen for Qt 5 as well. Sure, we can and do backport security fixes (and we 
have to do so for Qt 3 and 4 which you no longer support), but our ability 
to backport complex bug fixes is limited, and it will really hurt to have to 
redo the work that you have to do anyway for your commercial customers.

Please reconsider this policy or at least consider making an exception for 
5.15 LTS (and generally the last release branch before a first-digit major 
version change).

Kevin Kofler

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

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 22:56, Ville Voutilainen 
wrote:

> On Mon, 27 Jan 2020 at 23:43, Benjamin TERRIER 
> wrote:
>
> >> I know, but since there's no free right to download binaries, GDPR
> >> doesn't prevent getting explicit consent before allowing
> >> a download. Would you like me to give people more ideas? :)
> > GDPR states that data collection shall be "limited to what is necessary".
> > Requiring explicit consent for the user to provide data is not enough to
> be GDPR compliant.
> > The required data has to be "necessary".
>
> That is one of six lawful bases for processing data. There are five
> others. GDPR doesn't require all six
> to apply, it requires at least one.
>

I believe you are talking about article 6, I am talking about article 5
which does not have this "at least one" clause.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread David Edmundson

> All security fixes are made available to everyone, for all Qt versions that
> they affect, provided it's still a supported Qt version (or it was easy to
> make the fix).
>
If we could have that explicitly in writing from TQC, that would mean a lot.

I can easily envision a situation that affects only Qt5.15, but not
Qt6.0 at which point it's not covered by what has been suggested
officially so far as there would be nothing to cherry-pick.

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

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 23:43, Benjamin TERRIER  wrote:

>> I know, but since there's no free right to download binaries, GDPR
>> doesn't prevent getting explicit consent before allowing
>> a download. Would you like me to give people more ideas? :)
> GDPR states that data collection shall be "limited to what is necessary".
> Requiring explicit consent for the user to provide data is not enough to be 
> GDPR compliant.
> The required data has to be "necessary".

That is one of six lawful bases for processing data. There are five
others. GDPR doesn't require all six
to apply, it requires at least one.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On segunda-feira, 27 de janeiro de 2020 07:26:55 PST NIkolai Marchenko wrote:
> > they will be available 12 months after their commercial release
> 
> That's 12 months for cybercriminals to exploit already fixed
> vulnerabilities in open source distros...

All security fixes are made available to everyone, for all Qt versions that 
they affect, provided it's still a supported Qt version (or it was easy to 
make the fix).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Changes to Qt offering

What will happen to Qt for Python? As for now, its binaries can be just
downloaded using pip (a Python package manager). Will it change as well?

Cheers
Dmitriy

On Mon, Jan 27, 2020 at 3:35 PM Lars Knoll  wrote:

> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020
> .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part
> of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first. Backporting bug fixes is something that the Qt Company will
> take care of for these LTS branches. We’ve seen over the past that LTS
> support is something mainly required by large companies, and should
> hopefully help us get some more commercial support for developing Qt
> further.
>
> The second change is that a Qt Account will be in the future required for
> binary packages. Source code will continue to be available as currently.
> This will simplify distribution and integration with the Marketplace. In
> addition, we want open source users to contribute to Qt or the Qt
> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
> review and the forums all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a
> lower priced product for small businesses. That small business product is
> btw not limited to mobile like the one Digia had some years ago, but covers
> all of Qt for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.
>
> Best regards,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On segunda-feira, 27 de janeiro de 2020 10:39:44 PST Elvis Stansvik wrote:
> So? I have an account because I want to contribute. Does not mean I
> want to log in to download (especially not from CI).

The CI aspect is actually pretty relevant. Aside from Appveyor, most other CI 
systems with Windows support (like GitHub Actions) do not have Qt pre-
installed. What people do to test on Windows is to use recipes that download 
the pre-compiled binaries and unpack them.

What does the Qt Company suggest software developers do?

(I know there's Conan, vcpkg, etc. I want the Qt Company's official answer)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products

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

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 22:35, Ville Voutilainen 
wrote:

> On Mon, 27 Jan 2020 at 23:12, André Somers  wrote:
> >
> >
> > On 27/01/2020 22:07, Ville Voutilainen wrote:
> > > On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin 
> wrote:
> > >> By the way, gathering emails by requiring an account to download the
> software without any technical reason might be indeed an example of a GDPR
> violation.
> > > I am not a lawyer, but I am unaware of any free software license that
> > > gives you a right to download binaries at the terms
> > > of your own choosing. Source downloads are a different matter.
> >
> > GDPR has nothing to do with software licenses.
>
> I know, but since there's no free right to download binaries, GDPR
> doesn't prevent getting explicit consent before allowing
> a download. Would you like me to give people more ideas? :)
>

GDPR states that data collection shall be "limited to what is necessary".

Requiring explicit consent for the user to provide data is not enough to be
GDPR compliant.
The required data has to be "necessary".
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On segunda-feira, 27 de janeiro de 2020 08:23:56 PST NIkolai Marchenko wrote:
> But there will likely be changes to the desire of people to develop.
> Imagine an opensource contributor making a security fix who knows other
> opensource users on older branches aren't going to receive it and there is
> no way for him to push it there.

Nothing changes there. All patches for security can be published for all 
branches. Those patches are often attached to the security announcement email.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products



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

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 23:12, André Somers  wrote:
>
>
> On 27/01/2020 22:07, Ville Voutilainen wrote:
> > On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin  wrote:
> >> By the way, gathering emails by requiring an account to download the 
> >> software without any technical reason might be indeed an example of a GDPR 
> >> violation.
> > I am not a lawyer, but I am unaware of any free software license that
> > gives you a right to download binaries at the terms
> > of your own choosing. Source downloads are a different matter.
>
> GDPR has nothing to do with software licenses.

I know, but since there's no free right to download binaries, GDPR
doesn't prevent getting explicit consent before allowing
a download. Would you like me to give people more ideas? :)
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

I am not a lawyer too, but in this case, if I download Qt for personal
reasons (hobby projects) I act as a natural person, and The Qt Company
gathers my email address, and this is personal information. Of course, I
consent to this specifically but the thing is, I have to consent because
The Qt Company forces me to. Otherwise, I can't download the binaries. And
I don't see how the need of gathering my email address as a natural person
is sufficiently explained to me.

Cheers
Dmitriy

On Mon, Jan 27, 2020 at 10:07 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

> On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin  wrote:
> >
> > By the way, gathering emails by requiring an account to download the
> software without any technical reason might be indeed an example of a GDPR
> violation.
>
> I am not a lawyer, but I am unaware of any free software license that
> gives you a right to download binaries at the terms
> of your own choosing. Source downloads are a different matter.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Pier Luigi Fiorini

Il giorno lun 27 gen 2020 alle ore 22:01 Alexander Akulich <
akulichalexan...@gmail.com> ha scritto:

>
> You already made life harder by licensing Qt under GPL v3. Of course,
> it has pros and cons, but let's jump to the consequence: we have
> Sailfish OS out of the boat. The OS could have a modern Qt and we
> actually could have people working on the upstream QtDeclarative, Qt
> Quick Controls 2 and other modules in the paid time, but. The OS
> developers have complex agreements with a number of important business
> partners and for some of them, it is unacceptable to follow some of
> the tivoization-related GPL v3 clauses. It is hard to explain to
> managers the profit from a new version or collaboration with the Qt
> community. (From a business PoV) it makes very little sense to pay for
> some abstract "technical prettiness" as long as Qt 5.6 gives you the
> money.
>

Jolla should just buy a proprietary license since the user facing bits are
proprietary as well.

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread André Somers



On 27/01/2020 22:07, Ville Voutilainen wrote:

On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin  wrote:

By the way, gathering emails by requiring an account to download the software 
without any technical reason might be indeed an example of a GDPR violation.

I am not a lawyer, but I am unaware of any free software license that
gives you a right to download binaries at the terms
of your own choosing. Source downloads are a different matter.


GDPR has nothing to do with software licenses.

André

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

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin  wrote:
>
> By the way, gathering emails by requiring an account to download the software 
> without any technical reason might be indeed an example of a GDPR violation.

I am not a lawyer, but I am unaware of any free software license that
gives you a right to download binaries at the terms
of your own choosing. Source downloads are a different matter.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Alexander Akulich

Your decision is not a reason to contribute more. It is going to hurt
the ecosystem because it makes it harder to get new developers and
users.

In some of my previous companies, we had a long release cycle so as a
Linux developer I could justify my paid time spent on upstreaming a
fix to get it included into the binary offline installers for all
platforms in about a month. The new policy cross-off this reason to
submit fixes.

You already made life harder by licensing Qt under GPL v3. Of course,
it has pros and cons, but let's jump to the consequence: we have
Sailfish OS out of the boat. The OS could have a modern Qt and we
actually could have people working on the upstream QtDeclarative, Qt
Quick Controls 2 and other modules in the paid time, but. The OS
developers have complex agreements with a number of important business
partners and for some of them, it is unacceptable to follow some of
the tivoization-related GPL v3 clauses. It is hard to explain to
managers the profit from a new version or collaboration with the Qt
community. (From a business PoV) it makes very little sense to pay for
some abstract "technical prettiness" as long as Qt 5.6 gives you the
money.

On the professional side, I suddenly understand how much I'm depending
on Qt. I spent my paid and spare time to make the world and the Qt
world better, but now I'm sad and disappointed. The world is changing
so fast. Years ago I taught students to the light side with C++, Qt,
and open source. I can't imagine asking dozens of students to register
and get Qt Account. Nowadays and with this step, I see even fewer
reasons to learn C++ and Qt.

I respect and appreciate the work of all Qt developers. Thank you all
for the amazing technology. Long live Qt! I hope we won't have to
fork.

On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>
> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the 
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part of a 
> release is in the future going to be restricted to commercial customers. All 
> bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
> Backporting bug fixes is something that the Qt Company will take care of for 
> these LTS branches. We’ve seen over the past that LTS support is something 
> mainly required by large companies, and should hopefully help us get some 
> more commercial support for developing Qt further.
>
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a lower 
> priced product for small businesses. That small business product is btw not 
> limited to mobile like the one Digia had some years ago, but covers all of Qt 
> for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t be 
> any changes to Open Governance or the open development model.
>
> Best regards,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

By the way, gathering emails by requiring an account to download the
software without any technical reason might be indeed an example of a GDPR
violation.

Cheers
Dmitriy

On Mon, Jan 27, 2020 at 7:36 PM Frederik Schwarzer 
wrote:

> Am 27.01.2020 15:34 schrieb Lars Knoll:
>
> Hi,
>
> > The second change is that a Qt Account will be in the future required
> > for binary packages.
>
> We (as an embedded software company) depend a lot on commercial hardware
> with the software tools that are provided by the hardware vendors. The
> most annoying part of that is the need to log in for downloading that
> software. For those vendors there is no reason to require a log in
> technically. The software is not tied to the hardware or anything. It's
> probably just for data collection reasons. It sometimes just takes hours
> before they call your phone trying to sell you something. ...
> What this leads to here is that someone creates an account and puts some
> version of the software on our internal server. Everyone then uses that
> version instead of registering yet another account. The software on our
> server reaches back years and there is no plan updating. That's what
> happens if you put barriers in front of people. You get users who use
> old version.
>
>
> >  In addition, we want open source users to contribute to Qt or the Qt
> > ecosystem. Doing so is only possible with a valid Qt Account
>
> I do not believe that requiring an account leads to more contributions.
> It just leads to more emails in yet another database that will
> eventually be found open to the public due to some misconfiguration.
> Only collect personal data if it is really needed.
>
>
> > The third change is that The Qt Company will in the future also offer
> > a lower priced product for small businesses. That small business
> > product is btw not limited to mobile like the one Digia had some years
> > ago, but covers all of Qt for Device Creation.
>
> That however, seems good news. :)
>
> Regards,
> Frederik
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt 5.13 & 5.14 add device-independent pixels to device-dependent

I had fixed this prior to 5.13 but the patch was never accepted:
https://codereview.qt-project.org/c/qt/qtbase/+/188493
https://bugreports.qt.io/browse/QTBUG-58329
https://build.opensuse.org/package/view_file/
home:thiagomacieira:branches:openSUSE:Factory/libqt5-qtbase/0001-HighDpi-Fix-
handling-of-the-screen-origin-point.patch?expand=1

The problem is that Qt is adding device-independent pixels to device-dependent 
ones when calculating the positions of anything outside the first screen and 
coming up with nonsense. This can be seen from these lines in qtdiag:

  Geometry: 1920x1080+3200+0 (native: 3840x2160+3200+0) Available: 
1920x1080+3200+0
  Virtual geometry: 5120x1080+0+0 Available: 5120x1080+0+0

The number 5120 is 1920+3200, but 1920 is a scaled number and 3200 isn't. That 
means 5120 is a nonsensical result. The end result is that positioning of many 
things are off.

I've filed https://bugreports.qt.io/browse/QTBUG-81695, but I'm reporting here 
because this issue affects kmail majorly in 5.14 and thus makes it VERY 
difficult for me to work. Please consider this bug a P0.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products
Screens: 2, High DPI scaling: active
# 0 "eDP1" Depth: 24 Primary: yes
  Manufacturer: Sharp Corporation
  Model: 
  Serial number: 
  Geometry: 1600x900+0+0 (native: 3200x1800+0+0) Available: 1600x900+0+0
  Virtual geometry: 5120x1080+0+0 Available: 5120x1080+0+0
  2 virtual siblings
  Physical size: 290x170 mm  Refresh: 59.9818 Hz Power state: 0
  Physical DPI: 140.138,134.471 Logical DPI: 108,108 (native: 216.747,216.854) 
Subpixel_None
  High DPI scaling factor: 2 DevicePixelRatio: 2 Pixel density: 1
  Primary orientation: 2 Orientation: 2 Native orientation: 0 
OrientationUpdateMask: 0

# 1 "DP1-1" Depth: 24 Primary: no
  Manufacturer: Dell Inc.
  Model: DELL P2715Q-
  Serial number: X24K1693BS8L-
  Geometry: 1920x1080+3200+0 (native: 3840x2160+3200+0) Available: 
1920x1080+3200+0
  Virtual geometry: 5120x1080+0+0 Available: 5120x1080+0+0
  2 virtual siblings
  Physical size: 600x340 mm  Refresh: 23.976 Hz Power state: 0
  Physical DPI: 81.28,80.6824 Logical DPI: 108,108 (native: 216.747,216.854) 
Subpixel_None
  High DPI scaling factor: 2 DevicePixelRatio: 2 Pixel density: 1
  Primary orientation: 2 Orientation: 2 Native orientation: 0 
OrientationUpdateMask: 0
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Giuseppe D'Angelo via Development


Il 27/01/20 19:28, Tuukka Turunen ha scritto:
I do not know why the link does not work. But I remember that post very 
well.

[snip]


I wasn't commenting on the merits of the new decision, but on the choice 
of hiding a blog post that was perfectly visible until a few hours ago.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Konstantin Tokarev



27.01.2020, 21:30, "Tuukka Turunen" :
> Hi,
>
> I do not know why the link does not work. But I remember that post very well.
>
> On hindsight, it was too much of a rush back then to ask everyone to create a 
> Qt account immediately.
>
> As I wrote in my earlier reply, situation is different now:
>
> * Most users have already Qt account

FWIW, I've recently helped one Qt user on IRC who was refraining from 
submitting a bug report because they thought it was required to buy Qt license 
to obtain Qt account.

> * Marketplace needs it
> * More common to be connected
> If someone does not want to use Qt account, it is possible to build from 
> source.
>
> Yours,
>
> Tuukka


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

Re: [Development] Changes to Qt offering

Den mån 27 jan. 2020 kl 19:30 skrev Tuukka Turunen :
>
>
> Hi,
>
> I do not know why the link does not work. But I remember that post very well.
>
> On hindsight, it was too much of a rush back then to ask everyone to create a 
> Qt account immediately.
>
> As I wrote in my earlier reply, situation is different now:
>
> Most users have already Qt account

So? I have an account because I want to contribute. Does not mean I
want to log in to download (especially not from CI).

> Marketplace needs it

This is not a non-reason. It is based on the assumption that everyone
wants to use the Marketplace, which I very much doubt is the case.

> More common to be connected

Now I guess you're talking about the artificial pulling of offline
installers, and not the Qt Account requirement. In any case, just
because I have a connection does not mean I want to use it, nor
provide a login to download. I may want to download the offline
installer and use it X times.

>
> If someone does not want to use Qt account, it is possible to build from 
> source.

No comment.

Elvis

>
> Yours,
>
> Tuukka
>
> 
> Lähettäjä: Development  käyttäjän 
> Giuseppe D'Angelo via Development  puolesta
> Lähetetty: maanantaina, tammikuuta 27, 2020 8:13 ip.
> Vastaanottaja: development@qt-project.org
> Aihe: Re: [Development] Changes to Qt offering
>
> Il 27/01/20 16:57, Benjamin TERRIER ha scritto:
>
> We do hope that this eases your concerns, and that we can continue with your 
> trust.
>
>
> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>
>
> That blog post is now removed. The URL is correct, as it's cross referenced 
> from other blog posts.
>
> I won't comment on how professional this sounds.
>
> Anyhow:
>
> https://web.archive.org/web/20200127170008/https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Frederik Schwarzer


Am 27.01.2020 15:34 schrieb Lars Knoll:

Hi,


The second change is that a Qt Account will be in the future required
for binary packages.


We (as an embedded software company) depend a lot on commercial hardware 
with the software tools that are provided by the hardware vendors. The 
most annoying part of that is the need to log in for downloading that 
software. For those vendors there is no reason to require a log in 
technically. The software is not tied to the hardware or anything. It's 
probably just for data collection reasons. It sometimes just takes hours 
before they call your phone trying to sell you something. ...
What this leads to here is that someone creates an account and puts some 
version of the software on our internal server. Everyone then uses that 
version instead of registering yet another account. The software on our 
server reaches back years and there is no plan updating. That's what 
happens if you put barriers in front of people. You get users who use 
old version.



 In addition, we want open source users to contribute to Qt or the Qt 
ecosystem. Doing so is only possible with a valid Qt Account


I do not believe that requiring an account leads to more contributions. 
It just leads to more emails in yet another database that will 
eventually be found open to the public due to some misconfiguration. 
Only collect personal data if it is really needed.




The third change is that The Qt Company will in the future also offer
a lower priced product for small businesses. That small business
product is btw not limited to mobile like the one Digia had some years
ago, but covers all of Qt for Device Creation.


That however, seems good news. :)

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

Re: [Development] Changes to Qt offering


Hi,

I do not know why the link does not work. But I remember that post very well.

On hindsight, it was too much of a rush back then to ask everyone to create a 
Qt account immediately.

As I wrote in my earlier reply, situation is different now:

  *   Most users have already Qt account
  *   Marketplace needs it
  *   More common to be connected

If someone does not want to use Qt account, it is possible to build from source.

Yours,

Tuukka


Lähettäjä: Development  käyttäjän Giuseppe 
D'Angelo via Development  puolesta
Lähetetty: maanantaina, tammikuuta 27, 2020 8:13 ip.
Vastaanottaja: development@qt-project.org
Aihe: Re: [Development] Changes to Qt offering

Il 27/01/20 16:57, Benjamin TERRIER ha scritto:
We do hope that this eases your concerns, and that we can continue with your 
trust.


https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer


That blog post is now removed. The URL is correct, as it's cross referenced 
from other blog posts.

I won't comment on how professional this sounds.

Anyhow:

https://web.archive.org/web/20200127170008/https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer


--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com 
| Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Den mån 27 jan. 2020 kl 19:12 skrev Giuseppe D'Angelo via Development
:
>
> Il 27/01/20 16:57, Benjamin TERRIER ha scritto:
>
> We do hope that this eases your concerns, and that we can continue with your 
> trust.
>
>
> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>
>
> That blog post is now removed. The URL is correct, as it's cross referenced 
> from other blog posts.
>
> I won't comment on how professional this sounds.

Seriously TQtC, wtf? After 20+ years of using Qt, all of this
ass-hattery put together is seriously making me consider leaving and
not looking back.

Elvis

>
> Anyhow:
>
> https://web.archive.org/web/20200127170008/https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>
>
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Giuseppe D'Angelo via Development


Il 27/01/20 16:57, Benjamin TERRIER ha scritto:
*We do hope that this eases your concerns, and that we can continue 
with your trust*.



https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer



That blog post is now removed. The URL is correct, as it's cross 
referenced from other blog posts.


I won't comment on how professional this sounds.

Anyhow:


https://web.archive.org/web/20200127170008/https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer


--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Cristian Adam

> -Original Message-

> From: Development  On Behalf Of

> Konstantin Tokarev

> Sent: Monday, 27 January 2020 17:52

> To: Lars Knoll ; Qt development mailing list

> 

> Subject: Re: [Development] Changes to Qt offering

>

>

>

> 27.01.2020, 17:36, "Lars Knoll" mailto:lars.kn...@qt.io>>:

> > The second change is that a Qt Account will be in the future required for

> binary packages. Source code will continue to be available as currently. This

> will simplify distribution and integration with the Marketplace. In addition,

> we want open source users to contribute to Qt or the Qt ecosystem. Doing

> so is only possible with a valid Qt Account (Jira, code review and the forums

> all require a Qt Account).

>

> Will it be possible to download binaries bypassing QtIFW installer while

> having appropriate credentials? Right now, both online and offline installers

> are very inefficient to use in free CI systems like Travis CI, and many people

> including me are using scripts which download and unpack minimal set of 7z

> packages directly.

>

> --

> Regards,

> Konstantin

>



Hi,



In the FAQ 
PDF
 we have the following:



What should users do that need to install Qt in a CI / scripted setup?



The non-LTS part of the releases is available in the Qt repositories for 
everyone just like currently. For

commercial license holders, the access is granted for the LTS part using their 
Qt Account.



I hope that one can still download and unpack the minimal set of 7z packages 
directly. I used this

functionality to describe how one can use GitHub actions to build Qt Creator 
plugins against official

Qt binaries at: 
https://www.qt.io/blog/building-qt-creator-plugins-with-github-actions



The online installer requires GUI access, even from command line, and the 
GitHub Actions runners do not offer it.



Cheers,

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Giuseppe D'Angelo via Development


Il 27/01/20 18:39, NIkolai Marchenko ha scritto:
Honestly, if we think into the future it looks like compiling qt is too 
straightforward and doesn't incentivise commercial licenses enough. So 
the next big thing will be to make compiling qt an "evolving experience" 
with flags and possible buildsystems changing from version to version 
(hello cmake). Then, some part of a build will require to input online 
credentials to work. And so on. Because clearly removing offline 
installer will just make people go "okay, it's super annoying but I can 
create binaries myself" instead of "okay, it's super annoying, let's pay qt"


1) That is borderline violating the (L)GPL
2) Say hello to endless 3rd party websites distributing Qt binaries or 
easy recipes for compilation (Conan, vcpkg, choco, etc.)


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

> It is cheaper and faster to make your own offline installer.
Honestly, if we think into the future it looks like compiling qt is too
straightforward and doesn't incentivise commercial licenses enough. So the
next big thing will be to make compiling qt an "evolving experience" with
flags and possible buildsystems changing from version to version
(hello cmake). Then, some part of a build will require to input online
credentials to work. And so on. Because clearly removing offline installer
will just make people go "okay, it's super annoying but I can create
binaries myself" instead of "okay, it's super annoying, let's pay qt"

On Mon, Jan 27, 2020 at 7:49 PM Benjamin TERRIER 
wrote:

> I've had a Qt account for years, it doesn't change that I do not want to
> use it to download a Qt version.
>
> It is obvious that that in the world that we live today having an account
>> for a service is not a blocker for people in general.
>>
>
> Qt users are not "people in general", they are software developers and
> they understand that this is an artificial barrier.
> I hope all software developers understand that they should not need an
> authenticated access to download public tars of an open source project.
>
> we believe that we provide value to our users through the installer and
>> the Qt Marketplace to justify the Qt Account.
>>
>
> Do all Qt users have value in the Qt Marketplace?
> For open source user, I am pretty sure the answer is no.
> For commercial/company users, I doubt all developers need access to the
> marketplace.
>
> What does the installer brings now that was not their in 2015 ?
> Nothing. So it was a bad idea in 2015, and still is a bad idea.
>
> On a more general note. It seems you are trying to make money by taking
> feature from the open source versions (like the offline installer).
> What you take really hurts the usage of open source users and hurts the Qt
> community.
> But at the same time I am not sure these small features will justify
> buying a license that  cost several thousand dollars per seat.
> Especially when company that want to move from open source to commercial
> have to pay a prohibitive retroactive license fee.
> It is cheaper and faster to make your own offline installer.
>
> Le lun. 27 janv. 2020 à 17:25, Tuukka Turunen  a
> écrit :
>
>>
>> Hi,
>>
>> Well, quite many things have changed since 2015. One important item is
>> that almost one million users have already voluntarily created (and
>> verified) themselves a Qt account.
>>
>> See the FAQ (linked from the blog post):
>>
>> “Q: Will requiring the Qt Account drive away all Qt users?
>> A: We have had the Qt Account as an option for over 4 years, and during
>> that time there has been already nearly a million people who have
>> registered and verified their Qt Account. It is obvious that that in the
>> world that we live today having an account for a service is not a blocker
>> for people in general. Everyone has the option of building Qt from sources
>> if they do not like the installer, but we believe that we provide value to
>> our users through the installer and the Qt Marketplace to justify the Qt
>> Account.“
>>
>> Yours,
>>
>> Tuukka
>>
>> --
>> *Lähettäjä:* Development  käyttäjän
>> Benjamin TERRIER  puolesta
>> *Lähetetty:* maanantaina, tammikuuta 27, 2020 6:03 ip.
>> *Vastaanottaja:* Qt development mailing list
>> *Aihe:* Re: [Development] Changes to Qt offering
>>
>> Quoting The Qt Company itslef:
>>
>> Thanks for your feedback to the new online installer asking for a Qt
>>> Account signup. We have evaluated the feedback received via the blog,
>>> various discussion forums, irc and other channels. Based on all these
>>> comments and discussions with our partners we realize that this was not our
>>> finest moment.
>>> Preventing the growth and usage of Qt in the open source community is
>>> not what we want to happen. We did already see a nice jump in the number of
>>> Qt Accounts,
>>> but it was never our intention to make our valued community and
>>> contributors upset with us or stop using and contributing to Qt.
>>> *We clearly ill-calculated how asking for a Qt Account with the online
>>> installer would make our users feel*. A mistake. Sincere apologies.
>>>
>> [...]
>>> *We do hope that this eases your concerns, and that we can continue with
>>> your trust*.
>>>
>>>
>>>
>>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>>
>>
>>  So apparently the trust of the QT community os nt a concern anymore...
>>
>> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
>> a écrit :
>>
>>> I am afraid I do not have other words for this model than : absolutely
>>> disgusting and a complete dick move. Especially login requirement for
>>> binaries.
>>> I don't even understand how distros are now supposed to keep qt code
>>> safe since constantly pushing qt version up is recipe for problems and
>>> there will be no critical bugfixes to branches

Re: [Development] Changes to Qt offering

Literally this whole thing could be: "we're making a cheaper offering for
small teams" and see where it goes. Instead it's one wholesome " you!"
package to the community at large.

On Mon, Jan 27, 2020 at 7:55 PM Florian Bruhin  wrote:

> Hey,
>
> On Mon, Jan 27, 2020 at 04:00:48PM +, Tuukka Turunen wrote:
> > After the change every release of Qt will look like a non-lts release for
> > open-source users. Think of Qt 5.14 as an example. It was released in
> > December. Today it received the first patch release. There will be more
> > before next feature release is out. For open-source user Qt 5.15 will
> look
> > just like Qt 5.14 does.
>
> Except that the next release after Qt 5.15 won't be 5.16 but Qt 6.
>
> How does the transition story for open source projects look there? If the
> (security) support for Qt 5.15 is dropped as soon as Qt 6 is released, does
> that mean projects would have to migrate immediately? What if they are
> using
> third-party libraries which need to be migrated first?
>
> I'm aware that Qt 5 -> Qt 6 is supposed to be a manageable change (and
> smaller
> than 3 -> 4 or 4 -> 5). But still, expecting projects to essentially have
> migrated before Qt 6 is released isn't exactly realistic...
>
> Am I missing something there?
>
> Florian
>
> --
> m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org
>https://bruhin.software/ |
> https://github.com/sponsors/The-Compiler/
>GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
>  I love long mails! | https://email.is-not-s.ms/
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Konstantin Tokarev



27.01.2020, 17:36, "Lars Knoll" :
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).

Will it be possible to download binaries bypassing QtIFW installer while having 
appropriate credentials? Right now, both online and offline installers are very 
inefficient to use in free CI systems like Travis CI, and many people including 
me are using scripts which download and unpack minimal set of 7z packages 
directly.

-- 
Regards,
Konstantin

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Florian Bruhin

Hey,

On Mon, Jan 27, 2020 at 04:00:48PM +, Tuukka Turunen wrote:
> After the change every release of Qt will look like a non-lts release for
> open-source users. Think of Qt 5.14 as an example. It was released in
> December. Today it received the first patch release. There will be more
> before next feature release is out. For open-source user Qt 5.15 will look
> just like Qt 5.14 does.

Except that the next release after Qt 5.15 won't be 5.16 but Qt 6.

How does the transition story for open source projects look there? If the
(security) support for Qt 5.15 is dropped as soon as Qt 6 is released, does
that mean projects would have to migrate immediately? What if they are using
third-party libraries which need to be migrated first?

I'm aware that Qt 5 -> Qt 6 is supposed to be a manageable change (and smaller
than 3 -> 4 or 4 -> 5). But still, expecting projects to essentially have
migrated before Qt 6 is released isn't exactly realistic...

Am I missing something there?

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/

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

Re: [Development] Changes to Qt offering

>  A: We have had the Qt Account as an option for over 4 years, and during
that time there has been already nearly a million people who have
registered and verified their Qt Account.
And how many of them use these accounts to download qt, eh? I bet you they
only use the acc to login to bugtracker and develop qt.
No one wants to enter credentials to reinstal qt. Period.

On Mon, Jan 27, 2020 at 7:39 PM NIkolai Marchenko 
wrote:

>  > and the offline installer will become available to commercial
> licensees only
> Not to mention "free qt binaries installer" will become a third party
> thing like, immediately.
>
> On Mon, Jan 27, 2020 at 7:37 PM Benjamin TERRIER 
> wrote:
>
>> My understanding of the agreement between The Qt Company and the KDE Free
>> Qt Foundation is that if the Qt Company
>> releases a commercial Qt version without releasing the corresponding
>> open-source version within 12 months, the ownership of Qt will be
>> transferred
>> to the KDE Free Qt Foundation under a BSD license. (section 3.(ii)).
>>
>> I am pretty sure a source only release would be enough. So I bet that the
>> LTS branches will be public, but we will not have a binary release through
>> the installer.
>>
>> Le lun. 27 janv. 2020 à 17:17, Bogdan Vatra via Development <
>> development@qt-project.org> a écrit :
>>
>>> Hi Lars,
>>>
>>> În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
>>> > Hi all,
>>> [...]
>>> >
>>> > One is a change in policy regarding the LTS releases, where the LTS
>>> part of
>>> > a release is in the future going to be restricted to commercial
>>> customers.
>>> > All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
>>> > first.
>>>
>>>   I was at the Qt Contributor Summit, and I can swear that I not heard
>>> anything about LTS being restricted to commercial customers...
>>>
>>> Just to be crystal clear, will you close also the branches?
>>> What will happen if I want to fix something in one of these LTS branches?
>>>
>>> > Backporting bug fixes is something that the Qt Company will take
>>> > care of for these LTS branches. We’ve seen over the past that LTS
>>> support
>>> > is something mainly required by large companies, and should hopefully
>>> help
>>> > us get some more commercial support for developing Qt further.
>>>
>>> I bet you the following scenario will happen soon:
>>> - someone will fork Qt LTS (most probably immediately after you closed
>>> these
>>> branches, if not even sooner)
>>> - the community will continue to support that fork as it's open, with
>>> improvements, bug fixes, security patches, etc.
>>> - you'll not get these patches as they are not contributed via your
>>> gerrit...
>>>
>>>
>>> > None of these changes should affect how Qt is being developed. There
>>> won’t
>>> > be any changes to Open Governance or the open development model.
>>>
>>>  If the qt5 branches will NOT be closed, then yes, you are right, if
>>> they will
>>> be closed then, I'm afraid, your statement can't stand...
>>>
>>> Cheers,
>>> BogDan.
>>>
>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

I've had a Qt account for years, it doesn't change that I do not want to
use it to download a Qt version.

It is obvious that that in the world that we live today having an account
> for a service is not a blocker for people in general.
>

Qt users are not "people in general", they are software developers and they
understand that this is an artificial barrier.
I hope all software developers understand that they should not need an
authenticated access to download public tars of an open source project.

we believe that we provide value to our users through the installer and the
> Qt Marketplace to justify the Qt Account.
>

Do all Qt users have value in the Qt Marketplace?
For open source user, I am pretty sure the answer is no.
For commercial/company users, I doubt all developers need access to the
marketplace.

What does the installer brings now that was not their in 2015 ?
Nothing. So it was a bad idea in 2015, and still is a bad idea.

On a more general note. It seems you are trying to make money by taking
feature from the open source versions (like the offline installer).
What you take really hurts the usage of open source users and hurts the Qt
community.
But at the same time I am not sure these small features will justify buying
a license that  cost several thousand dollars per seat.
Especially when company that want to move from open source to commercial
have to pay a prohibitive retroactive license fee.
It is cheaper and faster to make your own offline installer.

Le lun. 27 janv. 2020 à 17:25, Tuukka Turunen  a
écrit :

>
> Hi,
>
> Well, quite many things have changed since 2015. One important item is
> that almost one million users have already voluntarily created (and
> verified) themselves a Qt account.
>
> See the FAQ (linked from the blog post):
>
> “Q: Will requiring the Qt Account drive away all Qt users?
> A: We have had the Qt Account as an option for over 4 years, and during
> that time there has been already nearly a million people who have
> registered and verified their Qt Account. It is obvious that that in the
> world that we live today having an account for a service is not a blocker
> for people in general. Everyone has the option of building Qt from sources
> if they do not like the installer, but we believe that we provide value to
> our users through the installer and the Qt Marketplace to justify the Qt
> Account.“
>
> Yours,
>
> Tuukka
>
> --
> *Lähettäjä:* Development  käyttäjän
> Benjamin TERRIER  puolesta
> *Lähetetty:* maanantaina, tammikuuta 27, 2020 6:03 ip.
> *Vastaanottaja:* Qt development mailing list
> *Aihe:* Re: [Development] Changes to Qt offering
>
> Quoting The Qt Company itslef:
>
> Thanks for your feedback to the new online installer asking for a Qt
>> Account signup. We have evaluated the feedback received via the blog,
>> various discussion forums, irc and other channels. Based on all these
>> comments and discussions with our partners we realize that this was not our
>> finest moment.
>> Preventing the growth and usage of Qt in the open source community is not
>> what we want to happen. We did already see a nice jump in the number of Qt
>> Accounts,
>> but it was never our intention to make our valued community and
>> contributors upset with us or stop using and contributing to Qt.
>> *We clearly ill-calculated how asking for a Qt Account with the online
>> installer would make our users feel*. A mistake. Sincere apologies.
>>
> [...]
>> *We do hope that this eases your concerns, and that we can continue with
>> your trust*.
>>
>>
>>
>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>
>
>  So apparently the trust of the QT community os nt a concern anymore...
>
> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
> a écrit :
>
>> I am afraid I do not have other words for this model than : absolutely
>> disgusting and a complete dick move. Especially login requirement for
>> binaries.
>> I don't even understand how distros are now supposed to keep qt code safe
>> since constantly pushing qt version up is recipe for problems and there
>> will be no critical bugfixes to branches that distros were stabilized at.
>>
>>
>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>
>>> Hi all,
>>>
>>> The Qt Company has done some adjustments to the Qt will be offered in
>>> the future. Please check out
>>> https://www.qt.io/blog/qt-offering-changes-2020 .
>>>
>>> The change consists of three parts.
>>>
>>> One is a change in policy regarding the LTS releases, where the LTS part
>>> of a release is in the future going to be restricted to commercial
>>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>>> into dev first. Backporting bug fixes is something that the Qt Company will
>>> take care of for these LTS branches. We’ve seen over the past that LTS
>>> support is something mainly required by large companies, and should
>>> hopefully help us get some more commercial

Re: [Development] Changes to Qt offering

2020-01-27 Thread Giuseppe D'Angelo via Development


On 27/01/2020 17:25, Simon Hausmann wrote:

The development model where changes go to dev first was indeed a topic
of discussion at the Qt Contributor Summit.

This also means that all security fixes will see the light of day on the
dev branch first, in public, in Gerrit.


Some other remark (and please substitute 5.15 / 6 with "latest LTS" and 
"dev" at your discretion; of course 5.15 is going to be a particular 
pain point being the last in the 5 series, so I expect people to be 
using it for a very long time).


1) This means there will be exactly zero incentive from 3rd parties at 
fixing bugs only present in Qt 5(.15) and not in Qt 6; or, similarly, to 
put effort in producing a cherry pick from Qt 6.x to 5.15 (but Lars said 
that TQC will be in charge of this), *especially* if they're not using 
Qt 6 yet.


2) It also means that someone pushing a bugfix against 5.15 for a bug 
that also affects 6.x will see that patch rejected (-2) as it would be 
in violation of the Qt policy. Again it won't matter if they're not 
using Qt 6 and can't care about it.


3) Speaking of which, is the plan to effectively fork 5.15 when it 
switches to commercial-only, and have a private TQC 5.15 branch, where 
TQC will do the cherry-picking and release from? Will the public branch 
/ releases be closed? In other words: what are the practicalities for 
all of this?


4) What's the policy for very important bugfixes targeting 5.15 after it 
has switched to commercial only? Will a new open source release be made? 
Will an official patch be provided? Where? By whom?


Thanks,

--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

 > and the offline installer will become available to commercial licensees
only
Not to mention "free qt binaries installer" will become a third party thing
like, immediately.

On Mon, Jan 27, 2020 at 7:37 PM Benjamin TERRIER 
wrote:

> My understanding of the agreement between The Qt Company and the KDE Free
> Qt Foundation is that if the Qt Company
> releases a commercial Qt version without releasing the corresponding
> open-source version within 12 months, the ownership of Qt will be
> transferred
> to the KDE Free Qt Foundation under a BSD license. (section 3.(ii)).
>
> I am pretty sure a source only release would be enough. So I bet that the
> LTS branches will be public, but we will not have a binary release through
> the installer.
>
> Le lun. 27 janv. 2020 à 17:17, Bogdan Vatra via Development <
> development@qt-project.org> a écrit :
>
>> Hi Lars,
>>
>> În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
>> > Hi all,
>> [...]
>> >
>> > One is a change in policy regarding the LTS releases, where the LTS
>> part of
>> > a release is in the future going to be restricted to commercial
>> customers.
>> > All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
>> > first.
>>
>>   I was at the Qt Contributor Summit, and I can swear that I not heard
>> anything about LTS being restricted to commercial customers...
>>
>> Just to be crystal clear, will you close also the branches?
>> What will happen if I want to fix something in one of these LTS branches?
>>
>> > Backporting bug fixes is something that the Qt Company will take
>> > care of for these LTS branches. We’ve seen over the past that LTS
>> support
>> > is something mainly required by large companies, and should hopefully
>> help
>> > us get some more commercial support for developing Qt further.
>>
>> I bet you the following scenario will happen soon:
>> - someone will fork Qt LTS (most probably immediately after you closed
>> these
>> branches, if not even sooner)
>> - the community will continue to support that fork as it's open, with
>> improvements, bug fixes, security patches, etc.
>> - you'll not get these patches as they are not contributed via your
>> gerrit...
>>
>>
>> > None of these changes should affect how Qt is being developed. There
>> won’t
>> > be any changes to Open Governance or the open development model.
>>
>>  If the qt5 branches will NOT be closed, then yes, you are right, if they
>> will
>> be closed then, I'm afraid, your statement can't stand...
>>
>> Cheers,
>> BogDan.
>>
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

>  having an account for a service is not a blocker for people in general.
Unless they are on a VM and entering the password for said account is an
absolute annoyance.

Also, I would like to raise a more important change:
> and the offline installer will become available to commercial licensees
only

Now every machine that needs qt libraries needs to be connected to the
internet if it doesn't pay. No expections.
This is a completely ridiculous bullshit move.

On Mon, Jan 27, 2020 at 7:34 PM Tuukka Turunen  wrote:

>
> Hi,
>
> Well, quite many things have changed since 2015. One important item is
> that almost one million users have already voluntarily created (and
> verified) themselves a Qt account.
>
> See the FAQ (linked from the blog post):
>
> “Q: Will requiring the Qt Account drive away all Qt users?
> A: We have had the Qt Account as an option for over 4 years, and during
> that time there has been already nearly a million people who have
> registered and verified their Qt Account. It is obvious that that in the
> world that we live today having an account for a service is not a blocker
> for people in general. Everyone has the option of building Qt from sources
> if they do not like the installer, but we believe that we provide value to
> our users through the installer and the Qt Marketplace to justify the Qt
> Account.“
>
> Yours,
>
> Tuukka
>
> --
> *Lähettäjä:* Development  käyttäjän
> Benjamin TERRIER  puolesta
> *Lähetetty:* maanantaina, tammikuuta 27, 2020 6:03 ip.
> *Vastaanottaja:* Qt development mailing list
> *Aihe:* Re: [Development] Changes to Qt offering
>
> Quoting The Qt Company itslef:
>
> Thanks for your feedback to the new online installer asking for a Qt
>> Account signup. We have evaluated the feedback received via the blog,
>> various discussion forums, irc and other channels. Based on all these
>> comments and discussions with our partners we realize that this was not our
>> finest moment.
>> Preventing the growth and usage of Qt in the open source community is not
>> what we want to happen. We did already see a nice jump in the number of Qt
>> Accounts,
>> but it was never our intention to make our valued community and
>> contributors upset with us or stop using and contributing to Qt.
>> *We clearly ill-calculated how asking for a Qt Account with the online
>> installer would make our users feel*. A mistake. Sincere apologies.
>>
> [...]
>> *We do hope that this eases your concerns, and that we can continue with
>> your trust*.
>>
>>
>>
>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>
>
>  So apparently the trust of the QT community os nt a concern anymore...
>
> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
> a écrit :
>
>> I am afraid I do not have other words for this model than : absolutely
>> disgusting and a complete dick move. Especially login requirement for
>> binaries.
>> I don't even understand how distros are now supposed to keep qt code safe
>> since constantly pushing qt version up is recipe for problems and there
>> will be no critical bugfixes to branches that distros were stabilized at.
>>
>>
>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>
>>> Hi all,
>>>
>>> The Qt Company has done some adjustments to the Qt will be offered in
>>> the future. Please check out
>>> https://www.qt.io/blog/qt-offering-changes-2020 .
>>>
>>> The change consists of three parts.
>>>
>>> One is a change in policy regarding the LTS releases, where the LTS part
>>> of a release is in the future going to be restricted to commercial
>>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>>> into dev first. Backporting bug fixes is something that the Qt Company will
>>> take care of for these LTS branches. We’ve seen over the past that LTS
>>> support is something mainly required by large companies, and should
>>> hopefully help us get some more commercial support for developing Qt
>>> further.
>>>
>>> The second change is that a Qt Account will be in the future required
>>> for binary packages. Source code will continue to be available as
>>> currently. This will simplify distribution and integration with the
>>> Marketplace. In addition, we want open source users to contribute to Qt or
>>> the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira,
>>> code review and the forums all require a Qt Account).
>>>
>>> The third change is that The Qt Company will in the future also offer a
>>> lower priced product for small businesses. That small business product is
>>> btw not limited to mobile like the one Digia had some years ago, but covers
>>> all of Qt for Device Creation.
>>>
>>> None of these changes should affect how Qt is being developed. There
>>> won’t be any changes to Open Governance or the open development model.
>>>
>>> Best regards,
>>> Lars
>>>
>>> ___
>>> Development mailing list
>>>

Re: [Development] Changes to Qt offering

My understanding of the agreement between The Qt Company and the KDE Free
Qt Foundation is that if the Qt Company
releases a commercial Qt version without releasing the corresponding
open-source version within 12 months, the ownership of Qt will be
transferred
to the KDE Free Qt Foundation under a BSD license. (section 3.(ii)).

I am pretty sure a source only release would be enough. So I bet that the
LTS branches will be public, but we will not have a binary release through
the installer.

Le lun. 27 janv. 2020 à 17:17, Bogdan Vatra via Development <
development@qt-project.org> a écrit :

> Hi Lars,
>
> În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
> > Hi all,
> [...]
> >
> > One is a change in policy regarding the LTS releases, where the LTS part
> of
> > a release is in the future going to be restricted to commercial
> customers.
> > All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
> > first.
>
>   I was at the Qt Contributor Summit, and I can swear that I not heard
> anything about LTS being restricted to commercial customers...
>
> Just to be crystal clear, will you close also the branches?
> What will happen if I want to fix something in one of these LTS branches?
>
> > Backporting bug fixes is something that the Qt Company will take
> > care of for these LTS branches. We’ve seen over the past that LTS support
> > is something mainly required by large companies, and should hopefully
> help
> > us get some more commercial support for developing Qt further.
>
> I bet you the following scenario will happen soon:
> - someone will fork Qt LTS (most probably immediately after you closed
> these
> branches, if not even sooner)
> - the community will continue to support that fork as it's open, with
> improvements, bug fixes, security patches, etc.
> - you'll not get these patches as they are not contributed via your
> gerrit...
>
>
> > None of these changes should affect how Qt is being developed. There
> won’t
> > be any changes to Open Governance or the open development model.
>
>  If the qt5 branches will NOT be closed, then yes, you are right, if they
> will
> be closed then, I'm afraid, your statement can't stand...
>
> Cheers,
> BogDan.
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Hi,

Well, quite many things have changed since 2015. One important item is that
almost one million users have already voluntarily created (and verified)
themselves a Qt account.

See the FAQ (linked from the blog post):

“Q: Will requiring the Qt Account drive away all Qt users?
A: We have had the Qt Account as an option for over 4 years, and during that
time there has been already nearly a million people who have registered and
verified their Qt Account. It is obvious that that in the world that we live
today having an account for a service is not a blocker for people in general.
Everyone has the option of building Qt from sources if they do not like the
installer, but we believe that we provide value to our users through the
installer and the Qt Marketplace to justify the Qt Account.“

Yours,

Tuukka

Lähettäjä: Development käyttäjän Benjamin
TERRIER puolesta
Lähetetty: maanantaina, tammikuuta 27, 2020 6:03 ip.
Vastaanottaja: Qt development mailing list
Aihe: Re: [Development] Changes to Qt offering

Quoting The Qt Company itslef:

Thanks for your feedback to the new online installer asking for a Qt Account
signup. We have evaluated the feedback received via the blog,
various discussion forums, irc and other channels. Based on all these comments
and discussions with our partners we realize that this was not our finest
moment.
Preventing the growth and usage of Qt in the open source community is not what
we want to happen. We did already see a nice jump in the number of Qt Accounts,
but it was never our intention to make our valued community and contributors
upset with us or stop using and contributing to Qt.
We clearly ill-calculated how asking for a Qt Account with the online installer
would make our users feel. A mistake. Sincere apologies.
[...]
We do hope that this eases your concerns, and that we can continue with your
trust.

https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer

So apparently the trust of the QT community os nt a concern anymore...

Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko
mailto:enmarantis...@gmail.com>> a écrit :
I am afraid I do not have other words for this model than : absolutely
disgusting and a complete dick move. Especially login requirement for binaries.
I don't even understand how distros are now supposed to keep qt code safe since
constantly pushing qt version up is recipe for problems and there will be no
critical bugfixes to branches that distros were stabilized at.

On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll
mailto:lars.kn...@qt.io>> wrote:
Hi all,

The Qt Company has done some adjustments to the Qt will be offered in the
future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .

The change consists of three parts.

One is a change in policy regarding the LTS releases, where the LTS part of a
release is in the future going to be restricted to commercial customers. All
bug fixes will (as agreed on the Qt Contributor Summit) go into dev first.
Backporting bug fixes is something that the Qt Company will take care of for
these LTS branches. We’ve seen over the past that LTS support is something
mainly required by large companies, and should hopefully help us get some more
commercial support for developing Qt further.

The second change is that a Qt Account will be in the future required for
binary packages. Source code will continue to be available as currently. This
will simplify distribution and integration with the Marketplace. In addition,
we want open source users to contribute to Qt or the Qt ecosystem. Doing so is
only possible with a valid Qt Account (Jira, code review and the forums all
require a Qt Account).

The third change is that The Qt Company will in the future also offer a lower
priced product for small businesses. That small business product is btw not
limited to mobile like the one Digia had some years ago, but covers all of Qt
for Device Creation.

None of these changes should affect how Qt is being developed. There won’t be
any changes to Open Governance or the open development model.

Best regards,
Lars

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Simon Hausmann


Am 27.01.20 um 17:13 schrieb Bogdan Vatra via Development:
> Hi Lars,
>
> În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
>> Hi all,
> [...]
>> One is a change in policy regarding the LTS releases, where the LTS part of
>> a release is in the future going to be restricted to commercial customers.
>> All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
>> first.
>I was at the Qt Contributor Summit, and I can swear that I not heard
> anything about LTS being restricted to commercial customers...

Right, at the Qt Contributor Summit LTS being restricted to commercial 
customers was not discussed. That was also not the claim. The full 
sentence (as quoted above) is:


     "All bug fixes will (as agreed on the Qt Contributor Summit) go 
into dev first."


The development model where changes go to dev first was indeed a topic 
of discussion at the Qt Contributor Summit.

This also means that all security fixes will see the light of day on the 
dev branch first, in public, in Gerrit.


Simon

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

Re: [Development] Changes to Qt offering

>  None of these changes should affect how Qt is being developed. There
won’t be any changes to Open Governance or the open development model.
But there will likely be changes to the desire of people to develop.
Imagine an opensource contributor making a security fix who knows other
opensource users on older branches aren't going to receive it and there is
no way for him to push it there.

On Mon, Jan 27, 2020 at 7:11 PM NIkolai Marchenko 
wrote:

> Just this change in general reads: "We're going to annoy and inconvenience
> as much users as possible so that they buy our stuff"
>
> On Mon, Jan 27, 2020 at 7:09 PM NIkolai Marchenko 
> wrote:
>
>> > The second change is that a Qt Account will be in the future required
>> for binary packages.
>>
>> I would like to raise a serious security issue with this change.
>> Oftentimes, you need qt binaries within a VM. Also, oftentimes, VM is
>> stubborn and refuses to accept pastes.
>> This means people will use much simpler passwords for their Qt accounts,
>> possibly similar passwords with their other stuff so that they don't have
>> to remember too much.
>> All because QtC is a dick and restricts binary downloads for no valid
>> reason at all.
>>
>> On Mon, Jan 27, 2020 at 7:01 PM Benjamin TERRIER 
>> wrote:
>>
>>> Quoting The Qt Company itslef:
>>>
>>> Thanks for your feedback to the new online installer asking for a Qt
 Account signup. We have evaluated the feedback received via the blog,
 various discussion forums, irc and other channels. Based on all these
 comments and discussions with our partners we realize that this was not our
 finest moment.
 Preventing the growth and usage of Qt in the open source community is
 not what we want to happen. We did already see a nice jump in the number of
 Qt Accounts,
 but it was never our intention to make our valued community and
 contributors upset with us or stop using and contributing to Qt.
 *We clearly ill-calculated how asking for a Qt Account with the online
 installer would make our users feel*. A mistake. Sincere apologies.

>>> [...]
 *We do hope that this eases your concerns, and that we can continue
 with your trust*.



 https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer

>>>
>>>  So apparently the trust of the QT community os nt a concern anymore...
>>>
>>> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko <
>>> enmarantis...@gmail.com> a écrit :
>>>
 I am afraid I do not have other words for this model than : absolutely
 disgusting and a complete dick move. Especially login requirement for
 binaries.
 I don't even understand how distros are now supposed to keep qt code
 safe since constantly pushing qt version up is recipe for problems and
 there will be no critical bugfixes to branches that distros were stabilized
 at.


 On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:

> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in
> the future. Please check out
> https://www.qt.io/blog/qt-offering-changes-2020 .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS
> part of a release is in the future going to be restricted to commercial
> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
> into dev first. Backporting bug fixes is something that the Qt Company 
> will
> take care of for these LTS branches. We’ve seen over the past that LTS
> support is something mainly required by large companies, and should
> hopefully help us get some more commercial support for developing Qt
> further.
>
> The second change is that a Qt Account will be in the future required
> for binary packages. Source code will continue to be available as
> currently. This will simplify distribution and integration with the
> Marketplace. In addition, we want open source users to contribute to Qt or
> the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira,
> code review and the forums all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer
> a lower priced product for small businesses. That small business product 
> is
> btw not limited to mobile like the one Digia had some years ago, but 
> covers
> all of Qt for Device Creation.
>
> None of these changes should affect how Qt is being developed. There
> won’t be any changes to Open Governance or the open development model.
>
> Best regards,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
 ___
 Development mailing

Re: [Development] Changes to Qt offering

2020-01-27 Thread Bogdan Vatra via Development

Hi Lars,

În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris:
> Hi all,
[...]
> 
> One is a change in policy regarding the LTS releases, where the LTS part of
> a release is in the future going to be restricted to commercial customers.
> All bug fixes will (as agreed on the Qt Contributor Summit) go into dev
> first. 

  I was at the Qt Contributor Summit, and I can swear that I not heard 
anything about LTS being restricted to commercial customers...

Just to be crystal clear, will you close also the branches?
What will happen if I want to fix something in one of these LTS branches?

> Backporting bug fixes is something that the Qt Company will take
> care of for these LTS branches. We’ve seen over the past that LTS support
> is something mainly required by large companies, and should hopefully help
> us get some more commercial support for developing Qt further.

I bet you the following scenario will happen soon:
- someone will fork Qt LTS (most probably immediately after you closed these 
branches, if not even sooner)
- the community will continue to support that fork as it's open, with 
improvements, bug fixes, security patches, etc.
- you'll not get these patches as they are not contributed via your gerrit...
 
 
> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.
 
 If the qt5 branches will NOT be closed, then yes, you are right, if they will 
be closed then, I'm afraid, your statement can't stand...

Cheers,
BogDan.


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

Re: [Development] Changes to Qt offering

Just this change in general reads: "We're going to annoy and inconvenience
as much users as possible so that they buy our stuff"

On Mon, Jan 27, 2020 at 7:09 PM NIkolai Marchenko 
wrote:

> > The second change is that a Qt Account will be in the future required
> for binary packages.
>
> I would like to raise a serious security issue with this change.
> Oftentimes, you need qt binaries within a VM. Also, oftentimes, VM is
> stubborn and refuses to accept pastes.
> This means people will use much simpler passwords for their Qt accounts,
> possibly similar passwords with their other stuff so that they don't have
> to remember too much.
> All because QtC is a dick and restricts binary downloads for no valid
> reason at all.
>
> On Mon, Jan 27, 2020 at 7:01 PM Benjamin TERRIER 
> wrote:
>
>> Quoting The Qt Company itslef:
>>
>> Thanks for your feedback to the new online installer asking for a Qt
>>> Account signup. We have evaluated the feedback received via the blog,
>>> various discussion forums, irc and other channels. Based on all these
>>> comments and discussions with our partners we realize that this was not our
>>> finest moment.
>>> Preventing the growth and usage of Qt in the open source community is
>>> not what we want to happen. We did already see a nice jump in the number of
>>> Qt Accounts,
>>> but it was never our intention to make our valued community and
>>> contributors upset with us or stop using and contributing to Qt.
>>> *We clearly ill-calculated how asking for a Qt Account with the online
>>> installer would make our users feel*. A mistake. Sincere apologies.
>>>
>> [...]
>>> *We do hope that this eases your concerns, and that we can continue with
>>> your trust*.
>>>
>>>
>>>
>>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>>
>>
>>  So apparently the trust of the QT community os nt a concern anymore...
>>
>> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
>> a écrit :
>>
>>> I am afraid I do not have other words for this model than : absolutely
>>> disgusting and a complete dick move. Especially login requirement for
>>> binaries.
>>> I don't even understand how distros are now supposed to keep qt code
>>> safe since constantly pushing qt version up is recipe for problems and
>>> there will be no critical bugfixes to branches that distros were stabilized
>>> at.
>>>
>>>
>>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>>
 Hi all,

 The Qt Company has done some adjustments to the Qt will be offered in
 the future. Please check out
 https://www.qt.io/blog/qt-offering-changes-2020 .

 The change consists of three parts.

 One is a change in policy regarding the LTS releases, where the LTS
 part of a release is in the future going to be restricted to commercial
 customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
 into dev first. Backporting bug fixes is something that the Qt Company will
 take care of for these LTS branches. We’ve seen over the past that LTS
 support is something mainly required by large companies, and should
 hopefully help us get some more commercial support for developing Qt
 further.

 The second change is that a Qt Account will be in the future required
 for binary packages. Source code will continue to be available as
 currently. This will simplify distribution and integration with the
 Marketplace. In addition, we want open source users to contribute to Qt or
 the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira,
 code review and the forums all require a Qt Account).

 The third change is that The Qt Company will in the future also offer a
 lower priced product for small businesses. That small business product is
 btw not limited to mobile like the one Digia had some years ago, but covers
 all of Qt for Device Creation.

 None of these changes should affect how Qt is being developed. There
 won’t be any changes to Open Governance or the open development model.

 Best regards,
 Lars

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

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

Re: [Development] Changes to Qt offering

> The second change is that a Qt Account will be in the future required for
binary packages.

I would like to raise a serious security issue with this change.
Oftentimes, you need qt binaries within a VM. Also, oftentimes, VM is
stubborn and refuses to accept pastes.
This means people will use much simpler passwords for their Qt accounts,
possibly similar passwords with their other stuff so that they don't have
to remember too much.
All because QtC is a dick and restricts binary downloads for no valid
reason at all.

On Mon, Jan 27, 2020 at 7:01 PM Benjamin TERRIER 
wrote:

> Quoting The Qt Company itslef:
>
> Thanks for your feedback to the new online installer asking for a Qt
>> Account signup. We have evaluated the feedback received via the blog,
>> various discussion forums, irc and other channels. Based on all these
>> comments and discussions with our partners we realize that this was not our
>> finest moment.
>> Preventing the growth and usage of Qt in the open source community is not
>> what we want to happen. We did already see a nice jump in the number of Qt
>> Accounts,
>> but it was never our intention to make our valued community and
>> contributors upset with us or stop using and contributing to Qt.
>> *We clearly ill-calculated how asking for a Qt Account with the online
>> installer would make our users feel*. A mistake. Sincere apologies.
>>
> [...]
>> *We do hope that this eases your concerns, and that we can continue with
>> your trust*.
>>
>>
>>
>> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>>
>
>  So apparently the trust of the QT community os nt a concern anymore...
>
> Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
> a écrit :
>
>> I am afraid I do not have other words for this model than : absolutely
>> disgusting and a complete dick move. Especially login requirement for
>> binaries.
>> I don't even understand how distros are now supposed to keep qt code safe
>> since constantly pushing qt version up is recipe for problems and there
>> will be no critical bugfixes to branches that distros were stabilized at.
>>
>>
>> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>>
>>> Hi all,
>>>
>>> The Qt Company has done some adjustments to the Qt will be offered in
>>> the future. Please check out
>>> https://www.qt.io/blog/qt-offering-changes-2020 .
>>>
>>> The change consists of three parts.
>>>
>>> One is a change in policy regarding the LTS releases, where the LTS part
>>> of a release is in the future going to be restricted to commercial
>>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>>> into dev first. Backporting bug fixes is something that the Qt Company will
>>> take care of for these LTS branches. We’ve seen over the past that LTS
>>> support is something mainly required by large companies, and should
>>> hopefully help us get some more commercial support for developing Qt
>>> further.
>>>
>>> The second change is that a Qt Account will be in the future required
>>> for binary packages. Source code will continue to be available as
>>> currently. This will simplify distribution and integration with the
>>> Marketplace. In addition, we want open source users to contribute to Qt or
>>> the Qt ecosystem. Doing so is only possible with a valid Qt Account (Jira,
>>> code review and the forums all require a Qt Account).
>>>
>>> The third change is that The Qt Company will in the future also offer a
>>> lower priced product for small businesses. That small business product is
>>> btw not limited to mobile like the one Digia had some years ago, but covers
>>> all of Qt for Device Creation.
>>>
>>> None of these changes should affect how Qt is being developed. There
>>> won’t be any changes to Open Governance or the open development model.
>>>
>>> Best regards,
>>> Lars
>>>
>>> ___
>>> Development mailing list
>>> Development@qt-project.org
>>> https://lists.qt-project.org/listinfo/development
>>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Hi,

In essence the LTS patch release is a selection of bug fixes and security fixes 
(including update of 3rd party libraries). The bug fixes and security fixes 
will go first to dev and are cherry picked back to release branches.

After the change every release of Qt will look like a non-lts release for 
open-source users. Think of Qt 5.14 as an example. It was released in December. 
Today it received the first patch release. There will be more before next 
feature release is out. For open-source user Qt 5.15 will look just like Qt 
5.14 does.

For commercial license holders the patch releases of Qt 5.15 keep rolling just 
like Qt 5.9. This is expected to convince some of the companies using Qt 
open-source to select the paid version. Not every company, but hopefully many 
enough.

Yours,

Tuukka

Lähettäjä: Development  käyttäjän Ville 
Voutilainen  puolesta
Lähetetty: Monday, January 27, 2020 5:45:32 PM
Vastaanottaja: NIkolai Marchenko 
Kopio: Qt development mailing list 
Aihe: Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 17:36, NIkolai Marchenko  wrote:
>
> >  I expect security fixes
> but that's basically what an LTS is ... isn't it?

An LTS gets rather more than just security fixes; an example of that
is compiler compatibility fixes.
Some of us, including Qt employees, backport bug fixes that are not
actual new features to LTS branches
regularly.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

Quoting The Qt Company itslef:

Thanks for your feedback to the new online installer asking for a Qt
> Account signup. We have evaluated the feedback received via the blog,
> various discussion forums, irc and other channels. Based on all these
> comments and discussions with our partners we realize that this was not our
> finest moment.
> Preventing the growth and usage of Qt in the open source community is not
> what we want to happen. We did already see a nice jump in the number of Qt
> Accounts,
> but it was never our intention to make our valued community and
> contributors upset with us or stop using and contributing to Qt.
> *We clearly ill-calculated how asking for a Qt Account with the online
> installer would make our users feel*. A mistake. Sincere apologies.
>
[...]
> *We do hope that this eases your concerns, and that we can continue with
> your trust*.
>
>
>
> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer
>

 So apparently the trust of the QT community os nt a concern anymore...

Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko 
a écrit :

> I am afraid I do not have other words for this model than : absolutely
> disgusting and a complete dick move. Especially login requirement for
> binaries.
> I don't even understand how distros are now supposed to keep qt code safe
> since constantly pushing qt version up is recipe for problems and there
> will be no critical bugfixes to branches that distros were stabilized at.
>
>
> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>
>> Hi all,
>>
>> The Qt Company has done some adjustments to the Qt will be offered in the
>> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020
>> .
>>
>> The change consists of three parts.
>>
>> One is a change in policy regarding the LTS releases, where the LTS part
>> of a release is in the future going to be restricted to commercial
>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>> into dev first. Backporting bug fixes is something that the Qt Company will
>> take care of for these LTS branches. We’ve seen over the past that LTS
>> support is something mainly required by large companies, and should
>> hopefully help us get some more commercial support for developing Qt
>> further.
>>
>> The second change is that a Qt Account will be in the future required for
>> binary packages. Source code will continue to be available as currently.
>> This will simplify distribution and integration with the Marketplace. In
>> addition, we want open source users to contribute to Qt or the Qt
>> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
>> review and the forums all require a Qt Account).
>>
>> The third change is that The Qt Company will in the future also offer a
>> lower priced product for small businesses. That small business product is
>> btw not limited to mobile like the one Digia had some years ago, but covers
>> all of Qt for Device Creation.
>>
>> None of these changes should affect how Qt is being developed. There
>> won’t be any changes to Open Governance or the open development model.
>>
>> Best regards,
>> Lars
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread Kai Köhne

> Von: Development  Im Auftrag von NIkolai 
> Marchenko
> Gesendet: Montag, 27. Januar 2020 16:27
> An: Ville Voutilainen 
> Cc: Qt development mailing list 
> Betreff: Re: [Development] Changes to Qt offering
>
>>  they will be available 12 months after their commercial release 
>
> That's 12 months for cybercriminals to exploit already fixed vulnerabilities 
> in open source distros...

Well, I think the popular Linux Distributions are pretty good at backporting 
security fixes themselves. Not all Linux distributions have been settling on 
LTS versions in the first place, and all major ones have been packaging Qt 
before LTS versions were even introduced... So, while I'm not a Linux packager 
myself, I don't think this is as dramatic for them as you seem to assume.

Kai

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

Re: [Development] Requesting a module for Qt5 classes that won't be maintained in Qt6

2020-01-27 Thread Marc Mutz via Development


+1

On 2020-01-24 10:29, Sona Kurazyan wrote:

Hi,

 Previously there were discussions that we need to have a new module
in Qt 6 for the Qt 5 classes that will be no longer maintained in Qt
6.

 Here are some candidates to be moved there in Qt 6 (see
https://bugreports.qt.io/browse/QTBUG-80312):

* QLinkedList
* QRegExp
* QStateMachine
* QStringRef
* QList

* QJsonDocument::fromBinaryData()

The list is not complete or final, feel free to suggest more items
that you think will fit there.

 So, I would like to request a new module and repository for this.

Name of the repository: qt/qt5compat.git

Description: The module contains unsupported Qt 5 APIs

Responsible person: Sona Kurazyan

Gerrit user/email: sona.kuraz...@qt.io

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

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

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 17:36, NIkolai Marchenko  wrote:
>
> >  I expect security fixes
> but that's basically what an LTS is ... isn't it?

An LTS gets rather more than just security fixes; an example of that
is compiler compatibility fixes.
Some of us, including Qt employees, backport bug fixes that are not
actual new features to LTS branches
regularly.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

>  I expect security fixes
but that's basically what an LTS is ... isn't it?

On Mon, Jan 27, 2020 at 6:33 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

> On Mon, 27 Jan 2020 at 17:27, NIkolai Marchenko 
> wrote:
> >
> > >  they will be available 12 months after their commercial release
> >
> > That's 12 months for cybercriminals to exploit already fixed
> vulnerabilities in open source distros...
>
> I expect security fixes to be made available to everyone, licensed
> customer or not. Whether my expectation is correct
> remains to be seen.
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 17:27, NIkolai Marchenko  wrote:
>
> >  they will be available 12 months after their commercial release
>
> That's 12 months for cybercriminals to exploit already fixed vulnerabilities 
> in open source distros...

I expect security fixes to be made available to everyone, licensed
customer or not. Whether my expectation is correct
remains to be seen.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

>  they will be available 12 months after their commercial release

That's 12 months for cybercriminals to exploit already fixed
vulnerabilities in open source distros...

On Mon, Jan 27, 2020 at 6:23 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

> On Mon, 27 Jan 2020 at 16:52, coroberti .  wrote:
> >
> > Dear Lars,
> > What about sources of LTS versions? Could they be still available?
>
> As far as I understand things, the KDE Free Qt Foundation agreement
> ensures that they will be available
> 12 months after their commercial release. The blog entry doesn't seem
> to mention this point.
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

On Mon, 27 Jan 2020 at 16:52, coroberti .  wrote:
>
> Dear Lars,
> What about sources of LTS versions? Could they be still available?

As far as I understand things, the KDE Free Qt Foundation agreement
ensures that they will be available
12 months after their commercial release. The blog entry doesn't seem
to mention this point.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering


Hi,

The criteria to qualify for the small business / startup is:
-  Revenue or funding less than 100.000 USD annually
- Max 5 employees

Yours,

Tuukka

On 27.1.2020, 16.58, "drwho"  wrote:

On 2020-01-27 9:34 a.m., Lars Knoll wrote:
> The third change is that The Qt Company will in the future also offer a 
lower priced product for small businesses. That small business product is btw 
not limited to mobile like the one Digia had some years ago, but covers all of 
Qt for Device Creation.

Has it been specified what defines a small business, 100K yearly profit?

It would be nice to have a licensing option for binaries only, no 
support.  The company I work for is moving all our Qt5.6 console apps to 
GoLang because we can't afford the cost for 5 seats and the 40,000 units 
per year device royalty.  The 5 seat cost would be almost 10% of our 
software budget.  Go and Rust are free.  It is hard justify a Qt 
commercial license for console only apps.

Jon

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


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

Re: [Development] Changes to Qt offering


Hi Ekke,

Currently Qt MQTT is not part of Qt for Device Creator or Application 
Development product, see: https://www.qt.io/features 

Huge amount of other libraries are included, but unfortunately MQTT is only 
available as part of the Qt for Automation. 

Yours,

Tuukka

On 27.1.2020, 16.47, "Development on behalf of ekke" 
 wrote:

Am 27.01.20 um 15:34 schrieb Lars Knoll:
> ...
>
> The third change is that The Qt Company will in the future also offer a 
lower priced product for small businesses. That small business product is btw 
not limited to mobile like the one Digia had some years ago, but covers all of 
Qt for Device Creation.

sounds great

would this per ex enable mobile apps to integrate MQTT ?

ciao

ekke

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


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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Jason H

I hope these changes mean that you'll be able to support mobile properly. 
I'm still waiting on a response from you about the future of Qt on mobile.


> Sent: Monday, January 27, 2020 at 9:34 AM
> From: "Lars Knoll" 
> To: "Qt development mailing list" 
> Subject: [Development] Changes to Qt offering
>
> Hi all,
> 
> The Qt Company has done some adjustments to the Qt will be offered in the 
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 . 
> 
> The change consists of three parts. 
> 
> One is a change in policy regarding the LTS releases, where the LTS part of a 
> release is in the future going to be restricted to commercial customers. All 
> bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
> Backporting bug fixes is something that the Qt Company will take care of for 
> these LTS branches. We’ve seen over the past that LTS support is something 
> mainly required by large companies, and should hopefully help us get some 
> more commercial support for developing Qt further.
> 
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).
> 
> The third change is that The Qt Company will in the future also offer a lower 
> priced product for small businesses. That small business product is btw not 
> limited to mobile like the one Digia had some years ago, but covers all of Qt 
> for Device Creation.
> 
> None of these changes should affect how Qt is being developed. There won’t be 
> any changes to Open Governance or the open development model.
> 
> Best regards,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread drwho


On 2020-01-27 9:34 a.m., Lars Knoll wrote:

The third change is that The Qt Company will in the future also offer a lower 
priced product for small businesses. That small business product is btw not 
limited to mobile like the one Digia had some years ago, but covers all of Qt 
for Device Creation.


Has it been specified what defines a small business, 100K yearly profit?

It would be nice to have a licensing option for binaries only, no 
support.  The company I work for is moving all our Qt5.6 console apps to 
GoLang because we can't afford the cost for 5 seats and the 40,000 units 
per year device royalty.  The 5 seat cost would be almost 10% of our 
software budget.  Go and Rust are free.  It is hard justify a Qt 
commercial license for console only apps.


Jon

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread Albert Astals Cid via Development

El dilluns, 27 de gener de 2020, a les 15:34:44 CET, Lars Knoll va escriure:
> Hi all,
> 
> The Qt Company has done some adjustments to the Qt will be offered in the
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
> 
> The change consists of three parts
> None of these changes should affect how Qt is being developed. There won’t
> be any changes to Open Governance or the open development model.

Can someone on the release team confirm there was a public discussion about the 
Qt Project not doing LTS releases anymore?

Otherwise it seems the Open Governance was a bit side tracked and The Qt 
Company unilaterally decided to stop doing some releases.

Cheers,
  Albert 

> Best regards,
> Lars
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development


-- 
Albert Astals Cid | albert.astals@kdab.com | Senior Software Engineer
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
KDAB - The Qt, C++ and OpenGL Experts

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

Re: [Development] Changes to Qt offering

2020-01-27 Thread coroberti .

Dear Lars,
What about sources of LTS versions? Could they be still available?
Thanks.
Kind regards,
Robert Iakobashvili


On Mon, Jan 27, 2020 at 4:35 PM Lars Knoll  wrote:
>
> Hi all,
>
> The Qt Company has done some adjustments to the Qt will be offered in the 
> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 .
>
> The change consists of three parts.
>
> One is a change in policy regarding the LTS releases, where the LTS part of a 
> release is in the future going to be restricted to commercial customers. All 
> bug fixes will (as agreed on the Qt Contributor Summit) go into dev first. 
> Backporting bug fixes is something that the Qt Company will take care of for 
> these LTS branches. We’ve seen over the past that LTS support is something 
> mainly required by large companies, and should hopefully help us get some 
> more commercial support for developing Qt further.
>
> The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account).
>
> The third change is that The Qt Company will in the future also offer a lower 
> priced product for small businesses. That small business product is btw not 
> limited to mobile like the one Digia had some years ago, but covers all of Qt 
> for Device Creation.
>
> None of these changes should affect how Qt is being developed. There won’t be 
> any changes to Open Governance or the open development model.
>
> Best regards,
> Lars
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

I understand the reasoning for this change but it effectively ruins the
spirit of open-source~ness of qt while technically leaving it intact.
Technically

On Mon, Jan 27, 2020 at 5:41 PM NIkolai Marchenko 
wrote:

> I am afraid I do not have other words for this model than : absolutely
> disgusting and a complete dick move. Especially login requirement for
> binaries.
> I don't even understand how distros are now supposed to keep qt code safe
> since constantly pushing qt version up is recipe for problems and there
> will be no critical bugfixes to branches that distros were stabilized at.
>
>
> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll  wrote:
>
>> Hi all,
>>
>> The Qt Company has done some adjustments to the Qt will be offered in the
>> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020
>> .
>>
>> The change consists of three parts.
>>
>> One is a change in policy regarding the LTS releases, where the LTS part
>> of a release is in the future going to be restricted to commercial
>> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go
>> into dev first. Backporting bug fixes is something that the Qt Company will
>> take care of for these LTS branches. We’ve seen over the past that LTS
>> support is something mainly required by large companies, and should
>> hopefully help us get some more commercial support for developing Qt
>> further.
>>
>> The second change is that a Qt Account will be in the future required for
>> binary packages. Source code will continue to be available as currently.
>> This will simplify distribution and integration with the Marketplace. In
>> addition, we want open source users to contribute to Qt or the Qt
>> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code
>> review and the forums all require a Qt Account).
>>
>> The third change is that The Qt Company will in the future also offer a
>> lower priced product for small businesses. That small business product is
>> btw not limited to mobile like the one Digia had some years ago, but covers
>> all of Qt for Device Creation.
>>
>> None of these changes should affect how Qt is being developed. There
>> won’t be any changes to Open Governance or the open development model.
>>
>> Best regards,
>> Lars
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> https://lists.qt-project.org/listinfo/development
>>
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

2020-01-27 Thread ekke


Am 27.01.20 um 15:34 schrieb Lars Knoll:

...

The third change is that The Qt Company will in the future also offer a lower 
priced product for small businesses. That small business product is btw not 
limited to mobile like the one Digia had some years ago, but covers all of Qt 
for Device Creation.


sounds great

would this per ex enable mobile apps to integrate MQTT ?

ciao

ekke

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

Re: [Development] Changes to Qt offering