Tools Project

Overview

Congratulations, you are a project lead for a tools subproject on eclipse.org. Now what ? This document describes the guidelines for the processes, roles and responsibilities for the team leads in running a tools subproject. Since projects are run as a meritocracy, you have control over the day to day running of your project within the framework of the tools pmc charter. This document describes the infrastructure at eclipse.org, how to interact with the PMCs for day to day management of the web site and other infrastructure related issues.

The is a living document, and will be updated to reflect the needs of the tools projects at eclipse.org. If you have a question that this document does not answer, please email the PMC. Please remind the PMC to update this document with the answer so we can keep the information generally available to all subproject leads.

Project Conventions

Is is recommended that your project follow the conventions found here. This will help keep the project consistent with the rest of the projects in eclipse.org which will simplify resuse and help movement of technology into the base eclipse.

Infrastructure details.

The infrastructure provided at eclipse.org for a project consists of the following services.

• Newsgroup
• Mailing List
• CVS
• Bugzilla
• Download space
• Web site.

When initially starting a project, you will need to provide some information for our infrastructure people. The form can be found here.

Newsgroup

Newsgroups are hosted on news.eclipse.org. These newsgroups are intended as a place where users of the subprojects can ask questions, get support from either the developers or the community in general and interact with the development team. If you are a user of a project, then this is the most likely place you will want to ask your questions. If you are a developer working on the project, you will do most of your interactions with other developers on the mailing lists. To get the proper use of newgroups vs mailing lists, you will probably need to remind errant users to post on the newsgroups instead of mailing lists.

Most subprojects will only have a single newsgroup. A simple naming scheme is used, so for project xyz, the newgroup will be news:news.eclipse.org/eclipse.tools.xyz.

Mailing Lists

Each tools subproject on eclipse.org may have one or more mailing lists dedicated for various aspects of the subproject. Typically, project xyz, will have a main mailing list called xyz-dev@eclipse.org.

Additionally, many projects have multiple components which are often developed independently. Each of these will typically have a mailing list of the form xyz-component-dev@eclipse.org.

Archives for each mailing list is maintained at http://dev.eclipse.org/mhonarc/lists/xyz-dev/maillist.html

The mailing lists are reserved for the developers of the code and its components. These are intended as hard-core developer lists which are to be used by the developers for their day to day work on the project. Activities like design reviews, code change proprosals, and voting is all performed on these lists.

CVS

The project lead is responsible for dividing their project into components. Commit access is controlled by component so for larger projects a project lead can have finder grained control access based on developer skill.

All tools projects are created in the tools repository.

For example, given a project structure below, you can have separate committers for core, ui and debug.

org.eclipse.xyz.core
org.eclipse.xyz.debug
org.eclipse.xyz.ui
org.eclipse.xyz.debug.ui

Committers receive accounts on dev.eclipse.org which is how they access the CVS repository. Their commit access scope is controlled per component.

Bugzilla

Each subproject will have a bugzilla product created for them. Each product will have a category for each component in the system. Each project will create bugzilla "target milestones" for their components. Typically these milestones include releases as well as milestones which come from the subproject plan which is posted on the subproject main page.

Download Space
The project lead will receive an account and password on download.eclipse.org which is a high bandwith download server. For tools projects, the directory will be /var/eclipse/tools/xyz. The download URL, is http://download.eclipse.org/tools/xyz/fileName.

Due to security concerns, we require the IP range for people who will be updating these directories.

Uploads to this space are via FTP or RSYNC.

To use rsync, you can update your download directory using the following command.

rsync --rsh=ssh local-dir user@download.eclipse.org:/var/eclipse/tools/xyz/server-dir/

Web

Each subproject has a web presense on www.eclipse.org. Each subproject will get a link of the form www.eclipse.org/xyz which can be used as the default home page for the project. The content for a subprojects web pages is served directly from the tools CVS repository. The convention is that a project has a xyz-home component in the tools CVS repository and that the web pages are served from their. The committers for the "xyz-home" essentially have control of the whole web for a particular subproject.

There are some images which you may use in your web pages. These can be viewed at www.eclipse.org/images.

There are some conventions we use for each subproject to simplify maintainance of the tools main pages using an auto generated system.

NOTE - the current structure varies from this, we'd like to move to the common naming scheme for ease of use and standard migration facilities on the eclipse main page.

Files are served from CVS using the CGI script found at http://dev.eclipse.org/viewcvs/indextools.cgi/. The standard main page for project xyz is served up via the URL.

http://dev.eclipse.org/viewcvs/indextools.cgi/org.eclipse.xyz

This url (http://dev.eclipse.org/viewcvs/indextools.cgi/) can also be used to browse the whole Tools CVS repository.

You may notice that there is also an http://dev.eclipse.org/viewcvs/index.cgi/ which shows the base platform CVS repository. This script also takes a parameter which selects the other repositories on eclipse.org. To select the tools repository you use ?cvsroot=Tools_Project as the parameter.

There is a subtle different between index.cgi and indextools.cgi. The index.cgi script has a combo box on the page which allows you to switch between the various CVS repositories at eclipse.org. Currently there are three repositories, one for each of the PMCs and it's subprojects. The indextools.cgi is hardwired to only show the tools repository. Correspondingly, the indextech displays the Technology PMC CVS repository.

In summary:

index.cgi Default CVS root is ?cvsroot=Eclipse_Project,  There is a combo box on page to select alternate repository. The parameters can be  ?cvsroot=Technology_Project, ?cvsroot=Tools_Project, and of course ?cvsroot=Eclipse_Project

The CVS access scripts which are tools repository and technology specific are as follows.

indextech.cgi        showsTechnology_Project roots, no ?cvsroot parameter allowed,  no combo box on page to select repository
indextools.cgi        showsTools_Project roots, no ?cvsroot parameter allowed,  no combo box on page to select repository
 
As a bootstrap mechanism, the PMC will have committer access to xyz-home to assist with web maintenance

Builds and Downloads
The project leads are responsible for builds and maintenance on eclipse.org. The frequency of these is dependent on the subproject needs.

It is the intent of the PMC to pursue the creation of a standard build process infrastructure to allow eclipse.org to provide automated builds and testing for project hosted on eclipse.org.

Getting changes to your infrastructure

If you need changes to your infrastructure, you need to send an email to webmaster@eclipse.org. This includes such things like password reset, creating new components, adding new committers. If you have infra related questions you can also send these to the webmaster and they will determine how to get the right answer. When sending requests to webmaster, please clearly identify the PMC and subproject you are working on so that requests that require PMC approval or clarification can be properly routed to the correct PMC by the infrastructure team.