Ideally and in principle, I agree from a UI / UX perspective. Shipping such regressions into production /
stable isn’t a great look from a user-centric point of view. With Arch-based distros being rolling-release, and Manjaro with its’ staged rollout from
stable branches would, in an ideal world, have lots of QA testing & iterative development feedback loop cycles between the staged promotion of packages. However, that would require enough people with systems on
testing branches who also have the technical competence and enough proficiency to find & access the appropriate upstream & packaging repos to catch bugs and problems before they flow into
I’m sure we’re all aware that, unfortunately, we don’t live in an ideal world. There are probably many barriers to entry for people to meet those criteria and to reach that level in the community, and the number of new users likely will always outnumber the highly skilled & proficient developers and package maintainers.
As such, the best we can do is try to set expectations with users appropriately. Developer & maintainer time is probably not going to be enough to do proper QA testing for everything. So, disclaimers are given about Manjaro being a community of volunteers. Warnings about using the AUR are given on the Manjaro side of things, etc…
A slight bit off-topic, but it may help understand the situation for developers & maintainers a bit to look at the following quick “case study” comparison:
Case study: Debian -> Ubuntu vs. ArchLinux -> Manjaro
Let’s look at Debian → Ubuntu for example. It’s a similar inter-distro relationship, but rather than rolling-release, they both have regular release cycles with an end product that has an officially named release. Canonical is able to provide resources to fund development, but the packaging flow is much slower than any rolling-release distro. This buys them a lot more time to address critical bugs & regressions before they reach an LTS release. Additionally, for community member volunteers there are a few major barriers to entry, outlined below.
Barriers to entry:
- Debian packaging tools are a bit esoteric, and require reading many chapters to understand
- The packaging structure is complex (e.g. the
debian/rules file, the
debian/patches/* files, and others)
- There are many tools the user must familiarize themselves with to do proper packaging (e.g.
- Maintainership training & access is hard to achieve
- The mentorship program is difficult to access (believe me, I’ve tried)
- MOTU developers are busy enough already, leaving little time to mentor new members
- those meetings happened over IRC, but given the 2020-2021 Freenode mass-exodus, it’s unclear where meetings are held now (wiki pages outdated)
- If you’re lucky to live in the right area, maybe a LoCo team is close enough?
Meanwhile comparing this to ArchLinux → Manjaro:
- Packaging tools are much easier to understand!
PKGBUILD file & syntax, which is mostly a shell-script anyway.
- Just need basic knowledge of the project’s build system tools (e.g.
meson), and how to use
gpg (optionally for signing)
- Personal packaging repos are a simple HTTP server setup +
repo-add away from easy local package testing.
- Development moved to GitLab recently, opening up pull/merge-requests for community developers & package maintainers (experience should get better once the account-registration spam issue is resolved)
- Maintainership is more accessible
- The AUR & process for becoming a TU is clear & documented in the Wiki
- IRC channel is on LiberaChat, and Wiki is up-to-date about this!
So for Arch-based distros, the barriers to entry are lower. However, that means more people of all skillsets & skill-levels are able to volunteer and impact the state of packages on the AUR. This means that things will be in a possibly more chaotic state given the nature of the AUR vs. official repos. (Not saying this applies to this particular
pamac issue… but just in general painting a full picture) The official packages (e.g.
pamac) are still maintained by those working officially for ArchLinux & Manjaro. This is somewhat similar to the official packaging channels for Ubuntu being maintained by Canonical, versus the
universe repos maintained by MOTU community members.
Number of employees:
Number of users (approximated based on survey data extrapolation with 32.8 million Linux users):
- ArchLinux: ~9.33 million
- Debian: ~3.26 million
Staff to User ratios (approximate
staff : 1 user):
Disclaimer: I’m not sure how accurate these LinkedIn employee counts are, and not sure how to gauge the approximate community sizes given the distributed & decentralized nature of *nix distros.
For all distros, the upstream development and upgrade of dependencies (e.g.
gtk4) can produce instability when changes are made to the dependency tree, which can sometimes get quite complex and produce unintended results when components are built and put together. The combinations and permunations of packaging dependencies + their versions can make for an astronomical number of things to test. Think of a QA testing / traceability matrix table which blows up in multiple dimensions to some kind of hyper-dimensional matrix in non-euclidean n-dimensional space (a hyper-hyper-cube? ). The problem-space grows exponentially when dependency & versioning complexity increases. For an entire Linux distro, it gets to astronomical levels of complexity. The time required to test all possible combinatorial configurations will always exceed the time and number of developers available to find & fix bugs.
Yet again, there is a similarity between the smaller number of people working at Debian & Canonical to maintain the official packages for Debian + Ubuntu, similarly to how the ArchLinux & Manjaro support staff is likely outnumbered by AUR maintainers & users combined.
Meanwhile, the timing and flow of Debian stable → Ubuntu’s interrim + LTS release cycle is a bit slower overall than ArchLinux → Manjaro’s rolling-release + staged branch cycle. Again, the longer and slower rollout of packages on the Debian-based distros results in buying more time to get bugs fixed before they end up in an LTS release. However, even with that slower cycle things still find their way into an LTS release. With ArchLinux & Manjaro, the picture is similar, yet with less time to prevent bugs & issues from rolling out. This results in a slightly less stable upgrade process in the short term… but with periods of relative stability once bugs and issues are found & the bugfixes roll out the next cycle.
EDIT: Added approximate staff to user counts for case-study distros
staff: 1 user ratio results, and clarified how approximate users were calculated (using 32.8 million Linux users total).