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