[Development] Changes to Qt offering

[Konrad Rosenbaum]

Hi,

On 2020-01-29 09:52, Cristián Maureira-Fredes wrote:
> I understand the video is an exaggeration,

Is it? I found it was pretty much bang on. Even for Qt: I just counted - 
it took me 5 clicks, most of them not very intuitive, to download the Qt 
installer I currently need (Linux 32bit on a 64bit host). With the 
proposed changes Qt ventures eerily close to the video...

Thankfully it did not ask for my name, date of birth, email address, 
mothers maiden name etc. - none of which is any of TQCs damn business.

For comparison: the typical Open Source download is 2 very intuitive 
clicks - click the "Download" link, get a nice long list of available 
and supported packages, click the one I need, use the system installer 
or tar to install the package.

> but in any case, there is something I really need to understand:
>
> 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.

Yes, and currently (thankfully) I normally do not need it. I certainly 
do not remember the password I used, nor do I remember where I stored it 
(it's ... somewhere...).

Should I find another bug, I'll dig it out and then log in... or request 
a password reset...

...though I'd prefer to not need it then - e.g. I can report Debian bugs 
without a password by simply sending a mail or using a script that asks 
for the relevant info.

I certainly will not bother with this for a simple download.

> 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.

Which basically means I will stop messing with the web page and use the 
GIT source tree to compile Qt, while my colleagues, who I wanted to 
convert, will continue merrily with C# (the horror!).

I'm already planning for a simple Jenkins job on my home server that 
will check for new Qt releases and automatically build them for me in a 
Docker container while I sleep...

> How different is this process
> from registering to this mailing list for example?
> 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.
Very. The mail list was fire and forget. I didn't even enter a password, 
the mail list software assigned one (AFAIR). I will never need the 
password ever again until I unsubscribe.
> 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?

Strange, if you come from the Open Source world: yes! Rude? Depends on 
how radical you are behind this GDPR thingy...

I see it like this: the CI exists for two reasons - to help the 
developers do better code and to assure paying customers that Qt has 
quality standards. Building the binaries on the CI is just more 
convenient than doing it by hand. So I don't see a direct connection 
between the two.

Besides, as an Open Source user I do not care about either one. (As a 
developer I do care about the first one.)

 From my point of view providing binaries is something you do to 
convince passers-by to become users. Making it more difficult is 
something to make sure you are not disturbed by pesky users. Remember, 
it is already quite difficult now...

May I humbly suggest you try to convert users into customers after they 
have been converted from passers-by to user?

BTW: in the past I would have convinced one of my customers to buy 
support for the Open Source version if it had been available. If there 
was a simple possibility to buy a single support incident (say, for 
100Euros) I would even do this occassionally as a private Open Source 
user when I come across a problem I can't or don't want to solve myself!

> 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,
Cool! What kinds of costumes do you do? Can I dress up as the Grinch? 
[SCNR] :)
>   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.

Nice. If as an Open Source user I would stay with LTS, then I don't have 
time to even research what bug fixes I need. If I had the time I would 
have ported to a newer version of Qt. So this argument is a non-starter.

Someone will hopefully create an Open Source branch for the LTS release 
and people like me will start to use it. Period. No surprise there. Yes, 
I did say "hopefully" and I am aware of the consequences - for me they 
are preferable to having to do this myself.

I hope you are aware that you have to eventually open up those LTS 
releases as per the KDE Free Qt agreement!?

> I think nobody at Qt will be so irresponsible of not notifying
> security patches, and I'm certain we will work around this issue,
> to maybe distributed in a better way for Open Source users.
How about keeping those branches public and just not providing binary 
packages?



     Konrad