/
transitioning_asf.ad
142 lines (110 loc) · 7.03 KB
/
transitioning_asf.ad
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
//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.