Estimated Reading Time:

Life After Graduation

Once a project has been established by the board, or a sub-project consumed by a TLP, this guide should be followed to migrate the podling from the Incubator to their own TLP.

Handover

This is the transfer of virtual resources from the care of the IPMC to the care of either the new or existing top level project taking charge of the graduating community.

Graduating as Subproject

This is the simple case. The IPMC Chair and the Chair of the project accepting the graduating community organize the handover between themselves.

You do need to update the Incubator’s podlings file. See Podling XML Examples.

Graduating as New Top Level Project

Board resolution and roster appointment

When graduating to a new project, the process is more complex. Creating a new project requires a resolution to be passed by the Board. You may look at older minutes from the calendar and check for "Establish ProjectName". Board Agenda Tool has an "Add Item" button that can be used to add the Graduation Resolution to the Board Agenda.

The Board votes on graduation resolutions at their monthly meeting. If the Board votes to pass the resolution, that then appoints the listed Project Management Committee including:

  • a Chair for the new project aka PMC Chair. The Chair will also be appointed an Officer of the Apache Software Foundation. This allows them access to official resources of the foundation as well as granting power to act on behalf of Apache within the scope of their project’s activities.

Usually once this happens, the secretary will inform the new chair. Occasionally, this will be missed: if more than 72 hours has passed since the Board meeting, it may be worth pinging the board to request confirmation.

  • the initial members of Project Management Committee aka PMC members.

PMC Chair Todo List

Once appointed, the new Chair needs to:

The ASF Secretary should do this without any action on the part of the new chair. As with above, if it has not happened within 72 hours of the resolution passing, contact the secretary to remind them.
PMC Todo List

Once appointed, Members of the new PMC need to:

  • Subscribe to the private mailing list for the project, if they aren’t already subscribed from their PPMC membership.

  • Review appropriate documentation:

Once all this is in place, resources can start to be handed over to the new project. See next section.

Please continue to hang around the Incubator and help new podlings have an easier time than you did!

First Steps Outside the Incubator

Graduation is the first step in what is hopefully a long road. There are some issues which incubation may not cover.

Transferring Resources

Starting the following steps require that the resolution was passed by the board.

When a project graduates, then the infrastructure resources (mailing lists, websites, source, etc.) need to be transferred from the Incubator to a project’s new home.

Although the below checklist is still generally useful, the infrastructure process has been streamlined, see requesting graduation. You might also want to check JIRA checklist tickets for projects that graduated in the last month or two. This process is known as "TLP Parent Request"

Checklist:

  • Update the Incubator status records

    • Like the rest of incubation, graduation is a process. Updating your status records as you progress will enable others to assist.

    • Update the podling status page. All sections should now be filled in including EXIT. Take some time to read carefully since this page forms the final public record for graduation.

  • Source

    • SVN repositories will be moved from the incubator to other locations, if you need the move done please raise an infra ticket after the TLP Parent Request.

    • Post an announcement to the development list telling everyone that the repository is about to be moved

    • Post an announcement containing instructions for developers describing how to svn switch their workspaces

    • Update site, jenkins, wikis, pom.xml and other resources to point to the new repository location.

  • Websites

    • Since podlings receive standard domains, no changes are required

    • Once graduated, your website will automatically redirect to remove the incubator subdomain

    • If you have any fully qualified links to your podling.incubator.apache.org on your website change them

  • Mailing lists

    • Mailing lists no longer need to get moved, since podlings are given standard domains.

    • If you use podling.incubator.apache.org format email addresses, please start using podling.apache.org

    • When using Maven: update pom.xml for the new mailing list address(es). Also update any documents on your website that show how to subscribe to the lists and/or find archives.

    • Check project-private mailing list membership. Mentors should be allowed to remain if they wish to do so. The subscriber list should otherwise match that on the resolution. See this and the EZMLM "Moderator’s and Administrator’s Manual".

    • Update mail addresses including:

      • confluence commit messages (see adminstration documentation)

      • issue tracking messages (see administration documentation)

      • The chair should have karma to perform these tasks.

    • Double-check that all of your lists have sufficient active moderators.

  • Issue Tracking

    • Ask infra to move the podling to its own top level category in JIRA, if using JIRA

  • Distribution mirrors

    • Dist area (dist.apache.org) release/${project} and dev/${project} folders can be created by PMC members.

      • Do not forget to copy KEYS file from release/incubator/${project} location.

      • You have two major options then:

        • you can keep incubating released artifacts at release/incubator/${project} and remove artifacts once your TLP project does their first release.

          File a JIRA under your newly JIRA ${project} space to remind to remove /dist/incubator/${project}/ after the first release in /dist/${project}/

        • you can move the last incubating released artifacts to your release/${project}, taking care that incubating stay in path (you will need to change website and mail for the new location)

Final Revision of Podling Incubation Records

When a project has finished its graduation steps, then the incubator resources need to be updated to indicate that the project is no longer incubating. Here are a few of the items that need to be done:

  • Update the svn incubator/trunk/content/projects/${project}.xml file to show the project’s status.

  • Update the podling summary metadata file, incubator/trunk/content/podlings.xml svn file. See the content/podlings.dtd and follow Podling XML Examples:

    • Change the podling status to "graduated"; (The only acceptable status are "current", "graduated", and "retired". "graduating" will make your podling disappear from several incubator pages.)

    • add the "enddate" attribute to document when the project graduated;

    • add the "resolution" element (see other project examples);

    • remove the "reporting" element.

  • After your project has finished reporting to the Incubator, then remove the "reporting" element from that podlings.xml file.

  • Ensure that other svn resources for your project have moved to your new home.

  • Review this whole graduation guide.

NOTE: Please edit this guide to add missing steps and clarifications.

New Responsibilities

Oversight

During the stay in the Incubator, the Incubator PMC (IPMC) was responsible to the Board for oversight. A graduated project must now take responsibility for its own oversight.

A project needs to ensure that its code base is clean from an IP perspective. New committers need to recruited, educated and mentored. Quality releases need to be cut. Community spirit needs to be maintained and conflicts resolved positively. Board reports need to be accurate and prompt.

Help is still available but the appropriate bodies (infrastructure, community, legal and so on) should now be approached directly.

Security

Each project needs to be able to manage security issues discovered in their code. By their nature, these issues need to be dealt with in private. These issues may either be dealt with on a separate security list or on the private list. Which list is suitable for security issues should be noted.

Volunteers need to be found from the PMC to work with the Apache security team and act as first contacts on security matters. The new project should make contact with the team soon after graduation and not wait for the first issue to be raised.

Projects should adopt a positive attitude towards security issues. It is easy to gain a poor reputation by mishandling of these issues. There are many people at Apache with considerable experience in this area so ask first.

Stay In Touch

Passing through the incubation process gives a very valuable perspective. Please help to improve the process by guiding new podlings and by developing improved policy and documentation on the general list.