It’s been nearly three months since Calamares transitioned to a community-maintainence model. That’s when I left Blue Systems as the paid maintainer, and so it’s been all-volunteer work since then. “Volunteer” can still mean “an 8 hour day hacking at issues”, but in terms of regularly available time, there’s been a sharp drop off. But let’s take a look at what those three months have brought:
- 3.2.60 release, which introduced a really annoying regression (unless you are in Antigua and Barbados),
- 3.2.61 release, which fixed it,
- 3.3.0-alpha2 release, which is something else entirely.
If a new maintainer shows up, things will be their responsibility, but for the time being, the “Maintainers Crew” is best thought of as myself, Anke Boersma (who has been with the project since its inception) and Evan James. I have a some thoughts about the future, I won’t speak for the others.
On purpose, I wrapped up the 3.2 series as I wound up my paid maintainership. Calamares 3.2 ships on a lot of distro’s, it’s largely stable even though it has never promised any ABI stability. Ongoing, there will be only bugfix and some translation update releases.
The regression in 3.2.60 was entirely my fault, rushing in something at (or after) the last minute. The short-cycle releases, every two weeks, meant that there was a 3.2.59 without that bug, and only two weeks less other work, so my decision was to “fix it right” rather than reverting, for a 3.2.61. It took some time to fix; in the mean time distro’s could sit with 3.2.59 or chase the development branch (there’s always some nutjobs like that).
- new releases when enough material accumulates, based on PRs from the community.
- ABI stability enforced by the release script. This isn’t quite there yet, since the script and CI pipelines need some more work, but the wild-west approach to stability (just recompile) is no longer practical in a stable, LTS-ish (Long Term Support), branch.
- string freeze enforced by the release script.
- translation updates for the coming month or two. Due to the way we translate with Transifex, it is only practical to have one active branch for translation. So, with the string freeze, that also means that eventually translations will be “as good as it gets” (depending on the translation team) and we’ll freeze those as well.
Basically, not much happening, possibly a 3.2.62 at the end of the year if nothing else changes, and then calling this branch “done”.
If a new maintainer shows up, then the next major (minor?) release of Calamares could go in any direction. I had a whole bunch of clean-ups in mind when starting the 3.3 branch, none of which have fully landed yet. These eat some of my free time every now and then.
ABI stability enforced by the release script. This is one reason why there are lengthy alpha releases: the ABI is crufty, the code somewhat haphazard, and it needs cleanup before any kind of ABI stability can be promised that is compatible with future development. In a way, this is a mechanism to force cleanup before a first release, somewhat like the considerations that happen around KDE Frameworks.
Now, for Calamares the considerations are a bit different, and Arch-based distros break ABI things all the time, without checking anything, so I’m not sure the majority needs this, except maybe PostmarketOS which has binary Calamares modules, externally built, which benefit.
Get rid of namespace CalamaresUtils. Some of the code precedes useful nested-namespace support, so the way namespaces are used in Calamares is a mess. That needs fixing – and because it impacts the ABI, needs fixing before a 3.3.0 as far as I’m concerned.
Those are the big ones.
At some point, we will have to switch translations over to the new branch; hopefully before the end
of this calendar year. As far as I’m concerned, while I’m the one pressing
the button to launch the
RELEASE.sh script, these will be alpha-releases
until all the cleanups have been done, and then the translations switched.
How to Contribute
For reporting bugs – if you are an end-user, we encourage you to report to the distribution, who can manage it upstream – there is a nice reporting guide written by Anke to help you provide useful information.
There is a CONTRIBUTING guide that talks about the how and what in more detail. For chat:
.. and I’ll add that Pull Requests are always welcome, although it can be a little slow (and sometimes, we have to say “no”, or shuffle a PR off to a different repository, like calamares-extensions, which is the best upstream spot for specialty modules).