New Project Provisioning Request

To be completed by a Project Lead of the new project, consulting with the PMC if necessary.

Updated April 4, 2011

This form is used to request the infrastructure for projects that have completed a successful Creation Review and are beginning the Validation Phase of their project (under an existing Top-Level Project) at eclipse.org. These documents follow the Eclipse Project Lifecyle as described in the Eclipse Development Process and are intended to complement the information provided there. In general all inquiries related to project provisioning can be sent to the EMO.

After a successful Creation Review, the project enters the Validation Phase and additional infrastructure is created to support the initial work on the project:

  • VCS commit rights
  • download site
  • a developer mailing list and
  • the project website

Ongoing changes to the project's core infrastructure are expected especially during the Validation Phase, as the project matures. Please consult the Project Implementation Phase Provisioning document for pointers on how to implement these changes.

This form is processed manually. Thus we request that you reduce the sysadmin overhead by only submitting complete data. Please wait until you have all the answers and then submit the completed form once. Multiple partial submission will (unfortunately) just confuse the situation. Thanks for your understanding.

If you have any questions, please send an email to the EMO.

 

Your Info
Name:
E-mail:
Phone number:
Development Process I have read and will follow the Eclipse Development Process

Project Info

If the id for your project is not shown below, please contact the EMO for assistance.

New Eclipse Project id:
 

Code Repository

Decide whether the project is going to use Git, or SVN for its source code repository. You should note that we intend to deprecate SVN at some point in the future.

Git    GitHub    SVN   

Note that all projects must submit an Initial Contribution to the IP Team before any code can be checked in.

For projects that intend to use GitHub, tag your repository as described in Hosting a Project at GitHub before submitting this form. Specify the URLs of existing repositories to be moved (one per line):


Committer List

A list of the initial committers for the project. This list should reflect the project creation document. Only include committers that appear in the document. If you need to add more committers, please do so after the project has been provisioned via committer election. Note that each committer must have completed the e-forms and paper-forms as specified in the new committer process. The project cannot be provisioned without at least one committer and you cannot be a committer until you have completed these forms and agreements.

Name Email Address
1.
         another committer

Project Lead
 

Project Website

Each project has a web presence on www.eclipse.org. The content for a project web pages is stored in a Git repository. The repository is automatically checked out to www.eclipse.org, and thereby enables website authors to use HTML and PHP to author websites directly on www.eclipse.org.

A directory of the form www.eclipse.org/[shortname] will be created for each new project. This also becomes the url for the project home page. A default template will be provided.

For instructions on setting up your Eclipse development environment to edit your project website, please see Phoenix Documentation.


Project Proposal
The project proposal is automatically archived in the proposals archive.

Project Forum
Projects typically have a forum for user discussions.

Project Mailing Lists
New projects typically have a single [shortname]-dev@ mailing list for developer discussion. A new project may choose to have additional mailing lists of the form [shortname]-[component]-dev@. The short name can be an abbreviation of the Descriptive Name, or an Acronym, or the project's optional Nickname. The short name appears on the mailing list main page. You will need to provide the long description using the project status infrastructure
Mailing List Name Short Description

Builds

The project leads are responsible for builds and maintenance on eclipse.org. The frequency of these is dependent on the project needs. There are three main options for builds at Eclipse:

  • Use the Common Build Infrastructure (CBI).
  • Use build.eclipse.org as a standalone build server.
  • Use your own infrastructure. Run builds offsite using source code from eclipse.org

Downloads

Downloadable files (i.e. ZIP files, JARs) must be hosted at download.eclipse.org. For mirroring purposes, the link to download a file is http://www.eclipse.org/downloads/download.php?file=/path/to/filename. This will allow mirror site selection based on the file requested. We ask that you not link directly to "download.eclipse.org".

Because the downloads space is mirrored to several servers worldwide, we ask you use this space wisely, taking extra care when placing large files in this space, and performing regular file cleanups. Large directories use bandwidth while mirroring and deter new mirror sites because of high disk space requirements. Also, HTML and PHP files must not be placed on the download server.

Uploads to this space are via SFTP or SCP. Use any SFTP or SCP client, such as CoreFTP or WinSCP, to connect to download.eclipse.org. If you are using Athena Common Builder, please see the Athena documentation for instruction on moving your build output to the server.


Bugzilla
A Bugzilla "product" is created for the new project. Underneath that product are a set of "components". There are two schemes for the component owners - some projects choose one, some choose the other:
  1. The component owners are actually humans - project committers as listed above. With this scheme, the component owner receives notifications of new bugs for this component.  

    If you choose this scheme, enter the component owners' email addresses. The components owners must already have existing Bugzilla user accounts.
  2. The component owners are abstract "inbox" entities. With this scheme, anyone who wants to receive notifications of new bugs for this component uses the Bugzilla "watch this address" feature to watch the inbox email address. Thus plus for this scheme is that it is easy to change component owners and have multiple owners (just have them watch the inbox address); the minus is that if nobody is watching the inbox address, the notifications go to /dev/null.

    If you choose this scheme, enter the inbox email addresses in form "[short name].[component name]-inbox@eclipse.org". These bugzilla accounts do not have to exist (and, in fact, they should not exist).

Component Name Description Component Owner's Email Address

Math question: (5 - 1) divided by two:
FYI: The project is 'created' in three steps:
  1. First the code repository, user accounts, mailing-list, master home page (links to your page in the website), download space on download.eclipse.org, and Bugzilla components are created.
  2. Then the developer mailing lists and the hosting Top-Level Project main page are connected to the project
  3. The project lead creates the initial website and the project status information files.
  4. And then, voilà, the project is "live".

This sequencing ensures that all the core infrastructure is ready and that the data and an initial project structure are in place, before the project goes live.