Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Planning Council/Cross Project Teams/Tracking"
(→Members) |
(→A proposed Solution) |
||
| Line 17: | Line 17: | ||
==A proposed Solution== | ==A proposed Solution== | ||
| − | [http://www.eclipse.org/helios/planning/trackingToolProposal.html | + | [http://www.eclipse.org/helios/planning/trackingToolProposal.html Tracking Tool Proposal] |
| − | [http://www.eclipse.org/helios/planning/EclipseSimultaneousReleaseFormPrototype.html | + | [http://www.eclipse.org/helios/planning/EclipseSimultaneousReleaseFormPrototype.html Example Form Input] |
Latest revision as of 13:35, 6 January 2010
Members
- David Williams (WTP)
- ?Wayne?
- ?
Statement of Problem
Last year, we used bugzilla to track compliance, or not, with the requirements of a Simultaneous Release. There was a couple of limitations to that approach that makes us think we can do better.
- The "summary" of bugs "fixed" or "won't fix" was cumbersome, took a long time to run.
- It seems "old fashioned" to capture tracking information in bugzilla (why not make a custom web app, for something we do every year).
- At best, you could note and summarize "yes/no" type responses. Much of "the good stuff" in a simultaneous release process is buried, if documented at all. For example, Projects can say, "yes we have a documented build process", but why not include/require the URL to that documentation.