Bugreport Milestone Planing
Moderators: Developer, Contributor
-
- Posts: 33
- Joined: 22 Jul 2005, 14:19
Bugreport Milestone Planing
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.
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.
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
Regards,
Victor
Mantis for Mobile Devices?
http://www.futureware.biz/mantiswap
-
- Posts: 33
- Joined: 22 Jul 2005, 14:19
Thanks great Idea for this...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
-
- Posts: 33
- Joined: 22 Jul 2005, 14:19
Yes this Feature was realy good! The Progress View is realy impotant for Software Dev. and ManagementBithunter 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%)")
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/
Regards,
Victor
MantisConnect
http://www.futureware.biz/mantisconnect/
in version?
Hi Victor,
do you have already a plan in which Mantis version do you want to implement it?
do you have already a plan in which Mantis version do you want to implement it?
Sponsoring this work
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
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
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
http://wiki.mantisbugtracker.com/doku.p ... quirements
Regards,
Victor
Mantis Eclipse Plugin
http://www.futureware.biz/mantisconnect
Comments on the requirements
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.
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.
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!
* 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!