This section contains information about how to contribute to the GridWay Metascheduler. GridWay is now a Globus ProtoProject and so develops products according to Globus philosophy and guidelines for collaborative development.

GridWay is a community project, benefiting from code and support contributions from individuals and corporations around the world. The development discussion mailing list is the forum for suggestions and comments for code changes. We'd be very happy to hear from experienced programmers and managers of grid infrastructures who'd like to join the development team.

Please, first of all check the Roles and Responsibilities that people can assume in Globus ProtoProjects, mainly users, contributors and committers. Everybody can help no matter what their role. Those who have been long term or valuable contributors to GridWay obtain the right to vote and commit directly to the source repository.

There are several ways to contribute to the GridWay project. All of them are very welcome, without the contribution and comments from our user community there is no reason for GridWay:

• How do I report a bug? You can report bugs in the user mailing list or using Globus bugzilla (gridway product).
• How do I make a feature request? Describe your idea in the user mailing list. GridWay developers will discuss and evaluate your proposal (see the Development process below).
• How do I contribute software/documentation to GridWay? There are three diferent types of contributions:
  • Bug fixes: If you have developed a solution for a bug in the GridWay code, send your patch (generated with diff -u command) to the development list.
  • Documentation: If you have improved the GridWay documentation or written a new how to, send a link to the new documentation to the development list.
  • Feature Development: If you want to develop a new feature or GridWay module, you can request it in the mailing list and lead the development campaign. Also if you want to get involved in the GridWay development community, check the current open campaigns and join one. In any case, check the development infrastructure and development process below.

Note that all source code or documentation committed to GridWay repository must be covered by the Apache License

The following infrastructure is available for collaboration:

• In addition to the user mailing list. The following lists support the development of GridWay:

• Developer discussion (gridway-dev@globus.org): is for the contributors to GridWay. On these lists suggestions and comments for code changes are discussed and action items are raised and voted on. For the developer community, these lists are the center of GridWay, where all the “action” is.

[ Archive ] [ Search ] [ Subscribe ] [ Unsubscribe ]

• Commit notifications (gridway-commit@globus.org): is where all CVS code commit messages are sent. All committers are required to subscribe to this list so that they can stay aware of changes to the repository.

[ Archive ] [ Search ] [ Subscribe ] [ Unsubscribe ]

• Bugzilla Database (gridway product)
• CVS repository (see below), to access and visualize the CVS source repository, use either of the following tools: ViewCVS or FishEye.
• Globus coding guidelines for Java and C
• Check the Development Roadmap

Development activities are performed in the trunk, which holds the latest code. To allow concurrent development, development campaings are usually performed inside a branch.

When it is decided to create a new stable release, a new branch is created from the trunk with the name of that stable release (gw<major>_<minor>_branch).

Stable release branches only change by means of bug fixes, that are made directly or inside a branch. This bug fixing process makes new incremental releases to appear, which are appropriatelly tagged (gw<major>_<minor>_<incr>). The stable release branch is merged back into the trunk periodically or after an incremental release, in order to have future releases free of bugs.

This process is depicted in the following figure (see also how to use the Globus Project CVS).

The Development process, which adheres to the Globus philosophy and guidelines for collaborative development, starts when a committer, contributor or user makes a development request in the mailing lists, or a bug entry appears in the Bugzilla Database (Campaign component). This new feature can be proposed based on the GridWay roadmap, or in new ideas. The arrival of a new request triggers the following actions:

1. A new entry is added in Bugzilla, to track feature requests. These bugs will be always in the Campaign Component and start with status New. A brief description of the new feature must be added in the bug comments and the person that triggered the campaign must be added to the CC field.

2. Feature Discussion in gridway-dev: The suitability of this feature is discussed in the list and the idea is refined. Everybody is welcome to share their opinions about the new feature. This discussion ends with a formal PROPOSAL for the product change that shall include:

• Purpose
• Implementation Ideas

Then a VOTE process is started, the new feature needs lazy consensus to enter the development phase. If accepted, the bug will remain in status New and the proposal and vote results are included in the comments. Otherwise, the bug status is change to Closed - Fixed, and vot- results are included in the bug comments.

3. Feature Implementation, when a developer shows her interest in developing an approved feature, the bug is assigned (status: Assigned). The developer must add an implementation description for this feature that shall include:

• Development Tasks
• Deliverables
• Estimated time
• Persons involved

In general, development campaigns are made in the trunk, usually inside a branch created with an appropriate name (campaign_<bug #>_branch). Once the feature is developed and tested its status is changed to Resolved - Fixed.

Once the patch with the code that implements the campaign is ready, the developer must add it to the Bugzilla campaign as an attachment or send it to gridway-dev@globus.org.

4. Commit discussion The suitability of committing the new feature now is discussed with a formal VOTE process. If the commit is approved the bug status is changed to Closed - Fixed. Otherwise it is keep in Resolved - Fixed and relevant reasons (e.g. interference with a release plan or other campaigns…) for not committing this feature now must be added to the bug comments. Note that once a feature is approved for implementation the development will be committed sooner or later.