Bugzilla – Full Text Bug Listing
| Summary: | [pmi] Connect releases with reviews and the project's plan | ||
|---|---|---|---|
| Product: | Community | Reporter: | Wayne Beaton <wayne.beaton> |
| Component: | Project Management & Portal | Assignee: | Portal Bugzilla Dummy Inbox <portal-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | contact, david_williams, gunnar, overholt, sbouchet, stepper |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 365667, 371808 | ||
| Bug Blocks: | 207108, 214277, 269120, 279973, 363868, 366479, 377576 | ||
|
Description
Wayne Beaton
It sounds like this work would also fix the problem where, currently, only one standard release plan can be rendered at a time. (For example, right now, Dali is planning a release in December, which is there currently viewable plan, but they also have a plan for Juno which you can't "see" via the website). I looked and looked for the bug/enhancement for that issue, but could not find it ... but I do recall there being one. (And, thought I'd mention it here, to make sure its solved "at the same time" if possible). The following information should be captured by the project team with each release record: * Release name (e.g. "1.0") * Release date * Link to approved IP Log * Rich text description of the release (i.e. release goals, features included in the release, that sort of thing) * Rich text discussion of non-code aspects * Rich text discussion of architectural issues * Rich text summary of usability issues * Rich text discussion of end-of-life issues/features * Bugzilla product/components/milestones included in this release * Rich text discussion of standard compliance * Rich text discussion of community development activities undertaken during release cycle * A collection of "themes" for the release (e.g. 'Design for Extensibility") with optional rich text description, * A list of milestones; each including a name (e.g. "m1"), date, optional description. * Rich text field for "other information" We need the ability to specify downloads for the release (link to a URL + description) for the release itself, and for each of the milestones. From this, we can generate a download page for the release and each of the milestones. All of these values can be changed throughout the release cycle. Revision management will keep track of changes. Prior to commiting to the release (i.e. at the end of the release cycle), a project committer declares: * Checkbox certification that the release's APIs are of "Eclipse Quality" * Checkbox certification that security issues have been reviewed. * Checkbox certification that the Eclipse IP Policy has been followed. A further field is required for feedback from the PMC/EMO. (In reply to comment #1) > It sounds like this work would also fix the problem where, currently, only one > standard release plan can be rendered at a time. (For example, right now, Dali > is planning a release in December, which is there currently viewable plan, but > they also have a plan for Juno which you can't "see" via the website). Actually, you can specify a planurl on the project plan renderer. e.g. http://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/birt/project/plan/birt_project_plan_3_7.xml If you specify a URL value on the "plan" field on a release record, we'll render that on the project summary pages. Related discussion: http://waynebeaton.wordpress.com/2011/11/14/connecting-releases-with-reviews-and-the-plan/ More related discussion http://waynebeaton.wordpress.com/2012/03/15/releases-plans-and-reviews-2/ Done. Marking as FIXED. |