Difference between revisions of "Project Management Infrastructure/Release Metadata"
|Line 15:||Line 15:|
The content the dashed comes from the review record; everything else (below the ) comes from the release record. You can get access to the release record by clicking the release name ("1.2.0" in this example).
Revision as of 16:49, 11 June 2013
A release record contains three categories of information.
Projects, Releases, and Reviews are presented as separate records. Each project record, obviously, represents information about a project. A project may have multiple releases; information about the release is represented in a release record. The release record also contains some review information. This information is included here, because all releases do not necessarily have a review (a project can opt to provide some "review" type information as part of a release record. A project can have multiple review records; as release reviews are the most common form of review, most review records will be joined to a release record.
A review record, however, does not require a release association. Some reviews are associated with proposals. Other have no other association (e.g. termination reviews).
When a review is displayed, it shows the review-specific information at the top of the page, and includes the "review" information from the release as the rest of the page contents.
This can make things a bit confusing when you want to make changes to the metadata for a review record. Just remember that the "review" information for a release is stored in the release record.
The content in the red-dashed box comes from the review record; everything else (below the box) comes from the release record. You can get access to the release record by clicking the release name ("1.2.0" in this example).
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.
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.
- 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:
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.
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.