MantisBT - Site |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0003525 | Site | [All Projects] Suggestion | public | 2018-09-27 04:58 | 2018-12-01 21:47 |
|
| Reporter | WubTheCaptain | |
| Assigned To | Blzut3 | |
| Priority | normal | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
|
| Summary | 0003525: Close MantisBT issues when a new version is released with a fix to that issue & cleanup our tracker |
| Description | I tried to read what the difference is between "closed" and "resolved" ticket statuses. The only hint of processing tickets I've had earlier has been the bar at bottom, which lists everything in sequential order: [ new | feedback | acknowledged | confirmed | assigned | needs review | needs testing | resolved | closed ] It is implied "closed" is the final step for a ticket.
Not all changes need testing. Sometimes there's not even anything to test, or the testing has already been done, so keeping a ticket at "needs testing" until the next software release also pollutes "Roadmap" in MantisBT and makes it more difficult to find unresolved issues. Don't do this!
This and keeping tickets permanently at "resolved" is the primary reason why it's almost hopeless to find an issue properly from "View Issues". Closed issues are hidden there by default, which is exactly how it's supposed to be – to find current issues, unless I opted to search for archived issues not relevant to me today.
After reading the difference and realizing how much of an inconvenience this is (exaggerated), I'm now bothered to see "Site" currently has 41 resolved bugs, Doomseeker has 248, and Zandronum has 1149 (!).
☠#$@&%*!
Every day I'm looking at so many issues "resolved" in my MantisBT view, reminding me a new release should be done because there's so many resolved issues (not closed). I bet damn well to myself I want to see what's resolved for the next release, not what's resolved years ago in some ancient release that already has it resolved! Was it resolved now, or do I still need to read this ticket sitting in My View when I log into the tracker?
Why can I not, unless I'm the reporter of a bug, with "reporter" privileges, reopen a bug marked as "resolved", if it's not actually resolved before the next release? Only I should not be able to reopen such bug if it's been "closed". (NB: There's an "editor" group too. Few people have it. Only those and/or "developers" group members should be able to reopen "closed" bugs.)
I'm fuming. (Nah, just a little bit. But please, let's improve the usability of our tracker.) |
| Steps To Reproduce | |
| Additional Information | Closing bugs exists in practice at least upstream (MantisBT), and I swear by the benefits if this was adopted on Zandronum tracker for all projects. (This ticket should have "urgent" or "immediate" priority. Just kidding.)
MantisBT's official tracker: 7, and only 7 (!) resolved bugs:'https://www.mantisbt.org/bugs/my_view_page.php [^]' (2,259 unassigned bugs). How many "closed" bugs do they have? 12,494!!! That's currently a ratio of ~1:1785 bugs resolved vs closed.
From 2005:
Quote from https://mantisbt.org/forums/viewtopic.php?t=329
For Mantis, we close the issues when the version is released.
From 2014–2015 (MantisBT 1.3.0-beta.1):
Quote from https://www.mantisbt.org/bugs/view.php?id=11396
2010-06-22 21:40 | dhx | Resolution | open => fixed
2010-06-22 21:40 | dhx | Fixed in Version | => 1.3.0-beta.1
2010-06-22 22:48 | dhx | Target Version | 1.2.2 => 1.3.0-beta.1
2014-12-08 00:34 | vboctor | Status | resolved => closed
[url=https://mantisbt.org/blog/archives/mantisbt/416MantisBT 1.3.0-beta.2 was released on 2015-03-17[/url], so even though the issue was resolved 4.5 years earlier, it was only closed once the release was put out. (Excuse me, but there's no blog post about 1.3.0-beta.1 that I can find. This was the closest example to that previous ticket.)
From 2018:'https://www.mantisbt.org/bugs/view.php?id=24741 [^]' – so yeah, this practice (arguably imo "best practice") has existed for at least 13 years.
NB: I'm assigned "developer" project access level in the Doomseeker project on this issue tracker. I am ready and willing to close all appropriate issues for that project and take assignment of this ticket. (I would probably also do so for other projects, but I lack editor permissions.) |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2018-09-27 04:58 | WubTheCaptain | New Issue | |
| 2018-09-27 05:12 | WubTheCaptain | Note Added: 0019789 | |
| 2018-09-27 05:23 | Blzut3 | Note Added: 0019790 | |
| 2018-09-27 13:13 | Pol M | Note Added: 0019791 | |
| 2018-09-27 20:33 | WubTheCaptain | Note Added: 0019792 | |
| 2018-09-29 08:05 | Zalewa | Note Added: 0019805 | |
| 2018-09-29 08:54 | Blzut3 | Note Added: 0019807 | |
| 2018-09-29 13:42 | WubTheCaptain | Note Added: 0019819 | |
| 2018-09-29 15:28 | WubTheCaptain | Note Added: 0019823 | |
| 2018-09-30 19:14 | Torr Samaho | Note Added: 0019846 | |
| 2018-09-30 21:29 | Blzut3 | Assigned To | => Blzut3 |
| 2018-09-30 21:29 | Blzut3 | Status | new => assigned |
| 2018-11-25 22:58 | WubTheCaptain | Note Added: 0020206 | |
| 2018-11-25 23:00 | Blzut3 | Status | assigned => resolved |
| 2018-11-25 23:00 | Blzut3 | Resolution | open => fixed |
| 2018-12-01 21:47 | Blzut3 | Status | resolved => closed |
|
Notes |
|
|
|
|
I'll give you an additional hint why this is an issue: Old "resolved" tickets get bumped up and it fills My View's resolved bugs list. I use that list to find what's newly resolved in Doomseeker or needing attention, especially if I didn't review the ticket as resolved myself. The pace of changes is rapid, and these worthless "resolved" bugs from guess-how-many-years ago keep bumping up in the list. |
|
|
|
(0019790)
|
|
Blzut3
|
|
2018-09-27 05:23
|
|
|
Huh, well I guess it makes sense now that you put it that way. I don't personally care one way or another. I guess I'm kind of surprised Mantis doesn't have a feature to auto close tickets associated with a release if that's how they do things. Certainly would have made their intention a lot more obvious. |
|
|
|
(0019791)
|
|
Pol M
|
|
2018-09-27 13:13
|
|
|
While it will be a titanic and tedious job to close all resolved tickets (unless this can be automated), I think that what Wub said seems reasonable. |
|
|
|
|
|
If Zalewa has no objections, I have an intention to start closing tickets in the Doomseeker project soon. |
|
|
|
(0019805)
|
|
Zalewa
|
|
2018-09-29 08:05
|
|
|
|
|
(0019807)
|
|
Blzut3
|
|
2018-09-29 08:54
|
|
FYI, I don't know about accounts with lesser permissions but Mantis does give me the option to select all and close on the view issues page.
I'll be sure to page the Zandronum developers here during the next meeting. |
|
|
|
|
Quote from Blzut3
FYI, I don't know about accounts with lesser permissions but Mantis does give me the option to select all and close on the view issues page.
Developer group (myself included) have that option. Thanks, I had forgotten this exists. |
|
|
|
|
First pass done with Doomseeker project, almost all but 1.2 tickets closed now (most closed by date range).
Frankly I can't easily find the 4 tickets (well, 2 or 3 of them) which are "resolved" but not targeting 1.1 or 1.2. Maybe that's intended. 0003527 would help finding those tickets, though. |
|
|
|
|
|
Closing resolved tickets after making a release sounds good to me. |
|
|
|
|
|
This is pretty much resolved. |
|