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

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

Reply via email to