| //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, you MUST complete and submit the SGA or CCLA, and Apache must receive it, before you import code. |
| |
| 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, attach the code to be imported to a JIRA ticket and then import it. We recommend that you tag the previous version |
| control system so we know the precise version you are importing. |
| |
| You MUST make a public record of the code you import. If you do not attach the import to a JIRA ticket, you MUST committed it to version control. |
| |
| == Importing History |
| |
| You can commit the incoming code as a snapshot or as a complete version |
| control export, including history (provided that the import is available in a format |
| readable by Github or Subversion, depending on where the new repository is). |
| Importing with history allows existing open source projects that want to maintain |
| older versions at Apache to easily perform source diffs and so on. Importing 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. |
| |
| == Audit Cryptography |
| |
| Before you commit the code base 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 you have created a JIRA ticket, it is time to clean up the source code. |
| |
| - Ensure source files use the standard Apache boilerplate headers. 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 file. Read the link:http://www.apache.org/legal/src-headers.html[Apache policy on headers]. |
| - Audit the source for any potential licensing issues. Resolve any issues you find immediately or note them in the status document for later attention. |
| |
| |
| We recommend that you start the initial cleanup before you commit the code. You MUST complete it before creating any |
| releases. |
| |
| == Clean Up Best Practice |
| |
| We recommend that you use version control to create a |
| public record of the cleanup process. This will assist anyone |
| auditing code provenance (now or in the future) to |
| easily perform due diligence without having to contact the people |
| who performed the cleanup. The cleanup process should |
| therefore clearly document (using version control) the |
| evolution of the IP licensing. |
| |
| Take particular care with commit messages |
| during cleanup. 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. |
| |
| We therefore recommend that, after you expand the initial source from the archive) you check it into a special directory (we suggest *${project}/trunk/import*) as is. This will preserve the original packaging, copyright statements |
| and license notices. Add the standard Apache |
| LICENSE and an appropriate NOTICE 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, you need to include the url of the Jira ticket (for the artifact imported), together with notes about the original |
| copyright owner and any associated paperwork. Note that this is an exact import including original headers, 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 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 you have cleaned up (and link:#repackaging[repackaged], if necessary) a section of code, normal development on it can begin. |
| |
| == On Repackaging |
| |
| We recommend - but do not require - that you repackage source code |
| under the Apache namespace. There is no need to use the incubator |
| namespace. For example, you might repackage Java source code to |
| *org.apache.foo.Bar* or a DTD to *http://podling.apache.org/foo/bar*. |
| |
| Existing open source projects moving to Apache may 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 the Apache link:http://incubator.apache.org/guides/branding.html[Branding Guide]. |
| Add appropriate disclaimers to the appropriate documentation. |
| Consider adding a *DISCLAIMER* text document. |
| |
| === Update Build |
| |
| If the project uses link:http://maven.apache.org[Apache Maven], you need to update the pom 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*. We recommend that you use the standard Apache settings |
| - 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. We recommend that you use the standard Apache settings. |
| - Check that *LICENSE*, *NOTICE* and - if appropriate - *DISCLAIMER* documents are copied into binary artifacts |
| |
| == Issue Tracking Transition |
| |
| We track issues for Apache projects on Apache hardware. Some projects arrive |
| with existing issue tracking systems. The project needs to move, for new development |
| at least, to an Apache issue tracker. Discuss options and reach a consensus on the public dev@ email list about the best transition strategy. |