- -Estimated Reading Time: - -

-

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 -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> -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> -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 -either creates or requests that -other resources (mail lists, subversion, bug tracker, <em>etc.</em>) -be created. -</p> -</section> -<section id="Sending+in+an+Incubation+Report"> -<title>Add to Incubation Summary file</title> -<p> -Add the podling to the podling summary file in -the "incubator" SVN at <code>content/podlings.xml</code> -(e.g. copy the entry from another podling that also has status="current") -and see <a href="website.html">instructions</a>. -</p> -<p> -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"' -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><reporting group="2" monthly="true">June, July, August</reporting></code> -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> -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. -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> -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> -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> -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> -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> -though moderators may want to set up -<a href='http://spamassassin.apache.org/'>spam filtering</a>. -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>. -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> -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>. -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 -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> -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 -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 -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> -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 -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>) -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>) -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> -for more details. -</p> -</section> -<section id='transition-mailing-lists'><title>Mailing List Transition</title> -<p> -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> -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> -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. -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> -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>). -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>

-

- -