Arch Linux Could Use Some Help With Toolchain Maintenance

[mdedetrich]

On my part, I believe this issue is more widespread and it doesn't concern Arch only, rather it's due to a cultural shift - we have to face the reality that unless something changes radically in the future, young people on the whole are no longer as interested in open source and volunteering and forming/participating in tech communities as they used to be just a scant generation ago (i.e. in the '00s), and this has or at least will very probably have a terrible effect on Linux as a whole (has anyone ever wondered what will happen to Linux - the kernel - in, say, 10 years when the current old-ish guard steps away?). It's fast becoming a situation where open source is dependent on corporations to provide the effort necessary to keep it afloat and up-to-date in terms of even such basic things as security fixes. It's not a secret that even now, many if not most of the new and shiny Linux features (from Wayland, to Gnome and KDE, to device drivers, to the kernel itself) are fueled or at least majorly assisted by some corporation or another that have invested themselves in that feature and payed some devs to implement it and/or maintain it. And don't even get me started on what will happen if and when Linux becomes even a tiny bit bigger than it is now - say 5% of the market - and the requirements in manpower for it to stay afloat increase proportionally.

/rant

I would say this is a simplistic conclusion. While it may be true that the open source culture has shifted, there are now in absolute numbers many more open source contributors (regardless of their values or ethics).

I think the bigger core problem is how complex systems have become over time, I wouldn't say its a stretch that both the kernel and what distributions have to handle nowadays is more complicated and more importantly the expectations are a lot higher because of people wanting those complications to be handled more easily.

[ⲣⲂaggins]

Possibly as a result of the phoronix exposure:

https://lists.archlinux.org/pipermai...ry/030729.html

[leipero]

This doesn't seem to be the fault of Arch from what I gather, it seems to me that GCC build process is just overcomplicated and it's probably possible to do it in more efficent way, GNU people tend to overcomplicate things that actually can be simple, my fav. example as always, autotools.

[gfunk]

To help with this issue, is it better to donate to the Arch project as a whole or individual developers solving a specific problem?
Assuming funding will help solve the problem

[TemplarGR]

The problem with Arch, is something that tends to happen in many community projects: It starts through a passion project, it becomes successful and well-known, and then others infiltrate its team in order to gain prestige for their CVs and not caring about the project much. Eventually, those people become the majority, and since they don't want to be sidetracked in the project, they decline any contributions or additions to the team all the while leaving the project to whither and die.

Right now there are many Arch devs, that while they do not want to actually work on the project and if criticized use various excuses, yet they do not open their positions to others because they enjoy the prestige of being "an Arch linux developer". It is disgusting, really. Of course they won't admit it, but it is pretty evident that this is happening. For example, Archlinux took like 2 months to update to GNOME 41. Because the developer assigned to it simply didn't care to update it. It wasn't a difficult update. He just didn't bother. Yet he didn't bother to ask someone else from the team to do the update, or ask for new people to step up, he simply took the time and left one of the 2 major DEs with no update for 2 months for no reason. When i opened a forum thread about it in Arch forums to ask why there is such a lag for the GNOME packages and if the developers are stressed, why don't they announce the need for more contributors? Well, the moderator stepped up to silence the thread with the excuse that "it doesn't go anywhere". That is the Arch mentality currently.

I am still using Archlinux but honestly i am really bothered with the current developer culture in the project. They don't care to do a good job, and they don't ask for more developers/announce they have a problem. Pathetic.

[lumks]

If my sarcasm wasn't clear, this was in no way a DDOS (which is maicious intent to bring down a service using techniques like botnets).

DDOS doesnt need to be malicious. It's just means Distributed-Denial-of-Service and this is what Manjaro users did to AUR, because of bad coding, to be more clear "no resource management in mind". Sadly Manjaro never cared about available resources for something as they do not use own resources somewhere, except things they are also unable to properly maintain. As the yearly domain cert out-of-date message for at least one of the servers shows.

This thankfully was changed, thanks to Arch devs who just blocked Pamac over and over.

What actually happened is that AUR service wasn't well built and/or didn't have enough server capacity to handle query parameter search's whenever someone was trying to search for an AUR package in the pamac (manjaro) GUI clients.

The problem was that that the server was asked by every character on every search, not only AUR, but every single character of every search in Pamac (and for GNOME even outside of Pamac as pamac is integrated into gnome shells search too). This means 10th of queries per secound by a single user and there are 1000th of users who did this.

This kind of problem happens when a distro ends up being popular, you need to scale.....

Not at all. you just need to be aware that there is a limit on resources and that you should absolutely NOT abuse someone elses infrastructure as Manjaro did and does.

In the end the solution was for Manjaro to disable all search functionality for AUR within Pamac rather than fixing the root problem.

In the end the temporary workaround was that Pamac was blocked by Arch multiple times until they changed the code to be not to heavy on Archs infrastructure. What should have been done from the start.
Please read:

1. https://gitlab.manjaro.org/applicati.../-/issues/1017
2. https://gitlab.manjaro.org/applicati.../-/issues/1135

The positive change is that there now also is a metadata archive for AUR clients, that is currently not used by pamac

https://gitlab.manjaro.org/applicati.../-/issues/1161

[lumks]

Right now there are many Arch devs, that while they do not want to actually work on the project

Who?

and if criticized use various excuses, yet they do not open their positions to others

One dev doesnt block more devs from joining. The Problem is that people actively need to proof that they are able to handle a critical part and also want to do that. It's not to simple to have a good view on the core parts of Arch, on the Infrastructure and such. there isnt just a repository that needs to be up. And all of this is split between barely 30 people. So of course something lacks manpower all the time.

because they enjoy the prestige of being "an Arch linux developer". It is disgusting, really. Of course they won't admit it, but it is pretty evident that this is happening.

It is? How?

For example, Archlinux took like 2 months to update to GNOME 41. Because the developer assigned to it simply didn't care to update it. It wasn't a difficult update. He just didn't bother.

GNOME sits in extra. So in fact it needs an Dev, not a TU to update it. There is only 1 Dev who does the job and he actively joined the FCGU Arch GNOME Unstable Matrix Chat to reach out for help. But because it's not that easy to jump in as "nobody" to the position as Arch Dev (For good reasons, as you can pretty much screw the core repo by an ooopsi commit). Direct help wasn't possible.

Yet he didn't bother to ask someone else from the team to do the update, or ask for new people to step up, he simply took the time and left one of the 2 major DEs with no update for 2 months for no reason.

He did care. The GNOME desktop team is underpowered by a lot (basically one guy, also doing more important work on Kernel level and other things). He reached out to the community and did get help. As explained above sadly not direct help but that might change in future and he does this in his free time, without getting any money.

When i opened a forum thread about it in Arch forums to ask why there is such a lag for the GNOME packages and if the developers are stressed, why don't they announce the need for more contributors?

Because that's not the problem. It's easy to write a PKGBUILD. Nobody needs contributors for this. It needs people to test them and give good feedback, as many packages do have an impact on other packages too and testing will take more time.

Well, the moderator stepped up to silence the thread with the excuse that "it doesn't go anywhere". That is the Arch mentality currently.

Thats the way to go. Don't be loud about that. If you want to help, help. Just reach out and help. There is a lot to do, also for external sources, as many provide an external repo for testing purposes and later on can be integrated into Arch directly.

I am still using Archlinux but honestly i am really bothered with the current developer culture in the project.

To be honest, If you're not part of the solution, you're part of the problem. You seems to be unaware how things work and I cant see any intention to change that or actually help.

They don't care to do a good job, and they don't ask for more developers/announce they have a problem. Pathetic.

Whats the Dunning–Kruger effect?

[TemplarGR]

Who?


One dev doesnt block more devs from joining. The Problem is that people actively need to proof that they are able to handle a critical part and also want to do that. It's not to simple to have a good view on the core parts of Arch, on the Infrastructure and such. there isnt just a repository that needs to be up. And all of this is split between barely 30 people. So of course something lacks manpower all the time.


It is? How?


GNOME sits in extra. So in fact it needs an Dev, not a TU to update it. There is only 1 Dev who does the job and he actively joined the FCGU Arch GNOME Unstable Matrix Chat to reach out for help. But because it's not that easy to jump in as "nobody" to the position as Arch Dev (For good reasons, as you can pretty much screw the core repo by an ooopsi commit). Direct help wasn't possible.





He did care. The GNOME desktop team is underpowered by a lot (basically one guy, also doing more important work on Kernel level and other things). He reached out to the community and did get help. As explained above sadly not direct help but that might change in future and he does this in his free time, without getting any money.


Because that's not the problem. It's easy to write a PKGBUILD. Nobody needs contributors for this. It needs people to test them and give good feedback, as many packages do have an impact on other packages too and testing will take more time.


Thats the way to go. Don't be loud about that. If you want to help, help. Just reach out and help. There is a lot to do, also for external sources, as many provide an external repo for testing purposes and later on can be integrated into Arch directly.


To be honest, If you're not part of the solution, you're part of the problem. You seems to be unaware how things work and I cant see any intention to change that or actually help.



Whats the Dunning–Kruger effect?

Indeed, you are suffering from Dunning-Kruger effect, like 99% of the Arch devs. Too much toxicity and elitism. You spew your lies every time you receive criticism. It is easier to lie about the situation than admitting you are wrong. Even in the thread i mentioned in the Arch forums, a fellow Arch user said that he had instantly (few days) updated GNOME for his own use, and he would be happy to contribute the packages, but he couldn't.... There are a lot of people both able and willing to contribute to Arch, but Arch devs make everything in their power to make the process difficult and obscure. How one does become a Trusted User? And even if he manages to do that, how he becomes a developer in order to be able to touch more important packages? The process is a pain in the behind, full of obstacles. Arch devs make no effort at all to recruit new blood, they do everything in their power to discourage people from joining, all the while refusing to work on the project with the typical excuse "too much work in my life, problems, blah blah blah". Yes, developers are people, Arch is a community project and free, so why not ask for more people to join? It is not hard to compile Arch packages. Not hard at all. Most of the time you just need to upgrade the software version and the signatures. Big trouble... The guy who compiled GNOME on his own, said he didn't encounter any issues.... And there shouldn't be any.

Why Arch devs don't admit they just don't want to recruit more devs because they feel they own Arch and it is theirs and only theirs, is beyond me. It is easier that way. Just place a notification in Arch website in the frontpage explaining that devs don't really care about updating packages and will do it at their leisure, while also they don't want any other to join the team. So people can know this before installing Arch, instead of figuring this out from experience.

[Setif]

..., and then others infiltrate its team in order to gain prestige for their CVs and not caring about the project much.

Some of them infiltrate it just to push their political agenda, so instead of focusing on the project development they brought other topics (inclusivity, outreachy, human rights,...) in the name of bringing more contributors.
They show themselves as the saviors of the project while in reality they push people back from contributing.
For example they push for ABCDXYZ+-* stuff, while only the western countries (~1billion) accept those things, excluding (or at least pushing their politics-culture-ideolgy on) others (~6billions).

[signed_log]

It's a great showdown of how important a automated testing farm is.

But, they wouldn't be able to do that, for a simple reasons, no company financially sponsors Arch ecosystem, so they have absolutely no way to have a suitable testing farm without risking financial trouble (and they don't want the hassle that comes with having such farm)

Not to advertise openSUSE but, I'm a openSUSE afficionado, openSUSE is SUSE-supported hardware-wise, which is why they have the possibility of running all their extensive release toolchain, with the center being OBS, for so many different arches and distros.

openQA does such a great job to keep Factory (and in turn Tumbleweed for around to 3-5 times a week) so at the edge with no real major issue for a while.

Arch could be way better steered only if they had any kind of testing farm, it's a rolling distro, not a scattered one. Even Debian has its own openQA instance