Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: remove ubuntu 22.04 job #9707

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tobtoht
Copy link
Collaborator

@tobtoht tobtoht commented Jan 15, 2025

Assumes #9680.

The Ubuntu 22.04 job is a little redundant now that we have a job for a bleeding-edge Linux distro (Arch Linux). Builds failing due to package upgrades will most likely get caught by this run.

@iamamyth
Copy link

Couldn't you make a similar argument for debian 10 and ubuntu 20? If anything, I'd rather keep ubuntu 22 than 20, as it's quite a popular distro (in effect making the test matrix: upcoming, common/popular base, and oldest).

@tobtoht
Copy link
Collaborator Author

tobtoht commented Jan 15, 2025

The jobs for Debian 10 and Ubuntu 20.04 serve a specific purpose: to ensure we don't accidentally break development builds on the oldest supported distributions. Due to how EOL policies line up, Debian does not always have the oldest packages, so it's important to keep both.

The most recent packages are covered by the bleeding edge job. Build issues with recent packages can be fixed before they land in more recent Ubuntu versions.

I don't know where 22.04 fits in here. If we want to keep it, we should define a deprecation policy, so it's clear to (future) maintainers when it should be removed/upgraded.

@iamamyth
Copy link

Due to how EOL policies line up, Debian does not always have the oldest packages, so it's important to keep both.

I had forgotten Ubuntu sometimes ends up with older packages than the roughly equivalent Debian version.

I don't know where 22.04 fits in here

Ubuntu 22.04 was the "common/popular" part of the test matrix from my earlier comment; maybe that should now be 24, but it seems a bit too recent to have more users than 22. I can see a case for eliminating it to save build time, but theoretical backwards-compat doesn't always translate to reality (compilers especially like to break things). As for update timelines, particularly if there's an Arch build, I'd guess 1-2 years after a new LTS distro gets released, rounding up to two; perhaps we can find some data to better inform the decision, if we want to keep it.

@iamamyth
Copy link

Here are some initial stats on Ubuntu usage:
https://fr.archive.ubuntu.com/stats/stats_of_day-24.html?version=last
https://fr.archive.ubuntu.com/stats/stats_of_day-406.html?version=last

So, ~1.6 years after 22 was released, it easily eclipsed 20, whereas 24 had virtually no usage 7 months after release. I'd say the next LTS becomes the "most popular" after 18 months maybe?

@selsta
Copy link
Collaborator

selsta commented Jan 15, 2025

I think it does not hurt to keep it if it adds a different compiler version compared to the other CI jobs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants