As a followup to this earlier conversation, I've restored the older Ubuntu 20.04 build in https://gitlab.com/libtiff/libtiff/-/merge_requests/358.
If anyone wants to support an older build, we will need to create an appropriate Docker build image. https://gitlab.com/libtiff/libtiff-ci-ubuntu20.04 could be used as a template. Then the libtiff CI build will need an extra job adding to make use of it. I don't have the time to support this personally, but if anyone would like to commit to making and supporting such an image, along with supporting any ongoing build failures within libtiff, we can certainly review and integrate it. Kind regards, Roger -----Original Message----- From: Tiff <[email protected]> On Behalf Of [email protected] Sent: 05 June 2022 12:11 To: 'Greg Troxel' <[email protected]> Cc: 'Tiff List' <[email protected]> Subject: Re: [Tiff] Upgrade of CI image Hi Greg, These are all good points. As you said, it all comes down to supporting what is documented. Unfortunately, that isn't too clear, and having a reasonable set of requirements properly agreed on and documented would make the scope for CI testing clearer. If you look at the CI testing (example: https://gitlab.com/libtiff/libtiff/-/pipelines/555776687), you'll see we have a reasonable coverage of various platforms. We test Cygwin, MinGW and VS2019 on Windows through AppVeyor. And we test GCC on Ubuntu Linux using GitLab directly (and until last week, LLVM/clang on FreeBSD arm64 which I had to offline due to the storage being knackered). Mac OS X has no CI coverage at present (we can add it now GitLab support it but we need to register for it). We could support a wider range of MSVC/Visual Studio versions. We don't yet test on VS2022. We could test on VS2017 or earlier. But every addition to the build matrix does have a maintenance burden as well as slowing things down. The same applies to testing multiple Linux distributions and distribution versions. Where do we draw the line? What would be "good enough"? On top of that we test both CMake and Autotools and if we were truly comprehensive the combinatorial explosion would be huge. So I'm not averse to extending the coverage at all, but I do want to keep it manageable. One point to consider is who our primary consumers/customers are. I'd posit our biggest users, by a large margin, are using pre-packaged libtiff builds provided by package managers, and that ensuring they are getting a well-tested and usable library release has the biggest cost:benefit for our end users and developers. This includes all of the Linux package managers (apt/yum/dnf/gentoo/arch), MacOS (brew and MacPorts), FreeBSD and other BSD ports trees, and more recently vcpkg on Windows. The main thread with all of these is that they are either rolling releases building against a recent toolchain, or they are built against a recent toolchain and then frozen for the lifetime of a distribution's major release. What we don't have is building of a new libtiff release on an older platform (for the most part). It ends up causing ABI breaks on LTS releases when it conflicts with the system copy. Look at pylibtiff for an example of that. So testing on current platforms is most beneficial for ensuring that all of these consumers are getting a working release. The other use case would be direct embedding of libtiff as a third-party library within a larger project, or hand-building libtiff and using it within other projects. This is common in proprietary projects. This is more difficult to support since we're both unpaid volunteers and we have no insight into what people are actually using. I'm totally on board with adding e.g. Ubuntu 20.04 back and maybe back to 18.04 as well. However, we do need to be somewhat restrained in how many jobs we have in total, and which build system we test for each platform. I would *love* to have some data on which GCC versions people are using, so that we have some evidence to justify what we are committing to support, rather than blindly supporting old systems "just because". If our primary userbase isn't even using new versions of libtiff on older systems, the cost:benefit would be low. Once the new sphinx docs (rst-docs branch) are merged, I would be very happy if we were to add a "supported platforms" page to the docs which details this properly. It would be great to gather comments. I created https://gitlab.com/libtiff/libtiff/-/issues/430 for this, so if anyone wants to contribute any data, please feel free. Kind regards, Roger -----Original Message----- From: Greg Troxel <[email protected]> Sent: 05 June 2022 00:35 To: [email protected] Cc: 'Tiff List' <[email protected]> Subject: Re: [Tiff] Upgrade of CI image <[email protected]> writes: > Our current CI is based upon Ubuntu 20.04. Now we have a new 22.04 > LTS release out, I've added a new repository for this. Initial MR here: > > https://gitlab.com/libtiff/libtiff-ci-ubuntu22.04/-/merge_requests/2 (Based on experience dealing with CI for unison, file sync not geo.) I'm surprised by "replace 20.04 by 22.04". To me the point of CI is to build and run tests on all systems where tiff might reasonably run, or at least within the scope of where the README says it ought to run. I think that's something like "all reasonable mostly-POSIX systems that are still maintained, and have [minimal toolchain requirements]". Plus probably people use it on Windows, but I'm clueless about that :-) In particular it's important to ensure that it still builds and works with the oldest tools that are documented to work. Packages that don't do that tend to depend on things they shouldn't, like features in gcc-N++ when N is specified, and things in Linux but not POSIX. So I would suggest adding a job for 22.04 and leaving 20.04. And testing on 18.04 if that's as simple as another duplication. After that priorities would be other CPUs and other operating systems -- but CI farms tend to be very monoculturish, or at least triculturish. All easier said than done, I know. And I know nothing about gitlab CI; my experience is with github because that's where unison was when I became maintainer. Greg _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff _______________________________________________ Tiff mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/tiff
