Hi @jolic, thx for asking what the situation with stable updates on ARM are. It is a little complex. You can check the packages mailing list to see how many syncs, pushes or commits were done to the binary packages repositories and by whom.
x86_64 architecture is more active as more people are using it. Even when you use ARM parts of Manjaro, most likely you will also have some x86_64 machines you might run at your home with Manjaro too.
When we look back to i686 architecture, Manjaro also had to maintain that architecture too. So a sync from Arch would also pull those packages to Manjaro. However, that architecture was dropped at some point. Regardless of that, package maintainers had to compile our overlay packages for both architectures back then.
When we talk ARM then the upstream distribution is currently Archlinux ARM or short ALARM. They do push packages to their repos and update their stuff. However, there might be a misunderstanding on how we get the packages from Arch or ALARM.
Well, it is still a manual process via our tool boxit. You might see daily updates on unstable branch for x86_64 simply cos our developers and package maintainers call boxit sync
when ever they see a need to do so. On ARM side this happens not so often or for some months not at all.
There will be some updates to arm-unstable branch, but those might be just kernels or few packages.
The overall concept however is simple but get kinda complex on ARM, more than it is on x86_64. So what is the magic behind stable updates?
- first, a developer or release manager is syncing from ALARM via
boxit sync
- then we normally discuss and check possible todo-lists from Arch and if ALARM adopted those.
- then our overlay packages might need rebuilds or updates to possible library changes made by the upstream distribution
- when that is all done the actual fun begins. ARM is not like x86_64 where we can assume on an AMD system Plasma, XFCE, GNOME and other desktop environments might work similar as on an Intel system. Sure there will be different graphic cards like AMD, Intel and Nvidia in the mix, but there mostly the drivers work. On ARM however we have different SBCs and some more commercial like devices like Pinephones, Pine64 laptops and some other MiniPC like devices from other vendors. All those have different firmwares and boot files plus also different kernels and drivers sometimes. So a Rasberry Pi4 might work but for some odd reason a Pi5 not. Or some SBC with Rockchip SoC act differently. Then you might need to discuss within the team or testers, who have that device on how to debug it or simply ship it knowing we will break some installations. Mostly developers even test packages first locally before they get added to our repositories. On x86_64 we normally ship and test after. ARM is more fragile in that regard.
- lets assume those tasks all succeeded somehow, then we do the snap to arm-testing
- hopefully some community testers will then pick up those updates and give it a swing. Based on their feedback we will fix remaining issues and push the set to arm-stable
- then the device images get created and tested again on all devices we currently support. when that is done the release announcement is written and published on our forums
- then another sync from ALARM to arm-unstable happens and the cycle repeats
So the whole process we somehow managed to do in 2 months. However, since the ARM team changed and not all supported devices are at our end for testing, less updates were made to arm-stable branch. Device images are currently only auto-generated but not tested at all.
So how to change that? Well, first we have to reduce all supported images and only focus on the few we might have devices on our end. Then we might need more people who might want to join the ARM team on our end and pick up what old members left of. When new tools like bxt get introduced at some point our workflow needs to be adopted or changed.
When I started Manjaro with friends 13 years ago, we just wanted a simpler Arch and don’t case Arch when they updated their repos, hence we cloned them to our end and had all the time we needed to update our packages. The team was small and we were agile.
Now the project has grown and has even more architectures than it had before. So we might also need to grow our team to give better support to those who use this distribution.
I tried as interim release manager for some time, but my time is very limited these days.