|[eclipse.org-planning-council] Proposed Eclipse Project reporting infrastructure|
Planning Council members,At the Council meetings a few weeks ago, I agreed to propose an XML file format and some tools for reducing the overhead of reporting your project's status while increasing the utility of the status information for other project leaders and other Eclipse members. Here is my first draft proposal - please comment and critique. Thank you.
-- *Bjorn Freeman-Benson*Technical Director, Open Source Process and Infrastructure <http://eclipse-projects.blogspot.com/>
Eclipse Foundation <http://www.eclipse.org/>voice: 971-327-7323 (PDT, UTC-7 <http://www.timeanddate.com/worldclock/custom.html?cities=202,188,195>) email: bjorn.freeman-benson@xxxxxxxxxxx <mailto:bjorn.freeman-benson@xxxxxxxxxxx>
Title: Eclipse Planning Council Minutes
June 6, 2005 - Bjorn Freeman-Benson
At the May 2005 Planning Council meeting, we decided that Bjorn would put together a mostly-automated planning and reporting system for Eclipse projects. The goals:
Each project will have an
eclipse-project-status.xml file in its
root web directory.
<project name="project_name" url="" url..." /> <summary>...executive summary of current status...</summary> <description>...description of project...</description> <leaders> <leader email="name1@xxxxxxxxxxx">first1 last1 optional_description1</leader> <leader email="name2@xxxxxxxxxxx">first2 last2 optional_description2</leader> ... </leaders> <shipping> <release url="" ... </shipping> <releases> <milestone date="date" url="" status="completed|scheduled|tentative">name</milestone> ... <release date="date" url="" status="completed|scheduled|tentative">name</release> ... </releases> <release-train> <head>...version/build that works with the HEAD of the release train...</head> <major train-version="...">...version/build that works with this major train release...</major> ... </release-train> <third-party> <item>...description of library or code...</item> ... </third-party> </project>
The date can be any of these levels of precision:
You won't be allowed to be more specific than a day nor vaguer than a quarter.
In the future we'd like to be able to gather the project description, shipping releases, and third-party inclusions automatically from the website, the downloads, and the feature.xml files. For now, however, it will need to be redundantly entered here.
I envision four initial reports from this data.
Release Timeline. Like the prototype master timeline. The master timeline will not include Technology projects (or, in the future, Research projects) on the theory that Technology projects are not "major Eclipse projects".
Milestone Timeline. Same thing, but showing all the milestones as well. It will be big and probably fairly cluttered.
Quick Reference. A one-page per project summary of all the projects. Useful for printing and flipping through on an airplane trip.
This file should be updated with current information each quarter. Current will be:
There will be an automated reminder email. The email will include why the automated program is sending you this email, e.g., "hasn't been updated" or "date field '27-Jan-2006' is not in DD/MM/YYYY or MM/YYYY or QN/YYYY date format".
Review, comment, and critique during June 2005.
Release timeline converted to use new XML format and old .dates.txt format by end of July 2005.
Reminders implemented by end of August 2005.
Remaining reports implemented by end of September 2005.
The goal is to switch to this reporting system before (or at) the next Council meetings in August, and to have the entire system working before we have to generate the next Roadmap at the end of 2005.
Back to the top