Project Management Infrastructure/Release Metadata

A release record contains three categories of information.

Description

Describe the release in the "Description" section. The description should generally be a concise paragraph describing the focus of the release (e.g. adding certain functionality, fixing bugs, etc.) in a form that is appropriate in an aggregation (e.g. a page that displays the release information for all projects participating in an instance of the Simultaneous release). The description should provide enough information to encourage the reader to click the "find out more" link.

Plan

Project plan information belongs in the "Plan" section. This information should generally be provided early in the development cycle to allow the various communities the ability to understand and participate in the release. It is expected that the plan will evolve over time. Note that all projects are required to provide a plan for each major and minor release (plans are not required service releases). Note that you can provide multiple "themes" for a release and each theme may contain a Bugzilla URL that will be used to populate lists of bugs targeted by the theme in the release (see below).

You can render the plan as a page by tacking '/plan' after the URL for the release.

e.g.

• Hudson 3.1 release: http://projects.eclipse.org/projects/technology.hudson/releases/3.1.0
• Hudson 3.1 plan: http://projects.eclipse.org/projects/technology.hudson/releases/3.1.0/plan

A link to the plan for the chronologically-next release is automatically generated and displayed in the project information block (which appears in the left navigation area on projects.eclipse.org). If the "Plan URL" is set in the project metadata, its value will override the automatically-generated one.

Bugs as Plan Items

The Bugzilla URL must be a "search" URL with the following form:

https://bugs.eclipse.org/bugs/buglist.cgi?classification=BIRT&product=BIRT&version=4.3.0&keywords=performance

The goal of the bugzilla queries is to support the use of bugzilla items for planning. The project team should assign target milestones to each bug, including both defects and enhancements. Additionally, the team should assign keywords (or keywords-in-titles) to each bug entry in order to classify them into themes. The bugzilla queries would then be, e.g., "all 2.6M1, 2.6M2, 2.6M3, ..., 2.6 bugs with keyword 'designforextensibility'", etc.

One option for mapping to the committed / proposed / deferred items is that all bugs with explicit milestones assigned are considered committed; those assigned a generic milestone or "---" are considered proposed; those assigned a milestone like "Future" are considered deferred. Another idea is to only retrieve bugs with a "plan" or "investigate" keyword by the queries, or to only add bugs with specific priorities, in order to avoid flooding the plan with less interesting small items.

If a project chooses not to use bugzilla item for planning (contrary to collective wisdom of the senior Eclipse project leads), the project plan format allows arbitrary html text paragraph(s) instead.

Review

The release has a "Review" section that can be used to provide information for the associated review. If you provide information here, the release record itself can be used as review documentation; no further documentation is required.