I hate to bring it up again but the alire-index pull requests are 3 weeks and 39 pull requests behind. Especially outside requests like the one for yamlscript are quite embarrassing.
Doubt there are many maintainers or those who can approve PRs. They might have something on irl so best we can do is be patient for now ^_^.
That is the problem. We don’t have enough maintainers. There are three as far as I know with @mosteo doing most of the work.
But it’s not just us. There are several pull requests from companies and outside communities who provide Ada bindings to there product. They might come to the conclusion that providing and Ada binding is a waste of time because the Ada community “is dead”.
Well I guess this is one of those famously difficult problems in open source in general. Maintainers have life outside OSS and cannot always fully commit all the time.
As for PR count and delay till merging there are worse projects though mostly the extremely large ones. For the current scale admittedly the PR process is a bit slow.
There could be some sort of auto approval process that the larger package management ecosystem eventually shift over to but I am not sure if we are ready for that yet.
Resolved many decades ago. Once you’ve got the maintainer status for the given project you can do with it whatever you want.
There should be none. The maintainer uploads a release. End of story.
There could be projects combining other projects, the maintainers of such second order projects (e.g. “distributions”) are free to decide what and how. For example, developers largely refused to adopt GTK 4. Nobody died.
I guess like what @krischik mentioned the bigger issue is the lack of maintainers. And what I am alluding to is more so that and the fact that it is difficult to build trust and mentor people to the point that they can be trusted as maintainers for the long term longevity and health of the project.
Torvalds and the creator of the Zig programming language has been warnings about this for a while, especially as the advent of LLMs has made the default in open source be not trusting and more skeptical of incoming contributions unlike before.
This would be true for almost every type of open source project outside of package management stuff which typically have semi to fully automated publishing future releases of a crate (the initial release PR is examined with more scrutiny, with good reason of course). At the project’s current scale, fully auditing every PR is feasible but it begins to get feasible or downright impossible at the scale of stuff like PyPi, npm and crates.io (just to name a few).
P.S. Hope I am not going on too much of a tangent here, but these are just my two cents on the matter.
Idk know what happened but two of three Alire-Project maintainers have been absent for a worryingly long time.
@Fabien.C hasn’t been active since the 25th of June and @csagaert hasn’t really been active since the middle of August (But that could just be a long vacation).
For what I know @mosteo is currently the only active maintainer but he has been sick (See Backlog in index submissions · alire-project/alire · Discussion #2184 · GitHub)
I wish him a speedy recovery. But it does kinda suck that everything is reliant on just one person.
I agree with you. That’s why I’d suggest adding new maintainers, specifically you @krischik as an Alire Index Maintainer since you’re the third biggest contributor to the index. And (if it’s OK with the current maintainers and others) I’d suggest myself as an Alire Codebase Maintainer.
There is probably a lot more to discus when one of the three maintainers comes back online but in the mean time we could already work on a selection of new project maintainers.
Why cant that be automated? A local LLM, harnessed to let only code through that paases compiler and GNATPROVE. Could such code then be harmful if in Alire?
We could have a two-tier index, similar to Debian’s unstable and testing suites. New releases would land in an “unstable” index immediately, with no waiting on review. Once reviewed, they’d be promoted to the main index that alr uses by default.
The unstable tier wouldn’t need much infrastructure. A bot that watches alire-index PRs and automatically merges them into a separate branch would be enough. Anyone who wants the latest releases could add that branch with alr index --add.
I missed that one. In future I will check the discussion as well as the pull requests.
I’m already in the process but I’m not yet trusted to make the actual merge. I which I could at least trigger the workflows for the new projects so they don’t have the double wait.
I’m cheating a little here as I have lot’s of small crates (tutorials, small tools for retro computing) for which I make lot’s of small improvements. And every time I update AdaCL I recompile and re-release everything.
The code is not actually checked. See the REVIEWING guidelines. It’s mostly the alire.toml file that is checked for completeness. Plus a few extra checks for new projects.
That’s what I do for myself already using a private index.
Martin
It is automated via github actions. You can’t submit for a review until it compiles on many platforms. As with all automation it is more reliable but perhaps more work without an LLM which always brings with it an inherent error rate.
Initially manual auditing of crates was said to be due to preventing names of well known existing packages being taken by new projects or squatted on. I guess that time has passed?
Though there was also a mention of keeping the quality high whilst possible.
It’s still in the guidelines. As well as not having „ada“ in the name. But that check has been automated. However, user can request to keep the „ada“ if there is good reason. And that still needs manual review.
I don’t think it can be fully automated.
Martin.
How much in running cost you think that might need, a secondary index I mean.
Agreed there should be a way to trust packages before they end up on alire or any other index. How would you want to achieve that? Checksums?
I understand now, thank you.
Alire review and backlog might be something @markhermeling could address at Ada/SPARK office hours.
Looks like a whole bunch of PRs got approved.
Yes that was me 
Since those are explicitly not code reviews, but mainly checking that the index file is correctly formatted and doesn’t do outright harmful things, a good bunch is automated and reviewing can go very quickly.
However having only 3 people with the rights to merge into the index is a bottleneck, and with a sprinkle of bad luck like Alex getting sick while I’m on vacation, the review backlog can grow quite fast…