Frequently Asked Questions

Yes. Code that has existed outside the ASF can only enter the ASF through the Incubator. There is no other option. The Incubator, among other things, is where the due-diligence of making sure the licence is correct, the copyright license is received, and all of the initial developers submit their CLAs. The Incubator is also the place where projects can familiarize themselves with how the ASF works under the guidance of Incubator PMC members (mentors).

No. Do it right, do it well, and add something in the process. Incubation is not about handing it over to some other group and seeing what happens. The Incubator is simply the name of the place that governs your actions when you process a new project into Apache. It moves at the same rate you do, and achieves whatever you achieve — the only difference is that we have a permanent record in one place that we can go back to if there are later IP problems, and there is a gate that must be passed through before the project is given the right to release software on behalf of the ASF. That gate will not be ignored or bypassed just because one group or another feels they have earned the right to bypass it; allowing that kind of exception destroys the potential to build a tradition of effective oversight, which is the reason we created the incubator.

The incubation process, WRT responsibilities, is roughly as follows: - Any Apache PMC (project management commitee), including the Incubator PMC itself, will approve the entrance of a project at Apache. They are the Sponsor. (In rare cases, the Apache Board of Directors will approve the entrance of a project.) - The Incubator PMC is from that moment on responsible for the project. The assigned Mentors (an ASF member who has volunteered to help with the incubation process) will have the primary responsibility for overseeing the progress of the project. Each quarter, the project will submit an update to the entire Incubator PMC as to the progress in Incubation. - This will remain so until the Incubator PMC approves the project to be "graduated". After graduation, if another PMC sponsored the podling, it will then be transferred to the PMC that asked for incubation. If the PMC was the Incubator itself or the Board, the project must then also be be approved by the Board to receive its own PMC. - At this point, Incubation is complete.

So, since you would like to have a place under the XXX Project, ask that PMC to sponsor you. After that vote, you will automatically be under the Incubator, and incubation will start.

The Incubator will only accept code for incubation if a PMC has voted to accept it. So when a proposal for the donation of code occurs, the project in question should discuss the proposal (usually on their public mailing lists!), leading to a decision by that project’s PMC on whether or not to sponsor the code (and potentially the project surrounding it). If the PMC agrees, then the incubator can be approached, and the code accepted for incubation. The grant needs to be recorded by following the procedure outlined at the IP Clearance forms.

Wrong. Here are some generally agreed points that you should take into consideration: - No codebase within the ASF is to be considered an exclusive location for a general technology within the ASF. - All initial codebases are just that: initial. Once the code is here, if people feel that the code sucks or the architecture sucks, or whatever else someone wants to complain about, all parties understand that the future direction of the architecture and code is, as is everything at the ASF, subject to communal will. - Other contributors interested in any ASF codebase, with or without existing codebases, are free to contribute, or to propose additional related projects.

Refer to our guide to updating the website. If you are not a committer on the Incubator project, then you can still send patches for the source documents. ==== 2.2. How do I update the incubation status of a project?

See notes about maintaining your project entry in the podlings summary file and your project status page.

Issue trackers do not meet the long-term archival and tracking requirements for our legal purposes and they do not authenticate that the person entering the status information has the authority to do so, which is what we get with our version control system. Note that how the actual day to day tracking of the project (i.e. bugs in code) is done is not the same as filing the legal forms - for those issues, our normal issue trackers can be used. Nevertheless, SVN is our only authoritative and formal tracking system for incubation status.

First of all, read our Incubation Policy. Refer to the Website Guide.

All requests for karma (whether for a podling web site or for the infrastructure site itself) should be directed to the incubator general list.

Please read the website guide before editing the website.

To set up the website for a podling, start by requesting karma.

This document describes how to grant karma for an existing Apache committer.

See Facilities for Incubator management.

Co-ordinate via your project’s dev list and PPMC. Often someone there will know what is necessary. Some notes are provided in the Mentor guide and in the Infrastructure instructions.