Revision 4
At CruxCon2004, there we decided that the CLC and CRUX Projects would become more integrated, and in fact merge, in order to provide a more unified and complete product to end users. Thus, the CLC contrib ports collection would merge to CRUX opt. To further this same goal, it was proposed that a centralized repository, created with ports from willing HttpUp maintainers, be created to take the place of the aging unmaintained ports collection. This meta-repository would be automatically maintained, and inherit the familiar name contrib.
Later in 2006 we took a step further and decided to host the contrib repository directly at crux.nu, in order to provide a common platform for easier cooperation and better history tracking. In October 2006 we decided to create a Git repository which is used as the new contrib repository.
The new contrib is a Git repository, anonymously available at git://crux.nu/ports/contrib.git and browsable via the web at http://crux.nu/gitweb/?p=ports/contrib.git;a=summary. This repository is periodically updated by the system and exported to httpup and rsync locations, much like the core and opt collections. Contrib maintainers have write access to the contrib repository, you can find a brief tutorial on the ContribHowTo page.
Requirements
Rules
New application scheme
We've decided to use a new application scheme to keep the quality of the contrib repository high. This scheme does mean that you (a maintainer already in contrib or opt/core) have to spend a bit more time on Crux. We hope that every new maintainer will participate in this scheme, too.
After a new applicant mail has been sent to the mailing list, the following procedure will start: The repository of this applicant has to pass a small initial verification done by the contrib maintainer. Afterwards two randomly chosen maintainer have to check these ports very carefully and that means looking at its Pkgfiles, checking its footprint files and checking if these ports are working for you. I would say that you should spend one or two hours on doing this, so checking every single port isn't necessary of course! Once the maintainers decided on this application - yes or no - , they will submit the reply to the contrib mailing list.
Once the application is accepted, the new maintainer will receive an email with the information needed to start working on the contrib collection.
Regarding bugs
We suggest that bugs against the contrib collection are also tracked in Flyspray. You're asked to look into bugs reported by users, even if a port works for you.
Regarding accepting input
Other maintainers might have different requirements for a certain port. Please listen to them. It's never possible to follow all wishes, but often leads to no or little additional effort to make a port better or more flexible.
Regarding selection
Generally provide only ports which you have tested, and are interesting to others too (e.g. a port containing the network settings for your lan is not a good candidate for contrib). As a general rule, publish only your best ports. Don't select all by default, and then think about possible exceptions.
Regarding dependencies
Provide all packages for your ports that are not yet in core, opt, xorg or contrib. All ports in contrib should build with ports from just these four collections.
Regarding dependents
If you maintain a library which has packages depending on it, think about the consequences of a update to your port. Discuss "critical" updates on the crux-contrib mailing list before sending them to contrib.