Hi,
On 12/22/16 09:18, Oliver Wolff wrote: > Can someone elaborate on how "one package per OS" reduces the testing > burden significantly? We still have to check every > platform/configuration that is inside the package. All that changes is > that the testers install from one big package instead of smaller > packages. I doubt that one person will check the whole windows package > (for example). At least I will not volunteer to do that :X I agree. If your goal is to have fewer people testing, combine the installers. Then, people who don't have the time/bandwidth/disk space for several 3.3GB snapshots will simply not test the packages. As as a *former* Windows user, I may be out of sync with developer expectations. Even so, I imagine you would be hard-pressed to find many developers who use all of the ABIs listed in that hypothetical Windows installer. I guess this will push those users to use the online installer, which is probably what is desired... I still have to deal with CI systems which download and install Qt automatically, and they are especially sensitive to the download/installation size issue. Until either installer provides a supported way to script the installation (I've been using [0]), then bloating the offline installer gets a -1 from me. > > > On 21/12/2016 19:37, Jake Petroules wrote: >> LET'S DO IT! And thank you for following through on this idea. >> >> This will reduce our package testing burden significantly which is >> very important because it lowers the barrier to entry for us to >> actually add new platforms/installers. For example, adding tvOS to >> the combined macOS/iOS/Android package would be valuable. This one sounds reasonable. >> >> I would omit the host architectures (it provides no useful value >> since there are multiple host architectures in some cases) and target >> platforms from the filenames, though (like -android, -qnx, >> -android-ios), because they aren't there for the Windows package so >> it would be more consistent. The download descriptions should detail >> what each package contains. Agreed. >> >> Also, can we simply subsume the QNX packages into the base enterprise >> packages? i.e. combine qt-enterprise-linux-x64-android and >> qt-enterprise-linux-x64-qnx? Or is there a licensing-related issue >> around that? And why do we need different packages based on the >> license, anyways? I assume the enterprise components haven't been properly "sanitized" so that they can be disabled for the open-source distribution. Combining the installers certainly makes the most sense, and was something promised already at last year's QtWS IIRC. [0] https://github.com/benlau/qtci/blob/master/bin/extract-qt-installer -- Andrew _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development