pages/guides/transitioning_asf.ad - incubator - Git at Google

 //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.
 = Initial Code Import
 Apache Incubator PMC
 2002-10-16
 :jbake-type: guide
 :jbake-status: published
 :idprefix:
 :toc:
 :imagesdir: ../images/

 For corporate contributions, the SGA or CCLA MUST be completed, submitted
 and received before the code is imported.

 For contributions composed of patches from individual contributors,
 it is safe to import the code once the major contributors (by volume)
 have completed ICLAs or SGAs.

 In either case, the code to be imported should be attached to a JIRA
 and then imported. It is recommended that the previous version
 control system is tagged so that the imported version is precisely known.

 A public record MUST be made of the code imported. If the import is not
 attached to JIRA then it MUST be committed to version control.

 == Importing History

 The incoming code can either be committed as a snapshot or as a complete version
 control export including history (provided that the import is available in a format
 readable by subversion).
 Importing with history allows existing open source projects who want to maintain
 older versions at Apache to easily perform source diffs and so on. Import just the
 latest code allows a clean break to be made with the past. The choice is left to
 the community of the incoming project.

 The infrastructure team will perform the import including
 mapping IDs but it is an operation that requires skill, time and care. In this case,
 please ask the infrastructure team politely.

 If you are importing from a github repository, you'll need to add one of our infra staff members as an admin to perform a move.

 == Audit Cryptography

 Before the code base is committed into an Apache repository, the contribution
 link:http://www.apache.org/dev/crypto.html[MUST] be checked
 and any restricted cryptography reported appropriately. Read and follow
 link:http://www.apache.org/dev/crypto.html[this guide].

 == Initial Clean Up

 Once a JIRA has been created, the source should be cleaned up.

 - Ensure source files use the standard Apache boilerplates. This may mean replacing existing license headers. The tools in link:https://svn.apache.org/repos/private/committers/tools[private/committers/tools] and link:https://svn.apache.org/repos/private/committers/relicense[private/committers/relicense] may be useful.
 - Ensure that NOTICE and LICENSE documents are present and correct.  Mentors should assist with this.
 - Add any required notices. Consider moving copyright attributions from source documents to the NOTICE. Read link:http://www.apache.org/legal/src-headers.html[Apache policy on headers].
 - Audit the source for any potential licensing issues. Any which are found should either resolved immediately (when required) or noted in the status document for later.


 It is recommended that the initial clean up be is started
 before the code is committed. It MUST be completed before any
 releases are cut.

 == Clean Up Best Practice

 It is recommended that version control is used to create a
 public record of the process. This will assist anyone
 auditing the code provenance (now or in the future) to
 easily perform due diligence without contacting the people
 who performed the clean up. The clean up process should
 therefore clearly document (using version control) the
 evolution of the IP licensing.

 Particular care needs to be taken with commit messages
 during clean up. The intended audience needs to include
 lawyers and code auditors. Members of the public need to be
 able to follow and understand the process from these
 messages alone.

 It is therefore recommended that the initial source is
 (after being expanded from the archive) checked in as is
 into a special directory (*${project}/trunk/import* is suggested). The original packaging, copyright statements
 and license notices should be preserved. A standard Apache
 LICENSE and appropriate NOTICE should be added at the top
 for the copyright for the collective work (see link:http://www.apache.org/legal/src-headers.html[policy]). Take particular care with this commit message. As with
 any patch that contains code which is not the original work
 of the committer, the JIRA url (for the artifact imported)
 needs to be included together with notes about the original
 copyright owner and any associated paperwork. The fact that
 this is a exact import including original headers should be
 noted to stop any queries about these foreign headers.

 The cleanup should then proceed in a number of commits. If
 the source provenance is complex, break the process up into
 a number of logical steps committing each in turn with a
 good message.

 In particular, take care when relocating copyright
 statements and license notices into the NOTICE in the root
 directory: consider moving each copyright owner individually
 so that it is easier to audit. (See link:http://www.apache.org/legal/src-headers.html#notice[policy].)

 Once a section of code has been cleaned up
 (and link:#repackaging[repackaged], if necessary) normal development can begin.

 == On Repackaging

 It is recommended - but not mandated - that source is repackaged
 under the Apache namespace. There is no need to use the incubator
 namespace. For example, Java source might be repackaged to
 *org.apache.foo.Bar* or a DTD to *http://podling.apache.org/foo/bar*.

 Existing open source projects moving to Apache may well need to consider
 carefully how they will approach this transition.

 == Update Documents

 Check the documentation for references to the old home of the project and update them
 with references to Apache.

 Read
 link:http://incubator.apache.org/guides/branding.html[Branding Guide].
 Ensure that appropriate disclaimers are added to the appropriate documentation.
 Consider adding a *DISCLAIMER* text document.

 === Update Build

 If the project uses link:http://maven.apache.org[Apache Maven], the pom will
 need to be updated to reflect that the project is now at Apache. In particular:
 - Update *mailingLists*
 - Update *organization*
 - Update *url*
 - Update *issueManagement*
 - Check *licenses*
 - Update *scm*
 - Update *groupId*
 - Update *manifestEntries*. It is recommended that the
 standard Apache settings are used
 - Update *developers* to use apache IDs (when known)
 - Update *distributionManagement*
 - Consider specifying a link:http://maven.apache.org/pom.html#relocation[relocation]

 If the project uses link:http://ant.apache.org[Apache Ant], the build script
 will probably need to be updated. In particular:
 - Ensure any MANIFESTs generated refer to Apache. It is recommended that the standard Apache settings are used.
 - Check that *LICENSE*, *NOTICE* and - if appropriate - *DISCLAIMER* documents are copied into binary artifacts

 == Issue Tracking Transition

 Issues for Apache projects should be tracked on Apache hardware. Some projects arrive
 with existing issues tracking. So, in the end these need to be replaced (for new development
 at least) by the Apache issues tracker. Options need to be discussed publicly on list
 and a consensus reached about the best transition strategy.
	//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.
	= Initial Code Import
	Apache Incubator PMC
	2002-10-16
	:jbake-type: guide
	:jbake-status: published
	:idprefix:
	:toc:
	:imagesdir: ../images/

	For corporate contributions, the SGA or CCLA MUST be completed, submitted
	and received before the code is imported.

	For contributions composed of patches from individual contributors,
	it is safe to import the code once the major contributors (by volume)
	have completed ICLAs or SGAs.

	In either case, the code to be imported should be attached to a JIRA
	and then imported. It is recommended that the previous version
	control system is tagged so that the imported version is precisely known.

	A public record MUST be made of the code imported. If the import is not
	attached to JIRA then it MUST be committed to version control.

	== Importing History

	The incoming code can either be committed as a snapshot or as a complete version
	control export including history (provided that the import is available in a format
	readable by subversion).
	Importing with history allows existing open source projects who want to maintain
	older versions at Apache to easily perform source diffs and so on. Import just the
	latest code allows a clean break to be made with the past. The choice is left to
	the community of the incoming project.

	The infrastructure team will perform the import including
	mapping IDs but it is an operation that requires skill, time and care. In this case,
	please ask the infrastructure team politely.

	If you are importing from a github repository, you'll need to add one of our infra staff members as an admin to perform a move.

	== Audit Cryptography

	Before the code base is committed into an Apache repository, the contribution
	link:http://www.apache.org/dev/crypto.html[MUST] be checked
	and any restricted cryptography reported appropriately. Read and follow
	link:http://www.apache.org/dev/crypto.html[this guide].

	== Initial Clean Up

	Once a JIRA has been created, the source should be cleaned up.

	- Ensure source files use the standard Apache boilerplates. This may mean replacing existing license headers. The tools in link:https://svn.apache.org/repos/private/committers/tools[private/committers/tools] and link:https://svn.apache.org/repos/private/committers/relicense[private/committers/relicense] may be useful.
	- Ensure that NOTICE and LICENSE documents are present and correct. Mentors should assist with this.
	- Add any required notices. Consider moving copyright attributions from source documents to the NOTICE. Read link:http://www.apache.org/legal/src-headers.html[Apache policy on headers].
	- Audit the source for any potential licensing issues. Any which are found should either resolved immediately (when required) or noted in the status document for later.


	It is recommended that the initial clean up be is started
	before the code is committed. It MUST be completed before any
	releases are cut.

	== Clean Up Best Practice

	It is recommended that version control is used to create a
	public record of the process. This will assist anyone
	auditing the code provenance (now or in the future) to
	easily perform due diligence without contacting the people
	who performed the clean up. The clean up process should
	therefore clearly document (using version control) the
	evolution of the IP licensing.

	Particular care needs to be taken with commit messages
	during clean up. The intended audience needs to include
	lawyers and code auditors. Members of the public need to be
	able to follow and understand the process from these
	messages alone.

	It is therefore recommended that the initial source is
	(after being expanded from the archive) checked in as is
	into a special directory (${project}/trunk/import is suggested). The original packaging, copyright statements
	and license notices should be preserved. A standard Apache
	LICENSE and appropriate NOTICE should be added at the top
	for the copyright for the collective work (see link:http://www.apache.org/legal/src-headers.html[policy]). Take particular care with this commit message. As with
	any patch that contains code which is not the original work
	of the committer, the JIRA url (for the artifact imported)
	needs to be included together with notes about the original
	copyright owner and any associated paperwork. The fact that
	this is a exact import including original headers should be
	noted to stop any queries about these foreign headers.

	The cleanup should then proceed in a number of commits. If
	the source provenance is complex, break the process up into
	a number of logical steps committing each in turn with a
	good message.

	In particular, take care when relocating copyright
	statements and license notices into the NOTICE in the root
	directory: consider moving each copyright owner individually
	so that it is easier to audit. (See link:http://www.apache.org/legal/src-headers.html#notice[policy].)

	Once a section of code has been cleaned up
	(and link:#repackaging[repackaged], if necessary) normal development can begin.

	== On Repackaging

	It is recommended - but not mandated - that source is repackaged
	under the Apache namespace. There is no need to use the incubator
	namespace. For example, Java source might be repackaged to
	org.apache.foo.Bar or a DTD to http://podling.apache.org/foo/bar.

	Existing open source projects moving to Apache may well need to consider
	carefully how they will approach this transition.

	== Update Documents

	Check the documentation for references to the old home of the project and update them
	with references to Apache.

	Read
	link:http://incubator.apache.org/guides/branding.html[Branding Guide].
	Ensure that appropriate disclaimers are added to the appropriate documentation.
	Consider adding a DISCLAIMER text document.

	=== Update Build

	If the project uses link:http://maven.apache.org[Apache Maven], the pom will
	need to be updated to reflect that the project is now at Apache. In particular:
	- Update mailingLists
	- Update organization
	- Update url
	- Update issueManagement
	- Check licenses
	- Update scm
	- Update groupId
	- Update manifestEntries. It is recommended that the
	standard Apache settings are used
	- Update developers to use apache IDs (when known)
	- Update distributionManagement
	- Consider specifying a link:http://maven.apache.org/pom.html#relocation[relocation]

	If the project uses link:http://ant.apache.org[Apache Ant], the build script
	will probably need to be updated. In particular:
	- Ensure any MANIFESTs generated refer to Apache. It is recommended that the standard Apache settings are used.
	- Check that LICENSE, NOTICE and - if appropriate - DISCLAIMER documents are copied into binary artifacts

	== Issue Tracking Transition

	Issues for Apache projects should be tracked on Apache hardware. Some projects arrive
	with existing issues tracking. So, in the end these need to be replaced (for new development
	at least) by the Apache issues tracker. Options need to be discussed publicly on list
	and a consensus reached about the best transition strategy.