Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Automatically-Generated Bug Lists for Releases

DZone's Guide to

Automatically-Generated Bug Lists for Releases

· DevOps Zone ·
Free Resource

Learn how integrating security into DevOps to deliver "DevSecOps" requires changing mindsets, processes and technology.

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.

The issues page for the Code Recommenders 2.10 release.

If you notice anything anomalous, please open a bug against “Community/Project Management & Portal”.

Learn how enterprises are using tools to automate security in their DevOps toolchain with these DevSecOps Reference Architectures.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}