Contributing to Bcfg2

There are several ways users can contribute to the Bcfg2 project.

  • Developing code
  • Testing pre-releases
  • Adding to the common repository
  • Improving the wiki
  • Writing documentation
  • Reporting bugs

Development

Send patches to the Bcfg mailing list or create a trac  ticket with the patch included. In order to submit a ticket via the trac system, you will need to create a session by clicking on the  Preferences link and filling out/saving changes to the form. In order to be considered for mainline inclusion, patches need to be BSD licensed. The most convenient way to prepare patches is by using git diff inside of a source tree checked out of git. The source tree can be checked out by running:

git clone git://git.mcs.anl.gov/bcfg2.git

The  web interface to the git repository or the source browser can give you an overview of the source code. For more details about the usage of the git repository, please refer to the Bcfg2 Git Howto page.

Several resources for developers exist in the wiki:

Bcfg2 is the result of a lot of work by many different people. They are listed on the contributors page.

Feel free to drop in during a code sprint if you would like to help out with some easier problems.

Testing Prereleases

Before each release, several prereleases will be tagged. It is helpful to have users test these releases (when feasible) because it is hard to replicate the full range of potential reconfiguration situations; between different operating systems, system management tools, and configuration specification variation, there can be large differences between sites.

See the TrackingDevelopmentTrunk page for a better view of changes in the prereleases.

Adding to the Common Repository

The Bcfg2 common repository is a set of portable examples that new repositories can be based on. This repo has several parts. The first is a series of group definitions that describe a wide range of client systems. The second is a set of portable bundles that have been ported to use these groups. This makes these bundles transparently portable across new client architectures.

This approach has several benefits to users

  • Configuration specification can be shared across sites where appropriate
  • This common configuration specification can be reused, allowing sites to migrate to new systems that other sites have already ported the common repository to
  • Setup of new systems becomes a lot easier.

Improving the wiki

Mail the mailing list for an account on the wiki.