[Development] Changes to Qt offering

[Giuseppe D'Angelo]

Il 29/01/20 09:52, Cristián Maureira-Fredes ha scritto:
> 
> Currently, you can create a Qt Account with your email
> and a password, when you received the email, you confirm by clicking on
> the link, and then you can optionally enter your information.
> First Name and Last Name are required, but then you can enter
> any information on these fields. (I didn't check the checkbox
> to receive information).

Using a fake identity is a violation of the terms of service, and I 
wouldn't be surprised that it could be seen as a crime in the EU or in 
the US. Are you seriously suggesting that?


> Doing that, now I have access
> to the future installer, I can manage my Qt downloads, install the
> binaries, remove components if I will not use and everything else.
> 
> How different is this process
> from registering to this mailing list for example?

This is a logical fallacy. "Name and email is also what you use to 
register to file your tax returns, why are you so concerned?"

I'd wager that the ratio of Qt users reading (if not writing) on these 
mailing lists vs the total of Qt users is somewhere in the 10^-4 order 
of magnitude. And, the irony is, we're not even using the Qt Account for 
managing the subscriptions to this very mailing list!


> IIRC I entered my email, my name, and a password, then I got an email,
> clicked on the link, verified my name again, and then I was welcomed
> to the mailing list.
> 
> But sure, the mailing list is not software, but a service
> to communicate with others.
> Since the installer is a service that TQtC provides,
> for me is really not difficult to understand that I will require
> an account, after all TQtC is responsible of having a working CI
> that can generate those binaries for your convenience.
> Sure, this was not there before, but is it really so strange? and rude?

It is in a world of software-as-a-commodity (and especially UI toolkits 
as a commodity), as well as in a world which is (finally) more privacy 
sensitive. People don't want companies to collect their personal data 
any more "just for the sake of it", but especially, any wall you raise 
that prevents the installation of your software to be a series of clicks 
on "next next next finish" simply makes your software much less attractive.

(Not to mention that, as already pointed out, this could be also solved 
by allowing some OpenID providers to authenticate an user)


> Regarding the LTS decision, you can take it from another point
> of view:
> 5.15 will only have 2 or 3 bug fixing releases, and so will all
> the LTS versions in the future.
> Since TQtC has commercial costumers, we will internally fork
> the latest bug fix release, and will start adding patches on
> top of that on request of the costumers, but hey! all those
> patches will be on Gerrit, so if they are important for your work,
> you can just cherry pick them to your local Qt and re-build.

Ok, finally some answers here.

I don't understand this model at all: if in the long run 5.15 is going 
to be maintained as a private fork, but all the patches to it are going 
to be public on gerrit, it's going to take approximately 20 minutes for 
someone to
* set up a gerrit stream
* get all the merged patches targeting this "5.15-private" branch
* cherry pick them on 5.15.x
* publish the result (5.15.oss-latest) on github or KDE or so

The net result will be that 5.15 will be forked twice (TQC will have an 
internal commercial fork, the OSS community a public fork), and that Qt 
will have lost all 3rd party contributions to 5.15 (cf. Thiago's email).

Isn't this a lose/lose?

My 2 c,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200129/3260270a/attachment-0001.bin>