What’s in a top-tier distro?
Learn how Fedora and Ubuntu are engineered, governed and supported.
THE ART OF GOOD REPORTING “If you think you’ve found a bug then familiarise yourself with the bugreporting process for each distro, so that the developers can fix it”
Just as anyone can contribute to the Linux Kernel, so anyone can contribute to Fedora or Ubuntu. You don’t need to be a seasoned coder – there are always translation and documentation tasks to do. If you’re a dab hand with a (virtual) paintbrush maybe you could contribute some icons, themes and logos too. Distro development isn’t some communist free for all, though. There are committees and managerial structures, though these are in general much less rigid than you’d find in a similar-sized company. In 2015 some 35 per cent of the 2,000-odd Fedora contributors were Red Hat employees, though the remaining 65 per cent may well have been working for someone else.
We won’t get into the technical minutia of how a distro is actually made. Look at the appropriate -next branch of any distro’s GitHub and you can get an idea of the process. For illustration though, a week after the release of Ubuntu 21.10, the first daily builds of 22.04 (Jammy Jellyfish) appeared. These at the time of writing hardly differ at all from the 21.10 release, since the first steps are to decide on the build environment and get everyone’s toolchains synced. You can find the release schedule at https://discourse.ubuntu.com/t/jammyjellyfish-release-schedule/23906, which shows when new software planned for inclusion is released.
OpenSSL 3 and Ruby 3.0 are both slated for release in November, for example. If you’re upset that Ubuntu 21.10 missed out on Gnome 41 (by dint of misaligned release schedules), you’ll be pleased to hear that Gnome 42 will (assuming no delays to its release) be powering the Ubuntu 22.04 desktop.
Chains of command
Fedora is governed primarily by the Fedora Council, which includes representatives from all over the project, Red Hat-nominated members and a few others. Beneath that are FESCo, the Fedora Engineering Steering Committee, and MindShare. FESco is responsible for deciding on the technical direction of the project and MindShare is all about community outreach, conducting liaison between teams and encouraging contributors to mix with other teams. Reporting into FESCo and MindShare are many smaller Engineering and Community teams. See the diagram (below left).
Like Fedora, Ubuntu’s development releases feed into its big, stable releases (the LTSes) which is what people will run on their servers and will be supported for 10 years (with an Ubuntu Advantage subscription). It’s these releases, in conjunction with Canonical’s support for enterprise tooling (OpenStack, Kubernetes, Ceph, etc), that fill its coffers, so it’s in its interests to make the LTS editions fantastic. Also like Fedora, contributions to each new release don’t just come from Canonical employees, but also from other companies and volunteers. Oversight is apportioned between the Ubuntu Technical Board and the Ubuntu Community Council, which are analagous to FESCo and MindShare. A key difference is that Ubuntu has a SABDFL (self-appointed benevolent dictator for life) in the form of Mark Shuttleworth, who has a casting vote on both of these committees.
Ubuntu’s Technical Board and Community council both meet fortnightly on IRC. This might seem like an outdated (or, if you’ve never used IRC before, complicated) way to do meetings. But it’s better than Zoom and,
since it’s how a great deal of open source projects are co-ordinated, is unlikely to go away soon. Fedora boards also use IRC, and have a great guide for newcomers at https://fedoramagazine.org/beginners-guide-irc.
Perhaps an overlooked part of making a distro is baking the files (ISO or USB images) that people will download and install. Fedora and Ubuntu both have their own tools for doing this non-trivial task.
Support levels
Both Canonical and Red Hat make money from providing support to their Enterprise customers. For machines on your own infrastructure, Canonical offers Ubuntu Advantage for Infrastructure (UA-I) and a quick glance at https://ubuntu.com/pricing shows that comes in three tiers. Its cheapest Essential support offering is available to those using the LTS releases on servers ($225 per machine per year), virtual machines ($75) and desktops. This doesn’t include phone support, but you can pay extra ($525 per annum) for that, and is only available for their LTS offerings. If you’re looking for paid support with installation, drivers or anything else consumer oriented then this isn’t really for you. It’s more aimed at infrastructure and server management (using Canonical’s Landscape administration tool).
That said, the Essential tier is available for free on up to three machines (or 50 if you’re an Official Community Member), and includes Extended Security Maintenance for older releases (namely 14.04 and 16.04) and access to the kernel live patching service. Again, kernel patching is only available for the standard LTS kernel, so no use for Ubuntu 21.10. Fedora is a community supported distribution, so there’s no paid support there. Red Hat supports Red Hat Enterprise Linux, which technology tested in Fedora (and now CentOS Stream too) will eventually find its way into once it’s stabilised. If you want support (beyond updates) with Kubernetes or OpenStack then you need to move up to the Standard tier. If you’re running Ubuntu on a public cloud, i.e. AWS, Azure or GCP, then you can, for a tiny bump on your hourly costs, switch to Ubuntu Pro instead.
For community support, there are official Ask Fedora and an Ask Ubuntu websites (run on Discourse and StackOverflow, respectively). These both receive dozens of questions a day, and both have easily accessible information on how to ask good questions and be a good human. There are also more traditional forums at The Fedora Lounge (https://forums.fedoralounge.com) and https://ubuntuforums.org). If you think you’ve found a bug then familiarise yourself with the bugreporting process for each distro, so that the developers can fix it. If you’re a beginner, or angry, then please resist the temptation to post until you’re familiar with this process or have calmed down.
For tracking bugs Fedora uses the popular Bugzilla application where as Ubuntu uses the equally popular Launchpad. Both platforms have much the same workflow: bug reports are triaged, tested and (hopefully) fixed, but they might also be marked as “Won’tFix” (where the issue is judged not to be a problem) or as a duplicate of another bug. The Bugzilla application is also used for feature requests, but again you should familiarise yourself with the etiquette here. Launchpad enables more advanced users to file ‘blueprints’ for desired features.
It goes without saying that you should perform due diligence and check your bug (or feature request) hasn’t already been reported before filing a new one. Fedora maintains a list of common bugs at https:// fedoraproject.org/wiki/Bugs/Common, which you should scrutinise for the aberration you’re planning on reporting. Sometimes the same bug will manifest itself in different ways, so inevitably some seemingly different bugs will end up being marked as duplicates.