Community
Participate
Working Groups
As part of the new project management infrastructure, I'd like to connect project releases directly to the corresponding review, and consider options for automatically generating project plans from the information. Projects are currently required to provide release information for their project via the portal. This information manifests as a list in the project summary/info pages, but is otherwise unused. When a project needs to do a release, they are required to request a review from the EMO via email. The EMO enters separate information for the review into the same database. This information manifests on the /projects page and on the project summary pages. This information is all disconnected. Connections can only be formed via naming conventions and date matching. As we move forward, I'd like to consider making the release record for a project more useful. A project can define a release at any time. That release specifies a release name, and a target date. We should also permit the project to easily capture information like a description of the goals of the release, along with the other information required by a release review, in rich text fields (with support for adding images, and other attachments). This information will be live; updated regularly during development of the release. As we get closer to the specified release date, the EMO and PMC can be automatically informed of the pending release and engaged to review the provided material, make changes, and provide other feedback prior to initiating (automatically) a review. I envision a field where the PMC/EMO can provide specific feedback to the project concerning such things as community development activities they should consider for their next development cycle, other improvements in outward community presence, transparency, openness, etc. The captured information will be rendered as the documentation for the review. We can capture, again as part of the release record a bugzilla URL and other information required to automatically generate a project plan in the board-approved format (or something very similar). For extra credit, we can permit the uploading of screenshots specific to the release. We can display those screenshots as part of an automated account of the release. We can also use them on a screenshots page that will--owing to the fact that these screenshots are attached to a specific release record--perpetually be up-to-date (assuming that we grab screenshots for only the current release) Bug 214277. I will provide more specific information in follow up discussion.
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.
