incubator-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From p...@apache.org
Subject [47/51] incubator git commit: Last bits of migration done.
Date Thu, 06 Jul 2017 00:21:18 GMT
Last bits of migration done.


Project: http://git-wip-us.apache.org/repos/asf/incubator/repo
Commit: http://git-wip-us.apache.org/repos/asf/incubator/commit/62a0b9ff
Tree: http://git-wip-us.apache.org/repos/asf/incubator/tree/62a0b9ff
Diff: http://git-wip-us.apache.org/repos/asf/incubator/diff/62a0b9ff

Branch: refs/heads/master
Commit: 62a0b9ff7d423e890fc6bbb805403055754f209a
Parents: 783b434
Author: John D. Ament <johndament@apache.org>
Authored: Sat Jun 24 10:14:02 2017 -0400
Committer: John D. Ament <johndament@apache.org>
Committed: Sat Jun 24 10:14:02 2017 -0400

----------------------------------------------------------------------
 pages/guides/committer.ad             |  28 +
 pages/guides/ip_clearance.ad          |  51 ++
 pages/guides/mentor.ad                | 873 +++++------------------------
 pages/guides/podling_sourcecontrol.ad |  16 +-
 pages/guides/transitioning_asf.ad     | 161 ++++++
 5 files changed, 395 insertions(+), 734 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/incubator/blob/62a0b9ff/pages/guides/committer.ad
----------------------------------------------------------------------
diff --git a/pages/guides/committer.ad b/pages/guides/committer.ad
index 53d6332..f654287 100644
--- a/pages/guides/committer.ad
+++ b/pages/guides/committer.ad
@@ -76,6 +76,33 @@ and explain the reason to your project lists (as you can see, no need to alert t
 == Podling PMC (PPMC)
 If you are a member of your PPMC, become familiar with the link:/policy/incubation.html[Incubation Policy] and see the link:ppmc.html[Podling PMC Guide].
 
+== Orientating New Committers: Understanding Apache</title>
+
+When a committer is elected by a typical top level project, the nominator
+and other PMC members educate the new committer about Apache. In the Incubator, this
+inductive must be performed by the Mentors. This process is one of the most important
+for the long term health of a project.
+
+Apache works on the principle that discussions should happen on the most open forum
+available. Unless the matter involves a sensitive matter (such as security or
+personal issues), it should be raised on an open mailing list (typically the podling dev list
+or the incubator general list). Use of the incubator private list should be reserved
+for official notifications and sensitive topics.
+
+Mentors need to take care. During the initial bootstrapping a habit may develop
+of emailing private list. It is important to break this habit as soon as the mailing
+lists are available.
+
+Netiquette about the correct use of *cc*'s may also be difficult to
+effectively impart. During the bootstrap process there are a number of occasions
+where *cc*'s are required. The typical usage is to copy in a private
+listing to indicate that the action has the lazy permission of the committee.
+*cc*'s are very commonly used to create inefficient ad-hoc mailing lists in
+the commercial world. Except for a small number of defined processes, *cc*'s
+are frowned upon at Apache. Mentor need to encourage questions to be asked first
+on the public lists of the project then raised (if necessary) to the general
+incubator list.
+
 == Questions?
 If you have any questions, please ask on the Incubator's
 general mail list.
@@ -84,3 +111,4 @@ Don't forget to check the information at:
 - link:http://www.apache.org/dev[http://www.apache.org/dev/]
 ** it is one of the most current resources for committers.
 - link:general.html#FAQ[Incubator General FAQ]
+

http://git-wip-us.apache.org/repos/asf/incubator/blob/62a0b9ff/pages/guides/ip_clearance.ad
----------------------------------------------------------------------
diff --git a/pages/guides/ip_clearance.ad b/pages/guides/ip_clearance.ad
index f89ae00..ff5b4ca 100644
--- a/pages/guides/ip_clearance.ad
+++ b/pages/guides/ip_clearance.ad
@@ -20,6 +20,57 @@ Apache Incubator PMC
 
 == Podling IP Clearance
 
+=== Background
+
+Existing codebases need to be imported through the standard IP clearance
+process. This means that a Software Grant Agreement
+(link:http://www.apache.org/licenses/#grants[SGA])
+or Contributor License Agreement
+(link:http://www.apache.org/licenses/#clas[CLA])
+need to be submitted
+for all copyright owners. This process may take a while so it is best to
+start as soon as the podling is accepted.
+
+The acceptance of the initial codebases is approved by the
+IPMC as part of the acceptance motion. So, no vote is required by the
+PPMC. Otherwise, follow the standard IP clearance process for podlings.
+
+=== Establishing Provenance
+
+Paperwork needs to be submitted to Apache that grants a legal license on the code
+to the Apache Software Foundation.
+As a rule of thumb, if all the material contributors to the code
+are joining the podling as initial contributors, then CLAs (individual or corporate)
+are all you need. The individuals must submit the 'individual' CLA (ICLA).
+If there are employers involved who might claim
+rights in the code, then corporate CLAs (CCLAs) are needed for those employers.
+
+If, on the other hand, there are material contributors who are <strong>
+not</strong> joining the podling as initial contributors, or if there
+are additional corporate entities who can claim rights in the code,
+then SGAs are required from those individuals or corporations.
+
+The foregoing is only a rule of thumb. Generally, the mentors of a new project
+will need to consult with general@incubator.apache.org or the Apache legal team
+about the particular circumstances.
+
+It may take some time to track down all contributors. It is not necessary to
+have paperwork on file for all contributions before the code is imported.
+It may be necessary to reverse some patches and rewrite areas of code if
+contributors cannot be found or at not happy about given Apache written
+permission to use their code.
+
+No releases are possible until the provenance of all the code to be release
+has been clearly established and the relevant paperwork filed with Apache. It is
+therefore important to keep the status updated.
+
+Receipts of ICLAs, CCLAs, and SGAs are recorded by the secretary in
+the private foundation repository. Reading is restricted to members and officers
+of the foundation. If there is no officer or member available then ask on the
+general list.
+
+=== IPMC Responsibility around IP Clearance
+
 The board has charged the Incubator project with management of IP clearance for Apache.
 Instructions are link:http://incubator.apache.org/ip-clearance/index.html[here].
 

http://git-wip-us.apache.org/repos/asf/incubator/blob/62a0b9ff/pages/guides/mentor.ad
----------------------------------------------------------------------
diff --git a/pages/guides/mentor.ad b/pages/guides/mentor.ad
index 0298883..0bd3bc4 100644
--- a/pages/guides/mentor.ad
+++ b/pages/guides/mentor.ad
@@ -13,829 +13,240 @@
 Apache Incubator PMC
 2002-10-16
 :jbake-type: pmcGuide
-:jbake-status: draft
+:jbake-status: published
 :idprefix:
 :toc:
 :imagesdir: ../images/
 
 The Mentors' guide is a go-to place for information about getting a podling up and running from an infrastructure point of view.
 
-
-
-<document>
-<properties>
-<atom url="http://mail-archives.apache.org/mod_mbox/incubator-general/?format=atom">general@incubator.apache.org Archives</atom>
-<title>Projects</title>
-</properties>
-<body>
-<section id="Incubating+Project+and+Mentor+Guides">
-<title>Mentor Guide</title>
-<p>This document targets any Incubating Project member, but
+This document targets any Incubating Project member, but
 especially Mentors, who have to ensure that some things get done.
 For a general description of the role of a mentor on an incubating
 project see the
-<a href="&root-path;/incubation/Roles_and_Responsibilities.html#Mentor">Roles and Responsibilities
-</a>document.
-</p><p>
+link:/policy/roles_and_responsibilities.html#Mentor[Roles and Responsibilities]document.
+
 This guide is a descriptive and at times
 discursive document. It describes established practices.
 It is informational not normative. Policy is laid down in the
-<a href="&root-path;/incubation/Incubation_Policy.html">Incubation Policy</a>.
-</p>
-<section id='TOC'><title>Contents</title><toc/></section>
-</section>
-<section id="Overview">
-<title>Overview</title>
-<p>
+link:/incubation/Incubation_Policy.html[Incubation Policy].
+== Overview
+
 After the Podling has been accepted by the Incubator PMC, one of the mentors
-<a href="&root-path;/incubation/Incubation_Policy.html#Setting+Up+a+New+Podling">sets up</a>
-the Podling; <em>i.e.</em> adds the podling metadata, creates the initial Podling status page, and
+link:/incubation/Incubation_Policy.html#Setting+Up+a+New+Podling[sets up]
+the Podling; _i.e._ adds the podling metadata, creates the initial Podling status page, and
 either creates or requests that
-other resources (mail lists, subversion, bug tracker, <em>etc.</em>)
+other resources (mail lists, subversion, bug tracker, _etc._)
 be created.
-</p>
-</section>
-<section id="Sending+in+an+Incubation+Report">
-<title>Add to Incubation Summary file</title>
-<p>
+
+== Add to Incubation Summary file
+
 Add the podling to the podling summary file in
-the "incubator" SVN at <code>content/podlings.xml</code>
+the "incubator" SVN at *content/podlings.xml*
 (e.g. copy the entry from another podling that also has status="current")
-and see <a href="website.html">instructions</a>.
-</p>
-<p>
+and see link:website.html[instructions].
+
 Please do this step ASAP after Acceptance. Other setup procedures utilize
 this metadata.
-</p>
-<p>
-Add a 'reporting' tag (after 'description') with the attribute 'monthly="true"'
+
+Add a *'reporting'* tag (after *'description'*) with the attribute *'monthly="true"'*
 and the appropriate "group" attribute, based on the month in which  the podling
 entered incubation (1 for January, April, July, October, 2 for February, May,
 August, November or 3 for March, June, September, December). The text content
 of the 'reporting' tag must contain the initial list of reporting months,
-starting with the month after the podling entered incubation. For example:
-<code>&lt;reporting group="2" monthly="true"&gt;June, July, August&lt;/reporting&gt;</code>
+starting with the month after the podling entered incubation.  Below is an example of the final XML snippet
+
+[literal]
+----
+    <podling name="PodlingName" status="current" resource="podlingname" sponsor="Sponsor" startdate="YYYY-MM-DD">
+        <description>A description of the podling, for the status page and reports</description>
+        <reporting group="1|2|3" monthly="true">First,Second,Third</reporting>
+        <champion availid="userid">Champion Name</champion>
+        <mentors>
+            <mentor username="userid">Mentor One</mentor>
+            <mentor username="userid">Mentor Two</mentor>
+            <mentor username="userid">Mentor Three</mentor>
+        </mentors>
+    </podling>
+----
+
+An example reporting block:
+[literal]
+----
+<reporting group="3" monthly="true">June, July, August</reporting>
+----
 Once the first three reports are complete, the monthly attribute should be removed
 and the list of months removed as well.
-</p>
-<p>
+
 The first report might be
 very short. However it is better that the Incubator PMC can help to
 guide through the early setup stages.
 For more details see the
-<a href="ppmc.html#Incubator+ASF+Board+Reports">PPMC Guide</a>.
-</p>
-</section>
-<section id="Initialize+Podling+Status+Page">
-<title>Initialize Podling Status Page</title>
-<p>
+link:ppmc.html#Incubator+ASF+Board+Reports[PPMC Guide].
+
+== Initialize Podling Status Page
+
 A mentor needs to
-<a href="website.html#Edit+your+project+status+page">create the
-web page</a> that will track the project's status.
+link:website.html#Edit+your+project+status+page[create the web page] that will track the project's status.
 A mentor will also need to update it until
-<a href="ppmc.html#Project+Status+Updates">others in the
-the project's PPMC can update it</a>.
-</p><p>
+link:ppmc.html#Project+Status+Updates[others in the project's PPMC can update it].
+
 The status
 page is the incubator's record of the progress made.
 It MUST be kept update to date during incubation.
 Some of the information is available from the proposal.
 As the startup process continues and resources are
 created the status SHOULD be updated.
-</p><p>
+
 The template contains lists of actions which may be needed
 to start up a podling. All those which do not apply should
 be deleted.
-</p><p>
+
 The status page is a useful aid to workflow. Volunteers
 can use it to sign up to the various tasks and monitor their
 progress. Once the mailing lists are set up and prospective
 committers subscribe then these may be used for discussion.
-</p>
-</section>
-<section id='request-required-resources'><title>Request Required Resources</title>
-<p>
+
+=== Request Required Resources
+
 The proposal should include a list of required resources. All of these will
 require active set up. Some are created by infrastructure after an appropriate
 request, others can be set up by any IPMC members (typically mentors).
-</p><p>
+
 Mailing lists should be created first. Other resources typically
 post information to these lists.
-</p>
-<section id='request-mailing-lists'><title>Request Mailing Lists</title>
-<p>
+
+==== Request Mailing Lists
+
 Apache mailing lists require volunteer moderators. New moderators can be
-<a href='http://www.apache.org/dev/committers.html#mailing-list-moderators'>changed later</a>
+link:http://www.apache.org/dev/committers.html#mailing-list-moderators[changed later]
 but at least one volunteer is required before the mailing lists can be set up.
 Moderation is a reasonably
-<a href='http://www.apache.org/dev/committers.html#mail-moderate'>easy task</a>
+link:http://www.apache.org/dev/committers.html#mail-moderate[easy task]
 though moderators may want to set up
-<a href='http://spamassassin.apache.org/'>spam filtering</a>.
+link:http://spamassassin.apache.org/[spam filtering].
 Having at least three moderators is recommended to spread the load.
-</p><p>
+
 The proposal should contain the rest of the information that needs to be collected
 before the mailing lists can be requested. Incubator is the responsible top level project.
-So the domain <code>MUST</code> be <code>incubator.apache.org</code>.
+So the domain *MUST* be *incubator.apache.org*.
 For example:
-</p>
-<ul>
-<li>dev@${podling}.incubator.apache.org</li>
-<li>commits@${podling}.incubator.apache.org</li>
-<li>private@${podling}.incubator.apache.org</li>
-</ul>
-<p>
+
+- dev@${podling}.incubator.apache.org
+- commits@${podling}.incubator.apache.org
+- private@${podling}.incubator.apache.org
+
 For initial community building it is usually appropriate to only have
 a "dev" list, to keep the discussions focussed. Later add a "user" list
 if needed.
-</p>
-<note>
-Commits under <code>http://svn.apache.org/repos/asf/incubator/<em>${podling}</em></code>
-will be emailed to <code>commits@${podling}.incubator.apache.org</code>.
+
+[NOTE]
+----
+Commits under *http://svn.apache.org/repos/asf/incubator/_${podling}_*
+will be emailed to *commits@${podling}.incubator.apache.org*.
 Any deviation will
-require special configuration in the <code>asf-mailer.conf</code> file by the IPMC.
-</note>
-<p>
-Mailing lists creation is a task for the <a href='#who-infra'>infrastructure team</a>. The
+require special configuration in the *asf-mailer.conf* file by the IPMC.
+----
+
+Mailing lists creation is a task for the link:#who-infra[infrastructure team]. The
 infrastructure team offers a tool that simplifies the creation of mailing lists.  You can access the
-<a href="https://infra.apache.org/officers/mlreq/incubator" target="_new">Incubator Mailing List Request Form</a>
+link:https://infra.apache.org/officers/mlreq/incubator" target="_new[Incubator Mailing List Request Form]
 to request a list.  A notification will be sent to private@incubator when the lists have been created.
-</p>
-<p>
+
 Remember to update the project status file with mailing list details. Prospective committers
 and mentors will need to subscribe. Email them once the status file has been updated. Inform
 any existing mailing lists or forums previously used by the project.
-</p>
-<p>
-Once the <code>commits</code> list is created, the project MUST review
-the <code>/incubator/${podling}</code> tree, since any commits made prior
+
+Once the *commits* list is created, the project MUST review
+the */incubator/${podling}* tree, since any commits made prior
 to the list's creation will have generated no email trail.
-</p>
-<section id='mail-archives'><title>Mail Archives</title>
-<p>
-Archives at <a href='http://mail-archives.apache.org'>http://mail-archives.apache.org</a> for the public
+
+===== Mail Archives
+
+Archives at link:http://mail-archives.apache.org[http://mail-archives.apache.org] for the public
 mailing lists will be setup as part of the mailing list creation process. No action is
-required by Mentors. The archives will be <a href='http://mail-archives.apache.org/mod_mbox/'>visible</a>
+required by Mentors. The archives will be link:http://mail-archives.apache.org/mod_mbox/[visible]
 as soon as posts have been made (and moderated) to these lists.
-</p>
-<p>
-You can also leverage <a href="https://lists.apache.org" target="_new">lists.apache.org</a> for
+
+You can also leverage link:https://lists.apache.org" target="_new[lists.apache.org] for
 mailing list archives.  There is a login link in the top right corner, which allows you to respond to
 threads from within the web application.
-</p>
-<p>
+
 Many projects are independently archived externally (for example, at
-<a href='http://www.mail-archive.com/'>The Mail Archive</a> and
-<a href='http://marc.info/?q=about'>MARC</a>)
+link:http://www.mail-archive.com/[The Mail Archive] and
+link:http://marc.info/?q=about[MARC])
 Independent archives help to
 increase project visibility as well as preserving a independent historic record.
 These subscriptions are not automatically created. If desired, subscribe manually.
-</p><p>
-Subscriptions to news-to-mailing-list bridges (for example, <a href='http://www.nabble.com'>Nabble</a>)
+
+Subscriptions to news-to-mailing-list bridges (for example, link:http://www.nabble.com[Nabble])
 must also be created manually. Subscribing helps accessibility and visibility but Nabble news
 users may not be aware that they are posting to a mailing list.
-</p>
-</section>
-<section id='mail-admin'><title>Mailing List Administration</title>
-<p>
-Apache uses <a href='http://www.ezmlm.org/'>ezmlm</a>. See the
-<a href='http://www.ezmlm.org/man/ezmlmman.html'>manual</a> and
-committer <a href='http://www.apache.org/dev/committers.html#mail'>mail FAQ</a>
+
+===== Mailing List Administration
+
+Apache uses link:http://www.ezmlm.org/[ezmlm]. See the
+link:http://www.ezmlm.org/man/ezmlmman.html[manual] and
+committer link:http://www.apache.org/dev/committers.html#mail[mail FAQ]
 for more details.
-</p>
-</section>
-<section id='transition-mailing-lists'><title>Mailing List Transition</title>
-<p>
+
+===== Mailing List Transition
+
 Independent mailing lists and groups are perfectly acceptable but development should
 happen on the official mailing lists at Apache. If a project has existing mailing lists,
 forums or groups the community needs to consider their future and plan for the transition
 to the official Apache mailing lists.
-</p><p>
+
 It may be useful to move development first to the official lists followed gradually
 by the user resources.
-</p>
-<p>
+
 Note that subscribers of external mailing lists will not be automatically subscribed
 to the new Incubator project mailing lists. Instead, a note should be posted to the
 old external mailing list asking them to subscribe to the new list. If possible, add
 a footer to the old mailing list with some instructions.
-</p>
-</section>
-<section id='request-issue-tracking'><title>Issue Tracking</title>
-<p>
-If any Mentor has project-creation karma (in the issue tracking system to be used)
-then they should execute.
-If no Mentor has the required karma then file an INFRA issue using the 'new jira project'
-type (not bug or request)
-</p>
-<p>
+
+===== Issue Tracking
+
+Request an issue tracker on the link:https://issues.apache.org/jira/servicedesk/customer/portal/1/group/7[infra service desk]
+
 Remember to post an email announcing that the issue tracker is available.
-</p>
-</section>
-</section>
-
-<section id="Set+Up+Podling+Source+Repository">
-<title>Set Up Podling Source Repository</title>
-
-<p>
-The most important responsibility for mentors is to set up the
-podling source repository. Podlings can choose between svn and
-git for source control.
-</p>
-
-<section id="Set+Up+GIT+Repository">
-<title>Set up GIT Repository</title>
-<p>
-Requests for new git repos are done via <a href="https://reporeq.apache.org/" target="_new">reporeq.apache.org</a>.
-This service will initialize a new repository, setup github mirrors and enable integrations for that repository.
-</p>
-<p>
-The Foundation's policy
-is to grant access to git repositories broadly to the incubator group,
-not narrowly podling-by-podling. So, once the repository
-exists, incubator group members gain access without further work.  Once
-the podling graduates, a dedicated ldap group will be created to manage
-access and only those members will be given access.
-</p>
-</section>
-<section id="Set+Up+SVN+Repository">
-<title>Set Up SVN Repository</title>
-<p>
-If the podling chooses svn, you must create the
-repository and give read/write access to the repository
-to all the committers for the podling. This involves requesting
-new committer accounts and granting access to mentors and existing
-Apache committers.
-</p>
-<p>Setting up a podling subversion repository has two steps: Creating the SVN space
-and configuring the authorization (in both svn and git).
-</p>
-<p>
-Create the workspace in svn. This requires commit access to the
-incubator svn repository. Podlings are given their own subdirectory
-of the incubator svn repository. To create the podling subdirectory,
-the mentor executes the svn command to create a remote directory:
-<code>
-svn mkdir https://svn.apache.org/repos/asf/incubator/{podling}
-</code>
-</p>
-<p>Create the workspace authorization in asf-authorization-template.
-This requires commit access to <code>infrastructure-puppet</code> to modify the file
-<code>https://git-wip-us.apache.org/repos/asf?p=infrastructure-puppet.git;a=blob;f=modules/subversion_server/files/authorization/asf-authorization-template</code>.
-Please follow the procedures in the <a href="https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo">infrastructure puppet workflow</a> document.
-</p>
-<p>
-Edit the file to add the podling repository in alphabetical order, e.g.
-</p>
-<source>{podling}={mentor1},{mentor2}</source>
-<p>
-In the section listing all the projects (again in alphabetical order)
-add the podling directory and permissions, to enable the podling for its
-eventual website:
-</p><br/>
-<source>[/incubator/{podling}]
-@{podling} = rw
-...</source>
-<p>
-</p>
-<br/>
-<p>
-This is a convenient time to add <a href='#Authorize+Committers'>authorization</a> for committers
-who have accounts.
-</p>
-<p>
-<a href='#who-auth-karma'>Authorization</a> karma is restricted. If no Mentor
-has this karma then post an email to IPMC private list requesting that this
-is actioned.
-</p>
-</section>
-<section id="Authorize+Committers">
-<title>Authorize Committers</title>
-<p>The process to add committers to the podling depends on whether
-the new committer is already an Apache committer and whether
-the new committer is in the list of original committers:
-</p>
-<ul>
-<li>The committer is in the list of original committers in the
-podling proposal to the incubator and is not already an Apache
-committer:
-<ul>
-<li>
-Ask developers to send their ICLA to secretary@apache.org according to
-<a href="http://apache.org/licenses/#submitting">standard procedure.</a>
-Note that ICLA forms must be signed, either by hand or by digital signature.
-</li>
-<li>
-Developers should choose an Apache id that is not already listed
-<a href="http://people.apache.org/committer-index.html">here.</a>
-</li>
-<li>
-Developers should enter their preferred Apache id on the ICLA
-and enter the podling name in the "notify" field of the ICLA.
-</li>
-</ul>
-</li>
-<li> The committer is in the list of original committers in the
-podling proposal to the incubator and is already an Apache committer, only
-<a href='#who-auth-karma'>incubator authorization</a> is required.
-</li>
-<li>The committer was voted by the PPMC and approved by the incubator
-PMC:
-</li>
-<p>
-Perform one of the above procedures depending on whether the
-committer is already an Apache committer on another project.
-</p>
-</ul>
-</section>
-</section>
-
-<section id='bootstrap'><title>[DRAFT] Podling Bootstrap</title>
-<p>
-<strong>NOTE</strong> This section is a DRAFT under development.
-</p>
-<p>
+
+=== [DRAFT] Podling Bootstrap
+
+*NOTE* This section is a DRAFT under development.
+
 Following podling creation, it needs to be bootstrapped. Here are some of
 the tasks:
-</p>
-<ol>
-<li>Ensure <a href='#mentors-ipmc'>Mentors are on the IPMC</a>[<code>Mentors</code>]</li>
-<li>Add podling to <a href='#Sending+in+an+Incubation+Report'>reporting schedule</a> [<code>IPMC member</code>]</li>
-<li><a href='#Initialize+Podling+Status+Page'>Initialize project status page</a> [<code>IPMC member</code>]</li>
-<li>Start <a href='#orientation'>orientation</a> [<code><a href='#who-committers'>Prospective committers</a></code>]</li>
-<li>Start <code>CLA</code> and <code>CCLA</code> submission [<code><a href='#who-committers'>Prospective committers</a></code>]</li>
-<li>Start <a href='#initial-ip-clearance'>IP Clearance</a>
-[<code>IPMC member</code>]</li>
-<li>Request Required Resources
-<ol>
-<li><a href='#request-mailing-lists'>Mailing Lists</a> [<a href='#who-infra'>Infrastructure Team</a>]
-<ul>
-<li>Consider and plan <a href='#transition-mailing-lists'>transition to official mailing lists</a></li>
-</ul>
-</li>
-<li><a href='#Set+Up+Repository'>Subversion</a> [IPMC]</li>
-<li><a href='#request-issue-tracking'>Issue Tracking</a> [<a href='#who-infra'>Infrastructure Team</a>]
-<ul>
-<li>Consider and plan <a href='#issue-tracking-transition'>issue tracking transition</a></li>
-</ul>
-</li>
-</ol>
-</li>
-<li><a href='#create-website'>Create website</a> [<code><a href='#who-committers'>Prospective committers</a></code>]
-<ol>
-<li>Consider and plan <a href='#web-site-transition'>web site transition</a></li>
-</ol>
-</li>
-
-</ol>
-<section id='mentors-ipmc'><title>Mentors MUST be on the IPMC</title>
-<p>
-Mentors <a href="&root-path;/incubation/Incubation_Policy.html#Mentor">MUST</a> be on the IPMC.
+- Ensure link:#mentors-ipmc[Mentors are on the IPMC][*Mentors*]
+- Add podling to link:#Sending+in+an+Incubation+Report[reporting schedule] [*IPMC member*]
+- link:#Initialize+Podling+Status+Page[Initialize project status page] [*IPMC member*]
+- Start link:#orientation[orientation] [*link:#who-committers[Prospective committers]*]
+- Start *CLA* and *CCLA* submission [*link:#who-committers[Prospective committers]*]
+- Start link:#initial-ip-clearance[IP Clearance] [*IPMC member*]
+- Request Required Resources
+-- link:#request-mailing-lists[Mailing Lists] [Infrastructure Team]
+--- Consider and plan link:#transition-mailing-lists[transition to official mailing lists]
+-- link:#Set+Up+Repository[Subversion] [IPMC]
+-- link:#request-issue-tracking[Issue Tracking] [link:#who-infra[Infrastructure Team]]
+--- Consider and plan link:#issue-tracking-transition[issue tracking transition]
+- link:#create-website[Create website] [*link:#who-committers[Prospective committers]*]
+-- Consider and plan link:#web-site-transition[web site transition]
+
+=== Mentors MUST be on the IPMC
+
+Mentors link:/policy/incubation.html#Mentor[MUST] be on the IPMC.  This should be checked prior to beginning incubation.
 Any prospective Mentors who are not yet on the IPMC should ask to be added (by election).
-Email the application to <code>private@incubator.apache.org</code>.
-</p>
-<note>
+Email the application to *private@incubator.apache.org*.
+
+[NOTE]
+----
 This process may take a few days.
-</note>
-</section>
-
-<section id='submit-cla'><title>CLA and CCLA Submission</title>
-<p>
-Prospective committers need to submit a
-Contributor License Agreement
-(<a href="http://www.apache.org/licenses/#clas">CLA</a>).
+----
+
+=== CLA and CCLA Submission
+
+Prospective committers need to submit a Contributor License Agreement
+(link:http://www.apache.org/licenses/#clas[CLA]).
 This process can take a while so it is recommended that committers start to submit
 these as soon as the podling is accepted.
-</p>
-</section>
-
-<section id='initial-ip-clearance'><title>IP Clearance</title>
-<section id='initial-up-clearance-general'><title>Background</title>
-<p>
-Existing codebases need to be imported through the standard IP clearance
-process. This means that a Software Grant Agreement
-(<a href="http://www.apache.org/licenses/#grants">SGA</a>)
-or Contributor License Agreement
-(<a href="http://www.apache.org/licenses/#clas">CLA</a>)
-need to be submitted
-for all copyright owners. This process may take a while so it is best to
-start as soon as the podling is accepted.
-</p>
-<p>
-The acceptance of the initial codebases is approved by the
-IPMC as part of the acceptance motion. So, no vote is required by the
-PPMC. Otherwise, follow the standard IP clearance
-<a href='#poding-ip-clearance'>process for podlings</a>.
-</p>
-</section>
-<section id='initial-provenance'><title>Establishing Provenance</title>
-<p>
-Paperwork needs to be submitted to Apache that grants a legal license on the code
-to the Apache Software Foundation.
-As a rule of thumb, if all the material contributors to the code
-are joining the podling as initial contributors, then CLAs (individual or corporate)
-are all you need. The individuals must submit the 'individual' CLA (ICLA).
-If there are employers involved who might claim
-rights in the code, then corporate CLAs (CCLAs) are needed for those employers.
-</p><p>
-If, on the other hand, there are material contributors who are <strong>
-not</strong> joining the podling as initial contributors, or if there
-are additional corporate entities who can claim rights in the code,
-then SGAs are required from those individuals or corporations.
-</p>
-<p>
-The foregoing is only a rule of thumb. Generally, the mentors of a new project
-will need to consult with general@incubator.apache.org or the Apache legal team
-about the particular circumstances.
-</p>
-<p>
-It may take some time to track down all contributors. It is not necessary to
-have paperwork on file for all contributions before the code is imported.
-It may be necessary to reverse some patches and rewrite areas of code if
-contributors cannot be found or at not happy about given Apache written
-permission to use their code.
-</p><p>
-No releases are possible until the provenance of all the code to be release
-has been clearly established and the relevant paperwork filed with Apache. It is
-therefore important to keep the status updated.
-</p><p>
-Receipts of ICLAs, CCLAs, and SGAs are recorded by the secretary in
-the private foundation repository. Reading is restricted to members and officers
-of the foundation. If there is no officer or member available then ask on the
-general list.
-</p>
-</section>
-<section id='initial-import-code-dump'><title>Initial Code Dump</title>
-<p>
-For corporate contributions, the SGA or CCLA MUST be completed, submitted
-and received before the code is imported.
-</p><p>
-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.
-</p><p>
-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.
-</p><p>
-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.
-</p>
-<section id='svn-history'><title>Importing History</title>
-<p>
-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.
-</p><p>
-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.
-</p>
-</section>
-</section>
-<section id='crypto-audit'><title>Audit Cryptography</title>
-<p>
-Before the code base is committed into an Apache repository, the contribution
-<a href='http://www.apache.org/dev/crypto.html'>MUST</a> be checked
-and any restricted cryptography reported appropriately. Read and follow
-<a href='http://www.apache.org/dev/crypto.html'>this guide</a>.
-</p>
-</section>
-<section id='initial-clean-up'>
-<title>Initial Clean Up</title>
-<p>
-Once a JIRA has been created, the source should be cleaned up.
-</p>
-<p>
-<ul>
-<li>
-Ensure source files use the standard Apache boilerplates.
-This may mean replacing existing license headers. The
-tools in
-<code>
-https://svn.apache.org/repos/private/committers/tools
-</code>
-and
-<code>
-https://svn.apache.org/repos/private/committers/relicense
-</code>
-may be useful.
-</li>
-<li>
-Ensure that NOTICE and LICENSE documents are present and
-correct
-</li>
-<li>
-Add any required notices. Consider moving copyright
-attributions from source documents to the NOTICE. Read
-<a href='http://www.apache.org/legal/src-headers.html'>
-Apache policy on headers
-</a>
-.
-</li>
-<li>
-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.
-</li>
-</ul>
-</p>
-<p>
-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.
-</p>
-<section id='clean-up-best-practice'>
-<title>Clean Up Best Practice</title>
-<p>
-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.
-</p>
-<p>
-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.
-</p>
-<p>
-It is therefore recommended that the initial source is
-(after being expanded from the archive) checked in as is
-into a special directory (
-<code>${project}/trunk/import</code>
-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
-<a href='http://www.apache.org/legal/src-headers.html'>
-policy
-</a>
-). 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.
-</p>
-<p>
-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.
-</p>
-<p>
-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
-<a
-href='http://www.apache.org/legal/src-headers.html#notice'>
-policy
-</a>
-.)
-</p>
-<p>
-Once a section of code has been cleaned up
-(and <a href='#repackaging'>repackaged</a>,
-if necessary) normal development can begin.
-</p>
-</section>
-</section>
-<section id='repackaging'><title>On Repackaging</title>
-<p>
-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
-<code>org.apache.foo.Bar</code> or a DTD to <code>http://dtd.apache.org/foo/bar</code>.
-</p><p>
-Existing open source projects moving to Apache may well need to consider
-carefully how they will approach this transition.
-</p>
-</section>
-<section id='documents-clean-up'><title>Update Documents</title>
-<p>
-Check the documentation for references to the old home of the project and update them
-with references to Apache.
-</p><p>
-Read
-<a href='http://incubator.apache.org/guides/branding.html'>Branding Guide</a>.
-Ensure that appropriate disclaimers are added to the appropriate documentation.
-Consider adding a <code>DISCLAIMER</code> text document.
-</p>
-<section id='build-clean-up'><title>Update Build</title>
-<p>
-If the project uses <a href='http://maven.apache.org'>Apache Maven</a>, the pom will
-need to be updated to reflect that the project is now at Apache. In particular:
-</p>
-<ul>
-<li>Update <code>mailingLists</code></li>
-<li>Update <code>organization</code></li>
-<li>Update <code>url</code></li>
-<li>Update <code>issueManagement</code></li>
-<li>Check <code>licenses</code></li>
-<li>Update <code>scm</code></li>
-<li>Update <code>groupId</code></li>
-<li>Update <code>manifestEntries</code>. It is recommended that the
-standard Apache settings are used</li>
-<li>Update <code>developers</code> to use apache IDs (when known)</li>
-<li>Update <code>distributionManagement</code></li>
-<li>Consider specifying a <a href='http://maven.apache.org/pom.html#relocation'>relocation</a></li>
-</ul>
-<p>
-If the project uses <a href='http://ant.apache.org'>Apache Ant</a>, the build script
-will probably need to be updated. In particular:
-</p>
-<ul>
-<li>Ensure any MANIFESTs generated refer to Apache. It is recommended that the
-standard Apache settings are used.</li>
-<li>Check that <code>LICENSE</code>, <code>NOTICE</code> and - if appropriate -
-<code>DISCLAIMER</code> documents are copied into binary artifacts</li>
-</ul>
-</section>
-</section>
-</section>
-<section id='orientation'><title>Orientating New Committers: Understanding Apache</title>
-<p>
-When a committer is elected by a typical top level project, the nominator
-and other PMC members educate the new committer about Apache. In the Incubator, this
-inductive must be performed by the Mentors. This process is one of the most important
-for the long term health of a project.
-</p><p>
-Apache works on the principle that discussions should happen on the most open forum
-available. Unless the matter involves a sensitive matter (such as security or
-personal issues), it should be raised on an open mailing list (typically the podling dev list
-or the incubator general list). Use of the incubator private list should be reserved
-for official notifications and sensitive topics.
-</p><p>
-Mentors need to take care. During the initial bootstrapping a habit may develop
-of emailing private list. It is important to break this habit as soon as the mailing
-lists are available.
-</p><p>
-Netiquette about the correct use of <code>cc</code>'s may also be difficult to
-effectively impart. During the bootstrap process there are a number of occasions
-where <code>cc</code>'s are required. The typical usage is to copy in a private
-listing to indicate that the action has the lazy permission of the committee.
-<code>cc</code>'s are very commonly used to create inefficient ad-hoc mailing lists in
-the commercial world. Except for a small number of defined processes, <code>cc</code>'s
-are frowned upon at Apache. Mentor need to encourage questions to be asked first
-on the public lists of the project then raised (if necessary) to the general
-incubator list.
-</p><p>
-TODO: content, links, prose, reconsider name for this section
-</p>
-</section>
-
-<section id='issue-tracking-transition'><title>Issue Tracking Transition</title>
-<p>
-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 publically on list
-and a consensus reached about the best transition strategy.
-</p>
-</section>
-</section>
-
-<section id='poding-ip-clearance'><title>Podling IP Clearance</title>
-<p>
-The board has charged the Incubator project with management of IP clearance for Apache.
-Instructions are <a href='http://incubator.apache.org/ip-clearance/index.html'>here</a>.
-</p><p>
-These equally apply to podlings. The Incubator project is responsible for all podlings
-and so is the receiving PMC. So, when a podling requests IP clearance, the
-IPMC wears <a href='http://www.apache.org/foundation/how-it-works.html#hats'>two hats</a>.
-This may be a little confusing at first.
-</p><p>
-The Incubator PMC must approve the clearance. This indicates that the project is
-happy to receive the code donated. When a new podling is created, this is done
-by the identification of existing codebases in the proposal. Otherwise, the
-IPMC delegates this decision to the PPMC.
-</p><p>
-As usual, three binding votes are required. So, Mentors need to be involved in
-IP clearance for podlings. If too few binding VOTEs are posted on list,
-the VOTE will need to be posted to the general list for ratification.
-</p><p>
-The second hat is technical IP clearance. Here, the IPMC needs to check that the
-paperwork is in order. Once the acceptance vote has been approved, an officer
-or member need to complete the process. For a podling, this will typically
-involve a Mentor.
-</p>
-</section>
-
-<section id='create-website'><title>Create Initial Website</title>
-<p>
-Podlings are free to use any technology desired to generate static content to be
-served under <code>http://<em>${podling-name}</em>.incubator.apache.org/</code>.
-However, the infrastructure team has some requirements for the publication
-process to manage the load on servers. The page linked below on the Apache CMS
-has more information.
-</p>
-<p>
-Some popular choices are:
-</p>
-<ul>
-<li><a href="http://www.apache.org/dev/cms.html">The Apache CMS</a></li>
-<li><a href='http://maven.apache.org'>Apache Maven</a></li>
-<li><a href='http://velocity.apache.org/anakia/releases/anakia-1.0/'>Apache Velocity Anakia</a></li>
-<li>XSLT</li>
-</ul>
-<p>
-It is recommended that an initial site is uploaded as soon as possible (to -
-for example - allow indexing by search engines). The initial site
-can be replaced by a fuller site later.
-Read the
-<a href='http://incubator.apache.org/guides/sites.html'>Podling Website Guide</a>
-for more information.
-</p>
-<note>
-Apache Infrastructure does not guarantee that site content stored only on the www server
-will be fully backed up in the event of failure. Consider checking the site into
-version control if it needs to be comprehensively backed up.
-</note>
-<p>
-Projects with an existing website who move to Apache need to consider
-what they plan to do with it. A decision should be reached and action upon before
-graduation.
-</p>
-
-<section id='web-site-transition'><title>Web Site Transition</title>
-<p>
-Projects may arrive with existing web sites outside Apache. Contributing as much
-documentation as possible to the project from these sites is strongly encouraged.
-Offshore sites related to projects are fine but official web sites for Apache
-projects should be hosted by Apache.
-</p><p>
-Some projects elect to maintain previous releases outside Apache. In this case, the existing site
-is typically retained as a hub for this maintenance work. Otherwise, sites should link
-or redirect to the official Apache site.
-</p><p>
-Apache may accept donations of domains related to projects moving here.
-Infrastructure will then arrange for renewal of the domains and redirection
-of traffic the official site. Ask infrastructure for more details.
-</p><p>
-Apache needs to deal with all commercial entities equitably. Linking to
-useful information on commercial sites is fine but unfair discrimination between
-commercial sites is not. Most Apache projects find it better to simply link only
-to relevant articles on commercial sites rather than having to vet every request
-for links to commercial activity.
-</p>
-</section>
-</section>
-</section>
-<section id='glossary'><title>Glossary</title>
-<section id='who-committers'><title>Prospective Committers</title>
-<p>
-These are the people listed as initial committers in the proposal.
-</p>
-</section>
-
-<section id='who-infra'><title>Infrastructure Team</title>
-<p>
-Tasks that cannot safely be delegated to projects are handled by the Apache
-<a href='http://www.apache.org/dev/infra-volunteer.html'>Infrastructure team</a>.
-The relevant instructions
-<a href='http://www.apache.org/dev/infra-contact'>MUST be followed</a>.
-JIRA is typically used to
-manage workflow. This allows progress to be easily tracked.
-</p>
-</section>
-<section id='who-auth-karma'><title>Incubator Access Authorization</title>
-<p>
-Special karma is required to authorize incubator access for committers.
-This karma is limited to:
-</p>
-<ul>
-<li>PMC Chairs (past and present)</li>
-<li>Selected people in the Infrastructure team</li>
-</ul>
-<p>
-If any mentor has karma then they should authorize the committer.
-To grant authorization, update:
-</p>
-<source>
-infrastructure/trunk/subversion/authorization/asf-authorization-template
-</source>
-<p>
-Edit the file to add the new committer to the podling authorization:
-</p>
-<source>
-{podling}={mentor1},{mentor2},{new-committer}
-</source>
-<p>
-If no mentor has karma then an email should be posted to the IPMC private
-list requesting that the grant is performed. One of the IPMCers with karma
-will authorize the committer.
-</p>
-</section>
-</section>
-
-</body>
-</document>
+

http://git-wip-us.apache.org/repos/asf/incubator/blob/62a0b9ff/pages/guides/podling_sourcecontrol.ad
----------------------------------------------------------------------
diff --git a/pages/guides/podling_sourcecontrol.ad b/pages/guides/podling_sourcecontrol.ad
index 7de15a0..ee13fdf 100644
--- a/pages/guides/podling_sourcecontrol.ad
+++ b/pages/guides/podling_sourcecontrol.ad
@@ -36,8 +36,7 @@ exists, incubator group members gain access without further work.  Once
 the podling graduates, a dedicated ldap group will be created to manage
 access and only those members will be given access.
 
-
-==== Set Up SVN Repository
+=== Set Up SVN Repository
 
 If the podling chooses svn, you must create the
 repository and give read/write access to the repository
@@ -83,7 +82,7 @@ link:#who-auth-karma[Authorization] karma is restricted. If no Mentor
 has this karma then post an email to IPMC private list requesting that this
 is actioned.
 
-=== Authorize Committers
+== Authorize Committers
 
 The process to add committers to the podling depends on whether
 the new committer is already an Apache committer and whether
@@ -106,3 +105,14 @@ link:#who-auth-karma[incubator authorization] is required.
 
 Perform one of the above procedures depending on whether the
 committer is already an Apache committer on another project.
+
+== Incubator Access Authorization
+
+Special karma is required to authorize incubator access for committers.
+This karma is limited to:
+
+- IPMC Members
+- Secretary
+- Infrastructure
+
+IPMC Members should use link:https://whimsy.apache.org/roster/committee/incubator[Whimsy's Roster Tool] to add existing commiters.
\ No newline at end of file

http://git-wip-us.apache.org/repos/asf/incubator/blob/62a0b9ff/pages/guides/transitioning_asf.ad
----------------------------------------------------------------------
diff --git a/pages/guides/transitioning_asf.ad b/pages/guides/transitioning_asf.ad
new file mode 100644
index 0000000..058d060
--- /dev/null
+++ b/pages/guides/transitioning_asf.ad
@@ -0,0 +1,161 @@
+//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 publically on list
+and a consensus reached about the best transition strategy.


---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@incubator.apache.org
For additional commands, e-mail: cvs-help@incubator.apache.org


Mime
View raw message