Tom Lord's
Software

Joining the Arch Community

Some advice and links for those who'd like to help develop arch or interact with those who do.

Gnu Arch

Support Services
(coming soon...)

  • Per Incident
  • Subscription
  • Deployment Services
  • Custom Development

Products
(coming soon...)

  • Deluxe Distributions
  • Documentation
  • Schwag

Alternative/Regional Providers
(coming soon...)

Gnu Arch is a fairly traditional free software project. Contributors are widely scattered, geographically. Discussions among contributors usually takes place on a public mailing list or IRC channel. At this time, developer discussions and user discussions take place on the same mailing list (see the "Mailing List" link in the box at left): developers often pitch in to help users with their questions; users often suggest feature ideas to developers.

Like most free software projects, anyone can offer to contribute code. Potential contributors whose offers are a good fit for what is needed, and who do their best to work with the existing (mostly informal) processes are likely to receive the most attention. Potential contributors whose offers are consistently inappropriate (for whatever reason) are likely to be neglected.

If you have or would like to make a contribution that is more than a trivial bug-fix you are strongly encouraged to discuss what you'd like to do first, on the mailing list. More experienced developers can help make sure that you don't waste your or our time working on something inappropriate.

An irc channel, #arch hosted by irc.freenode.net often (but not always) includes some experienced developers who can help with quick questions.

Basic Coordinates

The revision-controlled "mainline" sources for arch can be found at:
archive name lord@emf.net--2004
archive locations http://arch.quackerhead.com/~lord/archives/lord@emf.net--2004
http://regexps.srparish.net/{archives}/lord@emf.net--2004
top-level project dists--devo--1.0
buildcfg name configs/emf.net/devo.tla

Useful Links

mailing list http://mail.gnu.org/mailman/listinfo/gnu-arch-users
Bug Tracker http://bugs.gnuarch.org
Community Wiki http://wiki.Gnuarch.org/
The supermirror http://www.sourcecontrol.net

Coding Standards and APIs

Code for arch should be formatted and expressed in the style of code that is already there. For example, braces occur on their own line; indentation is by two spaces per level. The easiest way to learn the conventions is to follow the example of the existing code. Please pay attention, if a patch of yours is accepted, to any formatting changes we make when merging it.

Arch makes heavy use of the Hackerlab C library for which a reference manual is distributed with the arch source code (src/docs-hackerlab). For example, we don't use stdio, we don't directly use malloc, and we don't use the libc string functions. Once again, examining existing code seems to be the best way to learn.

Use Arch

For anything but the most trivial patches, it is almost a requirement that you publish your changes in the form of a public arch archive from which we can then merge. If you don't know how to do that yet, probably it is too early for you to be contributing. If you can't otherwise arrange hosting space for your archive, ask on the gnu-arch-users mailing list and perhaps someone can help you.

Use BugGoo

If you have a change ready to be merged, send a message to the gnu-arch-users mailing list with the string [MERGE REQUEST] in the subject line. The body of the message should describe the change and, most importantly, contain information about the location of your archive and the location within your archive of the change.

Be Patient

It's a common experience for both new and experienced developers to receive a reply to a merge request asking for some revisions to the change. You should plan for this.

Tom's in Charge

The arch project is not a democracy. It's not one of those projects where contributors vote "+1/-1/0" to decide what happens to the program. Instead, arch is a gatekeeper-based project (sometimes also called a benevolent dictator project).

Tom is the final arbiter of what code goes into arch -- he's the gatekeeper at the top of the gatekeeper tree. For the most part, this seems to work out pretty well -- he can be strict about code that will not go in but he usually has pretty good reasons.

When he has the time, Robert Collins sometimes acts as a "trusted lieutenant" -- meaning that he will review and merge people's contributions into a branch of his, from which Tom merges them into the main development version.

If Tom is away, for some reason, and an emergency release is required (such as to fix a security alert), James Blackwell is in charge.

Pay it Forward

New contributors who become sustained contributors generally receive a lot of help, in small increments, along the way. Should you become a sustained contributor, please return the favor by helping new contributors who follow you.

Copyright 2004, Thomas Lord (lord@emf.net)