- 1 Introduction
- 2 Infrastructure Projects
- 3 Packaging Projects
- 4 Web Projects
- 5 Coding Projects
This article is part of the DeveloperWiki.
This page is meant to list a lot of the projects Arch developers keep busy with. Yes, there are things to do outside of packaging. If you are interested in anything, this page should help you get in contact with the right people. If you are looking for something to do, this is always a good place to start.
Some of these projects have dedicated discussion areas, such as the release engineering and pacman development mailing lists. Other ones are less formal- some of the communication may just be person to person emails or on the arch-dev lists if it appeals to a larger crowd. Remember that if you are interested in these less-formal projects, you should let the names listed below know so they will include you on any communication regarding the project.
Primarily developer-side tools (devtools, namcap) and server-side (db-scripts) work.
Keep track of existing mirrors and ensure they are doing their job as good as possible (e.g. staying current). Ensure we have up to date contact information for as many mirrors as possible. Work on a tiered mirror system to relieve some stress from our primary rsync server.
Yeah, not only do we need a description, but some volunteers would be nice too!
Developer Communication Team
This isn't quite infrastructure, but it almost belongs here. Responsible for organizing developer meetings and making sure people attempt to be present; you newer guys might have no idea, but we used to actually schedule and have 80% of the developer staff present in IRC for 1-2 hour meetings. Responsible for any other coordination between developers, TUs, and maybe even the front page news.
Responsible for assigning bugs to package maintainers. If something is trivial and a fix can be easily made, then goes and does it. Organizes bug squishing days.
- TODO fill me out please
- (needs several people)
Responsible for communicating and determining what rebuilds will cycle through [testing] and in what order. They are probably also the people doing large portions of the rebuilds.
- Allan McRae (because my packages seem to cause big rebuilds...)
Package Review Team
Some packages in our repos receive little attention due to not being updated frequently. These need to be checked for being able to build (especially after major toolchain updates) and compliance with current packaging standards. It would be good for packages that have not been rebuilt in a long time to be rebuilt to take advantage of new optimisations.
- TODO fill me out please
Responsible for caring for those packages that no one seems to want and are being neglected. This may involve adoption by themselves or finding a foster caregiver, moving them to a willing maintainer in [community], or sending them to the AUR (or the trash).
The "I package more than the rest of you combined" Team
Because I felt bad leaving him off any list and he does a hell of a job.
This is meant to be a quick overview of the web projects we have and who works on them. For more technical details, you will want to check out the DeveloperWiki:Gudrun (web) and Category:DeveloperWiki:Server Configuration pages.
Responsible for coding and deploying the AUR.
Responsible for keeping our BBS install up to date and secure.
- Andrea Scarpino
Responsible for keeping our flyspray install up to date and secure.
Responsible for keeping the planet scripts updated and running.
- Andrea Scarpino
Responsible for keeping our wiki install up to date and secure.
Arch Linux Init Scripts
The all-important scripts that make your machine go when you turn it on
Arch Linux Release Engineering (Installer)
The Arch Linux Install Framework (AIF) and official installation ISOs
We have a program to create initrds for Arch systems.
This team is responsible for general development, including new features and bugfixes, for the package manager that is a core part of Arch. Although many people contribute patches and code, the people listed here are generally the people that will be reviewing patches and making the final say as to what gets in the codebase.
Pacman, as of September 2009, has been translated to 15 languages. The upkeep and maintenance of these translations is pretty much a job in itself, with the times immediately preceding a release being the busiest. Ideally this team is responsible for creating a translations branch when a string freeze is set, and then takes incoming translations, ensures they are valid, and merges them into their branch. When a release is not imminent, their focus may be on improving clarity and usefulness of existing messages.
- Giovanni Scafora ?