Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

Proposal Sandbox Pruning

A proposal for better sandbox management emerged from discussions at ApacheConEurope2005. Here IIRC is the consensus. Hopefully, folks with better memories will dive in and correct any mistakes.

Of course, other folks are encouraged to improve the proposal but it might be better to post to commons-dev about any major changes (so it can be discussed) rather than just diving in.


The sandbox contains many components which are no longer active. This confuses users. It increases the time required to checkout the sandbox. It also makes it more difficult for folks not familiar with Commons to see that we're demonstrating oversight.

Formal Process

  1. An inactive component is any component that not had any commits made in the last six months.
  2. Any component which has been inactive is a candidate for archiving.
  3. Any inactive component can be archived by lazy consensus.
  4. A directory called dormant will be created as a child of commons.
  5. This directory will be read-only except for archiving activities.
  6. To archive a component, the component directory will be moved from the sandbox to the dormant directory (and removed from trunks-sandbox svn:externals).
  7. A component can be unarchived (back into the sandbox) by a vote.
  8. The website for the component will be retained but marked as dormant.

Social Process

Probably best to batch these together and tidy up the sandbox a couple of times a year. Probably announce dates in advance so that folks get a chance to speak up.

Though any component can be archived by lazy consensus, netiquette requires a proposal to give the chance for any committers interested in that component to reply. There is no pressing reason for haste and so an appropriate duration should be chosen for the vote.