At some point a PMC may want to join the Attic. The following defines a process to move that PMC into the Attic and gently close it down.

  1. A PMC decides to move to the Attic.
    • Conduct a discussion on the public developer list whether to dissolve the PMC. Do not conduct it on the private PMC list.
    • Consider an appeal to the user list for interested users to provide their interest in helping out more.
    • Conduct a PMC vote on the public dev list.
    • If the PMC votes to dissolve the PMC and move to the Attic, inform the board of the successful vote on board@ mailing list (linking or forwarding the 'successful' vote) and add a resolution to dissolve the PMC to the next board meeting agenda.
    • If the PMC can't get enough people to vote to dissolve the PMC (and there are not three -1 votes), then that is grounds for moving to the Attic. They should inform the board as above, noting that the vote failed to get enough votes.
  2. If the board approves the resolution, open an Attic JIRA item - 'Move ${project} to the Attic'.
    The Attic PMC will step in and create a detailed issue description using, with other generated parts to move the project to the Attic.
    Generated issue content typically contains following steps (see "How to" below for a description of each step):
    1. # Confirm Board Resolution
    2. # Inform users of the move to the Attic
    3. # Create project page on Attic site:$project.html
    4. #Update the project DOAP files (if any) or copy to projects-override
    5. # Announce on announce at
    The Attic PMC will then execute the steps: getting help from terminating project is welcome, particularly on informing users step or any other useful action at project's level like modifying DOAP.
  3. Open an Infrastructure JIRA issue identifying the resources that need turning off/making read only.
    The Attic PMC will create a base issue description using
    Typically, it contains steps like following, that need to be tweaked based on assets of the retired project:
    • Make source control Git|Svn read-only
    • Remove files from[release|dev]
    • Closing down of dev@, commits@ and private@ etc. mailing lists
    • Close down the user mailing list (unless still active - in which case propose a moderator to Infra)
    • Make JIRA|Bugzilla read-only
    • Make the wiki (if any) read-only
    • Delete LDAP group(s)
    • Turn off automated builds

How to: General pointers

The following are useful svn/https locations:

How to: 1. Confirm Board Resolution

Check previous Board minutes to confirm the "terminate" resolution passed. The minutes are available from the following sources:

However note that the most recent meeting minutes are not published until the following meeting at the earliest

Check that Secretary removed the PMC from

This automatically removes VP entry on and project from navigation

How to: 2. Inform users of the move to the Attic

Let the users know that the PMC is moving into the Attic. Use the following template:

A heads up for the ${project} user community that the ${project} PMC has 
been 'moved to the Attic'. This means that the ${project} developers (more 
formally its Project Management Committee) have voted to retire ${project} 
and move the responsibility for its oversight over to the Attic project.

Loosely speaking this means that the projects resources will be moved to a 
read-only state.

You can read more about the Apache Attic and the process of moving to the 
Attic at

You can follow this process in JIRA:${#}


${Name} on behalf of ${project} + the Attic.

Remember to subscribe to the user list: use Whimsy Mailing List Self-subscription to avoid moderation (if the project hasn't been removed yet).

Also bear in mind that the user mailing list may already know and you can skip this stage, or you can get help from project having asked to move to the Attic. Make sure you read that thread if it does exist.

How to: 3. Create project page on Attic site:${project}.html

The Attic website is built using Anakia. Anakia is an old site technology built on top of Apache Velocity. You can get the source for the site from Subversion:

svn co

You can generate the required changes using the Python3 script as follows:

./ id1 [id2...]

This should generate the following files for each ID, as well as updating xdocs/stylesheets/project.xml:

  • ID.jira.tmp
  • xdocs/flagged/ID
  • xdocs/projects/ID.xml
  • cwiki_retired/WIKI_ID.txt

N.B. The code does not (yet) allow for wiki aliases. For example, eagle used EAG as the wiki name.

Review the changes in xdocs/, then commit to svn.

The ID.jira.tmp file is text that can be copy-pasted into a JIRA description. It should be deleted after use, and not committed to SVN

The buildbot job will build the site and commit the result which will be published soon after

How to: 4. Update the project DOAP file (if any):${project}

The files referenced are in, which every Apache committer can update.

Identify whether the project has a DOAP file (see the <comdev repo>/ file if update the rdf file with PMC to the Attic and add a category of retired:

pmc change:    <asfext:pmc rdf:resource="" />
new category:  <category rdf:resource="" />

You can use script/ to prepare the update that you'll just need to review and commit

How to: 5. Announce on

Announce that the project is now retired. Consider the following template.

Sometimes, the user mailing list will not be shut down. If that is the case, it should be mentioned in the announce. e.g. add "The user mailing list remains open." after "change in url." below.

Announcing that the Apache ${project} committers have voted to retire
the project due to inactivity. ${project} was {boilerplate}.

Retiring a project is not as simple as turning everything off, as
existing users need to both know that the project is retiring and
retain access to the necessary information for their own development

You can read more about ${project}'s retirement at:${project}.html

The project's resources will continue to be available in a read-only state -
website, mailing lists, wikis, git, downloads and bug tracker with no 
change in url.

Providing process and solutions to make it clear when an Apache
project has reached its end of life is the role of the Apache Attic,
and you can read more about that at:


on behalf of the Apache Attic and the now retired Apache ${project} project

It's important to include the boilerplate from the project's site so people know what we're talking about.