I have been asked quite often recently “what is some ways I can contribute to Arch Linux?”. And the usual answers apply – package for the AUR, contribute to the wiki, help out on the forums and IRC… All useful to the whole community, but being not selfless at all I really want people to help in a way that helps me! So here are some ideas:
#1 – Fix Bugs on the Bug Tracker
This is not a new suggestion either… but it is an area that I think most people could contribute. I would say that there is some things that can be done to reduce the work for the developer that they are assigned to for the majority of bug reports in our tracker. For example:
- Check that you can (still) replicate the bug. If you can, do not post “ME TOO!” as a comment. Just add a vote. Unless of course you can provide more information.
- Summarize links to external reports. I hate bugs that are reported with just a link to a forum post or another bug tracker that requires me to read pages of posts to get at the issue. A brief summary of how to replicate is very useful.
- For upstream bugs, make sure they are reported upstream. Provide the link to the upstream bug report or mailing list, etc.
- If upstream has a patch for the issue, test it. If it works, provide the updated PKGBUILD and patch in the bug tracker, making sure a there is a comment in the PKGBUILD about where the patch came from.
#2 – Ensuring Continuously Buildable Arch
Arch rolls along a breakneck speed and quite often a package that was built a few weeks ago will no longer build from ABS. Then we get bug reports in the form “foo does not build”. In fact, most of those bug reports do not even provide build error (stupid users…)! These bugs particularly annoy me because I really dislike ABS in its current form. However, having packages that always build is very helpful when we do rebuilds due to library soname bumps or some change in packaging policy.
What I would propose is forming a group of people who in some way are continuously rebuilding Arch packages. That should be easy to script with the use of our devtools scripts. Any time a package no longer builds, the issue is investigated, reported upstream (if needed) and a fixed PKGBUILD is posted on the bug tracker. That way the developer only needs to quickly scan the updated PKGBUILD, confirm the fix is good, and push the rebuild to the repos.
#3 – Forming an Arch Security Team
Currently, Arch has a rather ad-hoc approach of dealing with security issues. This is because the majority of security fixes result in a new version of software being released, so we get them quickly with an update anyway. Also, developers tend to follow the mailing lists of the software they maintain. However, Arch could benefit from team who keep track of new security issues and make sure our packages get fixed. It would be worth doing a review of the current package situation too…
There was a project called “Arch Sheriff” a while ago that attempted to do this. However, I think it failed for two main reasons. It required the developers to go to an external website to check if their packages were vulnerable and, to a much lesser extent, it required them to go find the upstream fixes. A much better approach would be for the security team to interact with the developers through the bug tracker, providing fixed PKGBUILDs that include links to the issue and the upstream fix as comments.
#4 – Buy Allan Beer
On second thoughts, that probably hinders rather than helps…
For ideas #2 and #3, there will be some groundwork needed to get this underway. I guess using IRC, the wiki and mailing-lists should be enough for organizing how they will be run. I would not be directly involved in any of those ideas (they are suppose to free up my time!) but can advise and provide a middle man to the developers if needed. Continuously building packages for idea #2 would also require computing resources, but I guess that could be spread across people in the group.
So what are you waiting for? Get doing stuff!
Hi, you mentioned that “I really dislike ABS in its current form”. I am interested what exactly do you dislike. How it is possible to improve ABS?
I do not like ABS because its lack of automation. Currently if I want to build a package with a patch applied I need to stick it in IgnorePkg in pacman.conf and manually update it. I know tools are available to help this, but by manually I mean in a separate command from pacman.
What I would like is to add source packages built using “makepkg –source” to the repo database, which can be downloaded with pacman (something like “pacman -Bd pkg”). From there we can work on getting pacman to update these built from source packages.
I seem to recall proposing an almost identical solution for #3 several years ago. The response I got from the Arch developers and community was lukewarm to say the least. I proposed creating an Arch Security mailing list. This was turned down and I was told to speak the Arch Server guys. So in the end I gave up due to this and some other real life issues unrelated to Arch. If there was official endorsement from the Arch developers I may be interested in participating in an Arch security team.
The response you got from Arch developers was positive. Users not so much, but users are stupid.
And despite my repeated asking [1,2], no-one ever did see just how many issues remain unfixed in our repos to see the extent of the issue. As I posted, I think the number of known issues is limited due to the quick updates, but it is non-zero.
Also, much of your focus was getting a mailing list and a name for the group. I never saw a single bug report about an issue needing fixed. And once you moved to talking to the Arch Server guys the relevance to Arch Linux disappeared because they ran entirely different package versions than we did.
[1] https://mailman.archlinux.org/pipermail/arch-general/2010-March/012099.html
[2] https://mailman.archlinux.org/pipermail/arch-general/2010-March/012093.html
(For people that are interested, most discussion happened between 2010-01 and 2010-06 on the arch-general mailing list.)
Can you suggest how to go about build packages, in a coordinated fashion i.e. beyond just grabbing package-of-the-day from core or extra?
The work has to be spread out to preserve resources and avoid duplication. If the work module is available as group of packages or meta-packages, that could be distributed among volunteers. A single script that builds set of packages could then be run from cron.
Also somebody would need to prioritize which packages are more important/more prone to breakage etc.
This is a good question… Personally, I would start with the [core] repo and build up from there.
As how to organize a team to work together on this, that will require some groundwork. I’d guess there would need to be a system that has a queue of packages to test. Somehow a member of the team would be given a package to build and then report back the result (success/fail). A failure would be repeated by another member and then flagged for review and fixing.
I guess we need some web service running to allow the continual package assignment, building and reporting to be automated from the builders perspective. I am not sure about these things, so this is making stuff up as I go here… but it could be an email service. A member sends a PGP signed email to an address with a specific subject. The email is responded to including the name of a package (group) to build. A reply is sent with success/fail.
Queue priority would need figured out, but i guess it should be based on the number of packages that depend on a given package and when it last went through the queue. I could come up with a good algorithm for this if someone figured out the automation above.
With regard to the automation side of things, those of us over on the ARM side are getting that down to a science. I’m continually improving our system, more so now since I currently have more free time, and from just going over an implementation plan in my head it doesn’t seem like it would be too much to add a continuous integration system just to test builds and report the status. I haven’t added in anything yet for building x86 packages, but adding new architectures to the system is pretty easy. If this is something you might want to explore, feel free to shoot me an email.
Thanks. I will keep your system in mind when (hopefully) someone decides this would be a good idea to take up.
WIth regards to number 1, why not bring back the Bug Days? We used to have them every month and they were great for general cleaning and improving the quality of bugs.
Also good for community involvment, though you might want to have a dedicated TU/dev for orientating new folk. (Yes, I am offering to do that.)
I would be happy to bring back bug days. But the last few really did not bring any community (or devs and TUs for that matter…).
Send a message to arch-dev-public to set one up.