This page is meant to outline a proposed new distributed development process for Boost C++ Libraries.

Rationale

• We want to lower the barrier to entry for contributors to the Boost C++ Library. In the current centralized development process, contributors are discouraged from contributing because:
  • Patches in Trac don't get applied quite fast enough because a maintainer still has to manually do it.
  • Getting commit access to the central repository is a manual process.
  • Before anybody can typically help in the maintenance of a library, that person has to do quite a lot of work without much certainty of success, and in the end mostly is a judgment call by an original maintainer.
• We want to make including libraries into a Boost Distribution a trivial process. In the current centralized process this means moving the code into a central repository then having maintainers manually merge the changes from the main development branch (trunk) into the release branch -- this is a problem because the risk of failure is high.
• We want to increase community participation in different aspects of the project like testing, promotion, documentation, BoostCon, and standardization. At the moment there's a lot of work to be done for Boost libraries but a lot of it has not been properly identified and publicized. This is coupled with the high barrier to entry for contributors and you have only a small community of developers trying to do all the work that other non-developers may very well be able to do. With regard to standardization, there are Boost C++ Libraries that would be great to have in the ISO standard -- the effort of championing these libraries currently fall on the shoulders of just the library maintainer, which can be done by others already in the committee or someone else willing to champion that effort.
• We want to enable the Boost project to scale up to have more than one distribution. As it is at the moment there is only one Boost C++ Library distribution which contains all the accepted libraries.

Definitions

Before moving on to the specifics, we need to define a few terms we're using:

• A Contributor is a person who does at least one of the following:
  • Submit patches to library code, documentation, build systems, tests, and anything materially tangible that's considered part of a library project (logos, websites, blog entries, etc.).
  • Reports issues with the library which means she has used it in a given context and is considered a testing contribution.
  • Merges patches into the a library on his personal branch/fork of the library and runs tests locally on his system.
  • Runs regression tests for a particular Boost distribution (see distribution below).
  • Shepherds contributions in from other sources into the main library.
  • Donates money or resources to making sure that the library effort continues.
• A Distribution is a collection of reviewed and accepted libraries. There can be many different types of distributions some of which are listed below:
  • Theme-based distributions (Metaprogramming, Algorithms, Containers, etc.)
  • Layer-based distributions (Core, Utilities, Extensions)
  • Maturity-based distributions (Stable, Unstable, etc.)
• A Release Manager is a person who:
  • Pulls together published versions of the libraries in the distribution that she manages.
  • Coordinates the efforts of contributors for libraries that are part of the distribution to get a given release tested, packaged, and distributed for general availability.
  • Signs off (literally, with his GPG Key, see "Web of Trust" below) on all changes merged into a release.
• The Web of Trust system relies on:
  • Contributors having signed GPG keys and publicly available public keys who sign all their contributions as well as those they shepherd into his own branch/fork.
  • Library Maintainers who have their signed GPG keys and publicly available public keys who pull in contributions from contributors and signs off on all their changes as well.
  • Release Managers who have their signed GPG keys and publicly available public keys who sign all the changes they pull in and all the tags they define for releases.
  • The web of trust signifies:
    • If a Contributor's GPG key is signed by a library maintainer, then that contributor is eligible to become a library maintainer.
    • A Release Manager may choose to pull changes that are not library maintainer-signed in case a library maintainer is not active or not available.
    • If a Release Manager chooses to sign a Contributor's key, that makes the Contributor eligible for maintaining a library which may potentially have the original library maintainer unavailable; in this situation, a Contributor is promoted to Library Maintainer from the trust system.
    • If two or more Release Managers sign either a Contributor's or Library Maintainer's key, that makes that person eligible to become a release manager of the distribution or distributions where the signing release managers are release managers of.
    • It is preferred -- but not required -- that people sign keys only if they have met in person or that they can say with reasonable certainty that this person they're signing the keys of is actually someone they trust. It's suggested that BoostCon or local Boost User Group events be the venue where key exchanges and key signings happen.
  • A Trusted Contributor, Trusted Library Maintainer, or Trusted Release Manager is a person who has at least two peers in the same or higher level (Contributor < Library Maintainer < Release Manager) signing with high trust levels.
• An Official Boost Release is an official release that is packaged and signed by a Trusted Release Manager.
• A Review Manager is a person who:
  • Drives the Review Process (see Review Process below)
  • Is responsible in collating and maintaining a record of reviews regarding the inclusion of a Candidate Library (see Candidate Library below)
  • Is poised to be a Library Maintainer of the library under review once it is accepted
• A Review Manager Assistant is:
  • Assist the driving of the Review Process (see Review Process below)
  • Is poised to be (or is already) a Contributor to the library under review once it is accepted
• The Boost Community is the group of people who are any one of the following:
  • A Contributor
  • A Library Maintainer
  • A Release Manager
  • A Review Manager
  • A Review Manager Assistant
  • A Registered Boost User -- a listed member of the Boost Users, Boost Developers, or BoostCon mailing lists who is not any one of those already mentioned above
• A Candidate Library is a library being considered or developed for inclusion in Boost. The criteria for Candidate Libraries are:
  • The project repository is publicly available.
  • The library follows the Boost Code Guidelines.
  • The library and all artifacts are available under the Boost Software License.
  • The library has all copyrights explicitly defined.