[Development] Changes planned for the online installer

[Sze Howe Koh]

Thanks for the initiative, Tuuka and team. Much appreciated.

As part of the meeting, please review the points raised in previous
discussions [1][2]. Three major pain points were:

    (A) Downloading metadata is very time-consuming.
    (B) The automatic mirror selection algorithm doesn't always pick
the best mirror.
    (C) (New users) It's not clear how to choose what to install.

The changes you described, as well as Fabrice's suggestions, seem to
address (A) quite nicely.

I made a tool to help with (B), but it was meant to be a quick and
dirty hack [3]. I didn't expect it to still be in use 5 years later.
Please provide the ability to override the default mirror within the
installer itself.

I believe the documentation team discussed on-boarding techniques as
part of their workshop last week [4]. Please work with them to address
(C) in a holistic manner.


Regards,
Sze-Howe

[1] https://lists.qt-project.org/pipermail/development/2018-April/032461.html
("To improve UX of the online installer") and subsequent replies
[2] https://bugreports.qt.io/browse/QTIFW-1132
[3] https://forum.qt.io/topic/43349/slow-downloads-with-the-online-installer-try-this-tool
[4] https://blog.qt.io/blog/2019/03/01/the-future-of-documentation/

On Tue, 19 Mar 2019 at 21:12, Fabrice Mousset | GEOCEPT GmbH
<fabrice.mousset at geocept.com> wrote:
>
> Hi,
>
> It is great to hear there will be done some update on Maintenance Tool
>
> I don’t know about internal architecture of the software, but it would be great if Maintenance Tool could handle locally a little “cache” to avoid always (re)downloading from server all information about Qt releases.
>
> Each time Maintenance Tool is launched, it downloads almost the same stuff (I think) for Qt Servers. It would be much faster to store this information locally in little “database” (XML or SQLite for example) with a MD5SUM as Checksum. This would speed up the boot process when nothing new on server between 2 starts and, I think, this will also consume less server resources.
>
> My two cents.
>
> Fabrice
>
> ------------------------------------
> Von: Development <development-bounces at qt-project.org> Im Auftrag von Tuukka Turunen
> Gesendet: Dienstag, 19. März 2019 13:33
> An: development at qt-project.org; releasing at qt-project.org
> Betreff: [Development] Changes planned for the online installer
>
>
> Hi,
>
> Online installer has over time become quite crowded with different releases and many have noticed that it is getting quite slow at times. Having all this default content is also problematic for those who mirror Qt as it would take a significant amount of disk space to have a complete mirror.
>
> From user viewpoint it could be seen handy that all these different releases are available via the online installer, but there are caveats. One major item is security. We always recommend to take the latest supported patch release, but have offered also all the old ones. It should be more clear than today to users what release to take. Unsupported releases contain multiple known vulnerabilities and should not be used.
>
> With an upcoming version of the online installer, we are planning to make the following changes:
>
> * Separate the pre-releases to its own ‘preview’ category, only visible when enabled
> * Remove all unsupported Qt releases from the online installer
> * Move all but the latest patch releases of supported Qt releases into ‘archive’ category
>
> This allows for greatly improved user experience of the online installer, focuses users to take the latest release with all security updates and reduces the space needed from the mirrors.
>
> Commercial online installer uses Amazon CDN and for the commercial users we are planning to offer some the older, unsupported releases. There is also extended support available for those commercial license holders who are using an otherwise unsupported release of Qt.
>
> Old Qt releases continue to be available for everyone in the download.qt.io historical archive, but in general they should be considered as a historical reference, not used in active projects.
>
> Feedback and thoughts welcome. The topic could also be taken to the agenda of next week’s release team meeting?
>
> Yours,
>
>                 Tuukka