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.

Graduating as New Top Level Project

When graduating to a new project, the process is more complex. Creating a new project requires a resolution to be passed by the Board. 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 resolution will appoint a Chair for the new project. 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.

Once appointed, the new Chair needs to:

They should then be able to start assembling the new PMC. The starting membership is listed in the resolution. However, the Chair of the new project needs to ensure that private list is created and the membership subscribed.

Members of the new PMC need to: - Subscribe to the private mailing list for the project, if they weren’t already subscribed from their PPMC days - Review appropriate documentation: Apache PMC Guide Related documentation

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

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

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.

    • Update the Incubator status page to denote the project as "graduating" when you commence, then as "graduated" when you are finished. The notes below will assist.

  • Source

    • Git repositories will be renamed to drop the incubator- prefix, please ensure that developers change their remotes. After you’ve created the TLP request, request the rename.

    • 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

  • Mailing lists

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

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

    • 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

    • Raise an infra ticket to create your dist area and move your Incubator dist area to 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 examples of other recent graduates. At the beginning of the process, add the "graduating" element. When finished the graduation process, then: * Change the podling status to "graduated"; * add the "enddate" attribute to document when the project graduated; * add the "resolution" element (see other project examples); * remove the "graduating" 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.