Bugreport Milestone Planing

General discussion of Mantis.

Moderators: Developer, Contributor

Post Reply
frentmeister
Posts: 33
Joined: 22 Jul 2005, 14:19

Bugreport Milestone Planing

Post by frentmeister »

Is there a possibility to implement/integrate milestone planning into Mantis ?

We need a more precise mile stone planning system for our project to resolve(....for the next milestone) bug reports in a more structured manner .

If anyone knows of any solution, PLEASE let me know.
vboctor
Site Admin
Posts: 1293
Joined: 13 Feb 2005, 22:11
Location: Redmond, Washington
Contact:

Post by vboctor »

You can create versions and mark them as non-released. You can then use such versions in the fixed-in-version field when resolving bugs. I typically add a "Next Release" version and set the fixed-in-version of all resolved bugs to it. When I'm making the release, I rename "Next Release" to the specific version name and add a new "Next Release".

Regards,
Victor
Mantis for Mobile Devices?
http://www.futureware.biz/mantiswap
frentmeister
Posts: 33
Joined: 22 Jul 2005, 14:19

Post by frentmeister »

vboctor wrote:You can create versions and mark them as non-released. You can then use such versions in the fixed-in-version field when resolving bugs. I typically add a "Next Release" version and set the fixed-in-version of all resolved bugs to it. When I'm making the release, I rename "Next Release" to the specific version name and add a new "Next Release".

Regards,
Victor
Mantis for Mobile Devices?
http://www.futureware.biz/mantiswap
Thanks great Idea for this...
Bithunter
Posts: 11
Joined: 24 Aug 2006, 14:27

Post by Bithunter »

Could be nice to have a feature like the one present in FlySpray, about setting a Milestone and assign bugs to it before solving them, and then you have a general vision about the progress (for example, have a "10 of 20 bugs resolved (50%)")
frentmeister
Posts: 33
Joined: 22 Jul 2005, 14:19

Post by frentmeister »

Bithunter wrote:Could be nice to have a feature like the one present in FlySpray, about setting a Milestone and assign bugs to it before solving them, and then you have a general vision about the progress (for example, have a "10 of 20 bugs resolved (50%)")
Yes this Feature was realy good! The Progress View is realy impotant for Software Dev. and Management
vboctor
Site Admin
Posts: 1293
Joined: 13 Feb 2005, 22:11
Location: Redmond, Washington
Contact:

Post by vboctor »

I'm planning to add support for milestones and roadmap. Once this is done using native fields, then all the other stuff can be easily added.

Regards,
Victor
MantisConnect
http://www.futureware.biz/mantisconnect/
illes
Posts: 30
Joined: 09 Mar 2005, 08:37
Location: Budapest, Hungary

in version?

Post by illes »

Hi Victor,

do you have already a plan in which Mantis version do you want to implement it?
jotango
Posts: 17
Joined: 26 Oct 2006, 12:41

Sponsoring this work

Post by jotango »

Hi vboctor,

I think many advanced users need this kind of functionality. If you open an issue in the mantis bugtracker for it, I think people would sponsor the development (including me). What do you think?

Best regards
vboctor
Site Admin
Posts: 1293
Joined: 13 Feb 2005, 22:11
Location: Redmond, Washington
Contact:

Post by vboctor »

Guys, let me know your opinion about the requirements I wrote in the wiki:

http://wiki.mantisbugtracker.com/doku.p ... quirements

Regards,
Victor
Mantis Eclipse Plugin
http://www.futureware.biz/mantisconnect
jotango
Posts: 17
Joined: 26 Oct 2006, 12:41

Comments on the requirements

Post by jotango »

Victor, my comments:

Database Changes

You may think about renaming the "version" field. For each issue you will now have: version, target_release, fixed_in_version. Version may be better renamed to "occurs_in_version" and "target_release" could be "target_fix_version". You would then have
- occurs_in_version: 1
- target_fix_version: 2
- fixed_in_version: 2

The last 2 may actually be redundant. If an issue is open, it should only have a target_fix_version. Once it is closed, target_fix_version should be equal to fixed_in_version. Perhaps simply rename fixed_in_version to target_fixed_version?

General changes

I would suggest writing (released) or (open) next to the version to reduce mistakes when people filter and assign

Roadmap

My perfect roadmap would be a list of all versions, together with a) the number of assigned issues, b) the number of these which are closed, c) the percentage of closed issues. It should be sorted by the latest closing date to the earliest.
Damien
Posts: 3
Joined: 29 Nov 2006, 03:55

Post by Damien »

Two ideas for small tweaks in relation to this:

* Add target_release to the list of fields accepted on the view-issues page.

* Is there an easy way currently to make this field always show on the add/edit issues pages? I'd like to be able to mark the target release when I'm added an issue.

I do love the feature, though, and the other improvements in v1.1, which I'm already using for production work due to the customizable front view page. Awesome work everyone!
Post Reply