//Licensed under the Apache License, Version 2.0 (the "License");
//you may not use this file except in compliance with the License.
//You may obtain a copy of the License at
//
//http://www.apache.org/licenses/LICENSE-2.0
//
//Unless required by applicable law or agreed to in writing, software
//distributed under the License is distributed on an "AS IS" BASIS,
//WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
//See the License for the specific language governing permissions and
//limitations under the License.
= Transferring Resources out of the Incubator
Apache Incubator PMC
2002-10-16
:jbake-type: guide
:jbake-status: published
:idprefix:
:toc:
:imagesdir: ../images/
:icons: font 

== 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 link:/guides/roles_and_responsibilities.html#incubator_project_management_committee_ipmc[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
link:/guides/roles_and_responsibilities.html#chair_of_the_incubator_pmc[IPMC Chair] and the Chair of the project accepting the
graduating community organize the handover between
themselves.

==== 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
link:graduation.html#preparing_a_charter[resolution]
to be passed by the link:http://www.apache.org/foundation/board/[Board].
You may look at older minutes from the link:http://www.apache.org/foundation/board/calendar.html[calendar] and check for "Establish ProjectName".
link:https://whimsy.apache.org/board/agenda/[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
  link:http://www.apache.org/foundation/[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.

WARNING: 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:

- Subscribe to the *board* mailing list
- Ensure that they have been added to
link:https://people.apache.org/phonebook.html?service=pmc-chairs[the PMC chairs group (pmc-chairs) in LDAP].

WARNING: 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.

- Check out the link:https://svn.apache.org/repos/private/foundation/officers[*foundation/officers*] folder from the private repository.
Users with member or pmc-chairs karma can do this.
- Add yourself to the #foundation/officers/affiliations.txt# file with the appropriate information.
- Add your details to the foundation web site Officer list at link:http://www.apache.org/foundation/index.html[http://www.apache.org/foundation/index.html] (in SVN at link:https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/[https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/])
- Review appropriate documentation:
** link:http://www.apache.org/dev/pmc.html#chair[PMC Chair Duties]
** PMC link:http://www.apache.org/dev/#pmc[documentation]
** Incubator link:http://incubator.apache.org/guides/chair.html[Chair guide]
** Reporting link:http://www.apache.org/foundation/board/calendar.html[calendar]
- Understand the reporting schedule with the link:/guides/roles_and_responsibilities.html#board[Board]. For
the first three months after graduation this will
be monthly. After that, the project should slot
into a quarterly reporting schedule. Now is a good time to remove
the project from the Incubator reporting schedule by updating the podlings.xml file. See link:/cookbook/podlings-xml.html[Podling XML Examples].
- Ensure the PMC is added to the committee-info.txt file at https://svn.apache.org/repos/private/committers/board/committee-info.txt
There are 3 sections which need to be updated; see instructions in the file, otherwise update it in link:https://whimsy.apache.org/roster/[Whimsy's Roster Tool]
You may need to get a member to help with this, such as your mentors.
- They should then be able to start assembling the new
link:http://www.apache.org/foundation/how-it-works.html#structure[PMC].
The starting membership is listed in the
link:graduation.html#preparing_a_charter[resolution]. However, the Chair of the new project
needs to ensure that private list is created and the
membership subscribed.

===== 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:
** Apache link:http://www.apache.org/dev/pmc.html[PMC Guide]
** Related link:http://www.apache.org/dev/#pmc[documentation]

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

IMPORTANT: 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

IMPORTANT: 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
link:http://www.apache.org/dev/infra-contact#requesting-graduation[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 link:#notes-status[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 link:http://incubator.apache.org/projects/index.html[status page] to denote the project as "graduating" when you commence,
then as "graduated" when you are finished. The notes link:#unincubate[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
** 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 link:http://www.apache.org/dev/committers.html#mail-moderate[this] and the link:http://www.ezmlm.org/[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 link:http://www.apache.org/dev/committers.html#mailing-list-moderators[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.
+
NOTE: 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 examples of other recent graduates.  At the beginning of the process, add the "graduating" element.

- When finished with the graduation process, see link:/cookbook/podlings-xml.html[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
link:/guides/roles_and_responsibilities.html#incubator_project_management_committee_ipmc[Incubator PMC (IPMC)]
was responsible to the
link:/guides/roles_and_responsibilities.html#the_board[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
link:http://www.apache.org/foundation/how-it-works.html#structure[PMC]
to work with the link:https://www.apache.org/security/committers.html[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 link:lists.html#general+at+incubator.apache.org[general] list.