Last week we added a new feature to the Eclipse Project Management Infrastructure: we automatically generate a bug list for each release.
The bug list is generated by matching the “target milestones” from Bugzilla to the name of the release record. So, a release named “3.5” will automatically match bugs with a target milestone of “3.5”. But, since it’s not always that neat and tidy, we decided to make the matches a little fuzzier: a release named “3.5”, “3.5.0”, or “3.5 (Luna)” will–for example–match target milestones named “3.5” ,”3.5M1″, “3.5 M2”, “3.5.0M3”, etc., but will not match “3.5.1” or “3.5.2” (these are considered separate releases).
For help on creating/modifying target milestones, consult the Eclipsepedia wiki.
The current implementation groups bugs by Bugzilla product and component; this seems to work well for releases for most projects (e.g. The Sapphire project’s 8 release). For releases by projects that include subprojects, the subprojects are included in the bug list (assuming that they have similarly-named target milestones). For some releases (e.g. The Eclipse project’s 4.4 release), the bug lists can be quite large, so we may have to noodle a bit on how to make these lists more manageable (the collapsible sections help, I think).
The bug list is displayed on the “Issues” tab (“bugs” just doesn’t seem right, and I’ve never liked the use of the term “ticket” in this context).
The issues page for the Code Recommenders 2.10 release.
If you notice anything anomalous, please open a bug against “Community/Project Management & Portal”.
