Re: [Development] A monologue about platforms in the Qt world
Hi Tony, On 02/05/2019 13:48, Tony Sarajärvi wrote: What's a supported platform? --- It means that The Qt Company gives you support if you stumble upon a problem with that distro I don't agree on "The Qt Company gives you support" part. That's part of whatever commercial support agreement one gets from TQC; the "supported platform" definition (if any) should apply to the Qt Project, not to TQC. and the Qt release promised to work on that. This is more like it. This promise should come from the "supported platforms" documentation pages, e.g. https://doc.qt.io/qt-5/supported-platforms.html https://doc.qt.io/qt-5/linux.html It's however totally unclear at this point what "supported platform" means for the Qt Project. I've got a personal interpretation of this, but I don't know if it's codified somewhere. (E.g.: I consider a FTBFS on a supported platform a P1 and a release blocker). Maybe it needs to be made clear, in Qt's policies as well as the official docs? But what’s unclear is what it actually means that Qt should work on that platform. Does it mean that the binaries we distribute should work on that? Or does it mean that Qt builds on it if you take the sources and compile them yourself? True, it's somewaht confusing for the end user. But IMHO I would not mix the two. To me, supported means that you can build from sources and run Qt there. In other words, to me, it does not mean that a platform is supported iff there is a binary build of Qt available for that platform. Or, it does not mean that a platform is supported iff such binary builds "work". This is one of the most asked questions we’ve had here. A good example is openSUSE 42.3 where examples don’t compile if you take our binary release and try to work with that. But if you would compile Qt on that distro, then it would work. (see https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the details). What do you think it means? Is one or the other answers wrong here? As a consequence of my position above: to me it means that openSUSE *is* supported (it's Linux/X11), but not by the binary builds. Lifespan of distros --- This is something we should have thought more about, but didn't. Perhaps still don't. Let's take Qt 5.12 as a good example here. Qt 5.12.0 was released on the 6th Dec 2018. It has a promised lifespan to at least the end of 2021. With us actually going development and testing before the actual release, we need to have the environment which we work on working at least 6 months before we release. Now that RHEL 7.4 was such an environment which was available then. Already released July 2017 and having an EOL (end of life) August 2019. Perfect! But the problem is our Qt 5.12.2, .3, .4, .5 releases. Should we be doing releases with a distro that isn't even supported by RedHat themselves? And there's the big question #1! Because of ignorance we didn't think about this when we documented things. We just blindly say that Qt 5.12 supports RHEL 7.4, because that's what we have in the CI! Yeah, but are we really supporting it in 2021, when RedHat themselves have pulled the plug on it over 2 years before that? Could we just update to the latest RHEL after all? Especially since we didn't use RHEL 7.4 to begin with, but our own distro as we modified the original RHEL? That's another area where this is mixing two levels of "support". Qt 5.12 will be supported (by the _Qt Project_) until 2021. At least to me, the support for the binary builds can change at any time during this time frame, as the two supports are not tied to each other. 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: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A monologue about platforms in the Qt world
See inline. From: Development mailto:development-boun...@qt-project.org>> on behalf of Danila Malyutin mailto:danilamalju...@gmail.com>> Sent: Friday, May 3, 2019 4:07 PM To: development@qt-project.org<mailto:development@qt-project.org> Subject: Re: [Development] A monologue about platforms in the Qt world > When selecting this operating system which we created packages with, we tend > to select a reasonable new one, most preferably a stable one, with a good set > of old libraries so that the backwards compatibility is good. Take RHEL 7 for > example. RHEL 7.0 was release in June 2014. In July 2017 we got the 7.4 > update which we began using. RHEL 7.4 is still compatible with 7.0, which > means that our binaries are created with a new distro that creates binaries > compatible with distros created in 2014. At least sort of. I found that to not be the case. For example, I couldn't get Qt Creator 4.8.0 (which was the first one using Qt 5.12) to run on RHEL/CentOS 7.3 due to LIBDBUS_1_3 errors. Could be the same issue as with OpenSUSE though. чт, 2 мая 2019 г. в 14:50, Tony Sarajärvi mailto:tony.saraja...@qt.io>>: Hi all! I'd like to open up a discussion about the platforms we "support". This is like listening to a broken record, but once again it’s about adding or removing platforms in the CI, what’s supported and what we do packages with. But, this time I'm going to approach you a bit differently. Instead of simple questions, I'm going to bombard you with boring details. You need to know what exactly it is we are asking you about after all ;) What's a supported platform? --- It means that The Qt Company gives you support if you stumble upon a problem with that distro and the Qt release promised to work on that. But what’s unclear is what it actually means that Qt should work on that platform. Does it mean that the binaries we distribute should work on that? Or does it mean that Qt builds on it if you take the sources and compile them yourself? This is one of the most asked questions we’ve had here. A good example is openSUSE 42.3 where examples don’t compile if you take our binary release and try to work with that. But if you would compile Qt on that distro, then it would work. (see https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the details). What do you think it means? Is one or the other answers wrong here? What a platform in the CI? --- Ok this one is pretty clear. A platform in the CI is a platform we see fit to be tested for a specific branch. The important thing here is to realize that this is not the same thing as us supporting something. For obvious reasons it would be great if everything we supported was tested here, but because of the vast amount of combinations, we can't do that. We simply try to cover the most common cases here. And that's always up for debate! If you see that something is worth testing in the CI, create a ticket about it and justify why your configuration should be in there. This doesn't just mean adding platforms or compilers. It also means configurations like -no-gui or building examples for Android or something. There are two perspectives to this: the Qt Project perspective, the The Qt Company perspective. As the company, "support" is a service we sell. People can ask for help, and we need to document on which platforms we help them with problems. That includes development hosts, and deployment targets. For the Qt Project, what matters is which platforms we want our code to compile on, and for which platforms we want to provide pre-built binaries. Ideally these two lists are mostly the same, but it's conceptually quite ok for TQtC to provide some platform support as a support or consulting service that includes developing patches. Might not be the most scalable business model under the sun, but whatever. I perhaps recall this wrongly, but I think that's what we used to call "Tier 1" vs "Tier 2" supported platforms. Tier 1 platforms: we provide tested binaries, verified through CI and pre-release package testing. You can expect a top out-of-the-installer experience. Tier 2: things are supposed to work, but they might not, and if they don't we'll help you with fixing it. This split still makes sense to me. The Qt Project at large should primarily care about Tier 1, ie contributors write code with those in mind (while being aware that there are also Tier 2 platforms); if changes break a tier 2, then it becomes TQtC’s problem to fix. What's a packaging configuration and why don't Linux binaries work as promised? --- Some configurations in the CI are used to actually create the binaries which we deliver as Qt binaries via the installer. They can be recognized by the "Packaging" keyword in the following files: https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/default.txt https://co
Re: [Development] A monologue about platforms in the Qt world
> When selecting this operating system which we created packages with, we tend to select a reasonable new one, most preferably a stable one, with a good set of old libraries so that the backwards compatibility is good. Take RHEL 7 for example. RHEL 7.0 was release in June 2014. In July 2017 we got the 7.4 update which we began using. RHEL 7.4 is still compatible with 7.0, which means that our binaries are created with a new distro that creates binaries compatible with distros created in 2014. At least sort of. I found that to not be the case. For example, I couldn't get Qt Creator 4.8.0 (which was the first one using Qt 5.12) to run on RHEL/CentOS 7.3 due to LIBDBUS_1_3 errors. Could be the same issue as with OpenSUSE though. чт, 2 мая 2019 г. в 14:50, Tony Sarajärvi : > Hi all! > > I'd like to open up a discussion about the platforms we "support". This > is like listening to a broken record, but once again it’s about adding or > removing platforms in the CI, what’s supported and what we do packages > with. But, this time I'm going to approach you a bit differently. Instead > of simple questions, I'm going to bombard you with boring details. You need > to know what exactly it is we are asking you about after all ;) > > > What's a supported platform? > --- > It means that The Qt Company gives you support if you stumble upon a > problem with that distro and the Qt release promised to work on that. But > what’s unclear is what it actually means that Qt should work on that > platform. Does it mean that the binaries we distribute should work on that? > Or does it mean that Qt builds on it if you take the sources and compile > them yourself? This is one of the most asked questions we’ve had here. A > good example is openSUSE 42.3 where examples don’t compile if you take our > binary release and try to work with that. But if you would compile Qt on > that distro, then it would work. (see > https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the > details). What do you think it means? Is one or the other answers wrong > here? > > > What a platform in the CI? > --- > Ok this one is pretty clear. A platform in the CI is a platform we see fit > to be tested for a specific branch. The important thing here is to realize > that this is not the same thing as us supporting something. For obvious > reasons it would be great if everything we supported was tested here, but > because of the vast amount of combinations, we can't do that. We simply try > to cover the most common cases here. And that's always up for debate! If > you see that something is worth testing in the CI, create a ticket about it > and justify why your configuration should be in there. This doesn't just > mean adding platforms or compilers. It also means configurations like > -no-gui or building examples for Android or something. > > > What's a packaging configuration and why don't Linux binaries work as > promised? > --- > Some configurations in the CI are used to actually create the binaries > which we deliver as Qt binaries via the installer. They can be recognized > by the "Packaging" keyword in the following files: > https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/default.txt > https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qt5.txt > For most platforms this makes a lot of sense and they don't cause problems > anywhere, but our Linux binaries are a different thing entirely. Where > Windows and macOS binaries work here and there, Linux distros tend to be > more strict to what works and where. The library dependencies make things > not work backwards as well as on Windows and macOS. Which brings us to the > problem mentioned earlier at supported platforms. Binaries created with > RHEL 7.4 don't tend to work on openSUSE 42.3, but they do compile. > > When selecting this operating system which we created packages with, we > tend to select a reasonable new one, most preferably a stable one, with a > good set of old libraries so that the backwards compatibility is good. Take > RHEL 7 for example. RHEL 7.0 was release in June 2014. In July 2017 we got > the 7.4 update which we began using. RHEL 7.4 is still compatible with 7.0, > which means that our binaries are created with a new distro that creates > binaries compatible with distros created in 2014. At least sort of. > > But the distro we use, isn't always the out-of-the-box distro. When we > used RHEL 6.6 for example, we replaced the bluez (for Bluetooth) libraries > with own ones so that Qt binaries would have the features enabled that were > wished. That actually means that we didn't use RHEL 6.6 to create the > releases, but in fact a custom distro based on RHEL 6.6. (off on a tangent > here: Qt 5.6 sources actually don't even compile on an out-of-the-box RHEL > 6.6 because we now missed that during verification (bug created!). And > actually by us installing devtoolsets provided by RHEL, us installing > custom Pythons, extracting own libclangs,
Re: [Development] A monologue about platforms in the Qt world
> Does it mean that the binaries we distribute should work on that? I have been maintaining XCB plugin and the bundled xkbcommon and xcb 3rd party sources based on the assumption that an answer to this question is - yes. From: Development on behalf of Tony Sarajärvi Sent: Thursday, May 2, 2019 1:48 PM To: development@qt-project.org Subject: [Development] A monologue about platforms in the Qt world Hi all! I'd like to open up a discussion about the platforms we "support". This is like listening to a broken record, but once again it’s about adding or removing platforms in the CI, what’s supported and what we do packages with. But, this time I'm going to approach you a bit differently. Instead of simple questions, I'm going to bombard you with boring details. You need to know what exactly it is we are asking you about after all ;) What's a supported platform? --- It means that The Qt Company gives you support if you stumble upon a problem with that distro and the Qt release promised to work on that. But what’s unclear is what it actually means that Qt should work on that platform. Does it mean that the binaries we distribute should work on that? Or does it mean that Qt builds on it if you take the sources and compile them yourself? This is one of the most asked questions we’ve had here. A good example is openSUSE 42.3 where examples don’t compile if you take our binary release and try to work with that. But if you would compile Qt on that distro, then it would work. (see https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the details). What do you think it means? Is one or the other answers wrong here? What a platform in the CI? --- Ok this one is pretty clear. A platform in the CI is a platform we see fit to be tested for a specific branch. The important thing here is to realize that this is not the same thing as us supporting something. For obvious reasons it would be great if everything we supported was tested here, but because of the vast amount of combinations, we can't do that. We simply try to cover the most common cases here. And that's always up for debate! If you see that something is worth testing in the CI, create a ticket about it and justify why your configuration should be in there. This doesn't just mean adding platforms or compilers. It also means configurations like -no-gui or building examples for Android or something. What's a packaging configuration and why don't Linux binaries work as promised? --- Some configurations in the CI are used to actually create the binaries which we deliver as Qt binaries via the installer. They can be recognized by the "Packaging" keyword in the following files: https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/default.txt https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qt5.txt For most platforms this makes a lot of sense and they don't cause problems anywhere, but our Linux binaries are a different thing entirely. Where Windows and macOS binaries work here and there, Linux distros tend to be more strict to what works and where. The library dependencies make things not work backwards as well as on Windows and macOS. Which brings us to the problem mentioned earlier at supported platforms. Binaries created with RHEL 7.4 don't tend to work on openSUSE 42.3, but they do compile. When selecting this operating system which we created packages with, we tend to select a reasonable new one, most preferably a stable one, with a good set of old libraries so that the backwards compatibility is good. Take RHEL 7 for example. RHEL 7.0 was release in June 2014. In July 2017 we got the 7.4 update which we began using. RHEL 7.4 is still compatible with 7.0, which means that our binaries are created with a new distro that creates binaries compatible with distros created in 2014. At least sort of. But the distro we use, isn't always the out-of-the-box distro. When we used RHEL 6.6 for example, we replaced the bluez (for Bluetooth) libraries with own ones so that Qt binaries would have the features enabled that were wished. That actually means that we didn't use RHEL 6.6 to create the releases, but in fact a custom distro based on RHEL 6.6. (off on a tangent here: Qt 5.6 sources actually don't even compile on an out-of-the-box RHEL 6.6 because we now missed that during verification (bug created!). And actually by us installing devtoolsets provided by RHEL, us installing custom Pythons, extracting own libclangs, perhaps build our own openssl from sources, one could actually argue, that we don't use RHEL 7.4 either, but our own custom Linux based on RHEL 7.4. Lifespan of distros --- This is something we should have thought more about, but didn't. Perhaps still don't. Let's take Qt 5.12 as a good example here. Qt 5.12.0 was released on the 6th Dec 2018. It has a promised lifespan to at least the end of 2021.
[Development] A monologue about platforms in the Qt world
Hi all! I'd like to open up a discussion about the platforms we "support". This is like listening to a broken record, but once again it’s about adding or removing platforms in the CI, what’s supported and what we do packages with. But, this time I'm going to approach you a bit differently. Instead of simple questions, I'm going to bombard you with boring details. You need to know what exactly it is we are asking you about after all ;) What's a supported platform? --- It means that The Qt Company gives you support if you stumble upon a problem with that distro and the Qt release promised to work on that. But what’s unclear is what it actually means that Qt should work on that platform. Does it mean that the binaries we distribute should work on that? Or does it mean that Qt builds on it if you take the sources and compile them yourself? This is one of the most asked questions we’ve had here. A good example is openSUSE 42.3 where examples don’t compile if you take our binary release and try to work with that. But if you would compile Qt on that distro, then it would work. (see https://bugreports.qt.io/browse/QTQAINFRA-2780 if you want to know the details). What do you think it means? Is one or the other answers wrong here? What a platform in the CI? --- Ok this one is pretty clear. A platform in the CI is a platform we see fit to be tested for a specific branch. The important thing here is to realize that this is not the same thing as us supporting something. For obvious reasons it would be great if everything we supported was tested here, but because of the vast amount of combinations, we can't do that. We simply try to cover the most common cases here. And that's always up for debate! If you see that something is worth testing in the CI, create a ticket about it and justify why your configuration should be in there. This doesn't just mean adding platforms or compilers. It also means configurations like -no-gui or building examples for Android or something. What's a packaging configuration and why don't Linux binaries work as promised? --- Some configurations in the CI are used to actually create the binaries which we deliver as Qt binaries via the installer. They can be recognized by the "Packaging" keyword in the following files: https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/default.txt https://code.qt.io/cgit/qt/qt5.git/tree/coin/platform_configs/qt5.txt For most platforms this makes a lot of sense and they don't cause problems anywhere, but our Linux binaries are a different thing entirely. Where Windows and macOS binaries work here and there, Linux distros tend to be more strict to what works and where. The library dependencies make things not work backwards as well as on Windows and macOS. Which brings us to the problem mentioned earlier at supported platforms. Binaries created with RHEL 7.4 don't tend to work on openSUSE 42.3, but they do compile. When selecting this operating system which we created packages with, we tend to select a reasonable new one, most preferably a stable one, with a good set of old libraries so that the backwards compatibility is good. Take RHEL 7 for example. RHEL 7.0 was release in June 2014. In July 2017 we got the 7.4 update which we began using. RHEL 7.4 is still compatible with 7.0, which means that our binaries are created with a new distro that creates binaries compatible with distros created in 2014. At least sort of. But the distro we use, isn't always the out-of-the-box distro. When we used RHEL 6.6 for example, we replaced the bluez (for Bluetooth) libraries with own ones so that Qt binaries would have the features enabled that were wished. That actually means that we didn't use RHEL 6.6 to create the releases, but in fact a custom distro based on RHEL 6.6. (off on a tangent here: Qt 5.6 sources actually don't even compile on an out-of-the-box RHEL 6.6 because we now missed that during verification (bug created!). And actually by us installing devtoolsets provided by RHEL, us installing custom Pythons, extracting own libclangs, perhaps build our own openssl from sources, one could actually argue, that we don't use RHEL 7.4 either, but our own custom Linux based on RHEL 7.4. Lifespan of distros --- This is something we should have thought more about, but didn't. Perhaps still don't. Let's take Qt 5.12 as a good example here. Qt 5.12.0 was released on the 6th Dec 2018. It has a promised lifespan to at least the end of 2021. With us actually going development and testing before the actual release, we need to have the environment which we work on working at least 6 months before we release. Now that RHEL 7.4 was such an environment which was available then. Already released July 2017 and having an EOL (end of life) August 2019. Perfect! But the problem is our Qt 5.12.2, .3, .4, .5 releases. Should we be doing releases with a distro that isn't even supported by RedHat themselves? And
