From: Gianluca S. <gi...@gm...> - 2007-07-26 08:40:54
|
I just realized in the summary page, the "Resolved" column of the "By Date" table does not take into account bugs closed directly without passing first on the "resolved" state. So a question for everyone: do we want to count them as "resolved" or not? |
From: Jeferson O. <jef...@gm...> - 2007-07-26 16:57:47
|
Gianluca Sforna wrote: > So a question for everyone: do we want to count them as "resolved" or not? I do, because it is common (at least here) a developer detect a bug, report an issue, work on it, and himself closes the issue without any external test. In this case the "Resolved" status is skipped but the issue was resolved. Regards, Jeferson Oliveira Brazil Sent by Mozilla Thunderbird http://br.mozdev.org/thunderbird |
From: Jennifer M. <jm...@ps...> - 2007-07-26 17:05:16
|
On Jul 26, 2007, at 12:57 PM, Jeferson Oliveira wrote: > I do, because it is common (at least here) a developer detect a bug, > report an issue, work on it, and himself closes the issue without any > external test. In this case the "Resolved" status is skipped but the > issue was resolved. I agree=97our process works like this from time to time as well. -J.= |
From: Victor B. <vb...@gm...> - 2007-07-26 17:21:40
|
I haven't yet looked at the exact value in the summary page that you are referring to, but in Mantis, we typically consider an issue is resolved if its status is >=3D the configured resolved status. So I believe we should count it. On 7/26/07, Jennifer Mullen <jm...@ps...> wrote: > > On Jul 26, 2007, at 12:57 PM, Jeferson Oliveira wrote: > > > I do, because it is common (at least here) a developer detect a bug, > > report an issue, work on it, and himself closes the issue without any > > external test. In this case the "Resolved" status is skipped but the > > issue was resolved. > > I agree=97our process works like this from time to time as well. > > > -J. > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > mantisbt-dev mailing list > man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Glenn H. <thr...@lo...> - 2007-07-26 17:50:20
|
On 26-Jul-07, at 4:40 AM, Gianluca Sforna wrote: > I just realized in the summary page, the "Resolved" column of the "By > Date" table does not take into account bugs closed directly without > passing first on the "resolved" state. Which table are you referring to? The one headed with 'By Date' has two columns. The number in the second column is the count of bugs submitted in the last x days (where x in the number in the first column). In the other tables, the counts are a snapshot at that instant in time. If a bug is 'closed' when you run the report, it is counted as closed and not resolved. Resolved is anything between the resolved threshold and not closed. None of the values have any notion of time in them. The graphs are also a snapshot in time. The 'Cumulative by Date' graph does not differentiate resolved from closed (both are considered closed). > > So a question for everyone: do we want to count them as "resolved" > or not? > > I would dissent and not count them as 'resolved'. I believe that 'resolved' means that there is some process still to be done before they are closed. If the bug was legitimately closed, there is nothing more to do. (For Mantis, resolved means that the code is in CVS and tested. Closed means it is in a public release. Only non-code affecting issues could go from open directly to closed without being resolved first.) ... Glenn -- Glenn Henshaw Logical Outcome Ltd. e: thr...@lo... w: www.logicaloutcome.ca Mantis Developer and User |
From: Jeferson O. <jef...@gm...> - 2007-07-26 18:13:43
|
Glenn Henshaw wrote: > I believe that > 'resolved' means that there is some process still to be done before > they are closed. If the bug was legitimately closed, there is nothing > more to do. (For Mantis, resolved means that the code is in CVS and > tested. Closed means it is in a public release. Only non-code > affecting issues could go from open directly to closed without being > resolved first.) Interesting point of view. Thinking about it I have noticed that ChangeLog shows all resolved bugs, even when not yet closed, as resolved in version X.x.x. In my scenario, "Resolved" means that some developer have fixed some code, and the test team is working on a test version. When the test is ok, the issue is closed. So "Closed" means that the fix is able to be part of the next release. Considering that between the "Resolved" and "Closed" status some version could be released, and the code wasn't committed yet, shouldn't the ChangeLog consider only the closed issues? Is there some ChangeLog's option to indicate which status should be considered part of a version? Maybe a solution could be a "Released in version" field distinguishing the fixed version from the released one(?). Regards, Jeferson Oliveira Brazil Sent by Mozilla Thunderbird http://br.mozdev.org/thunderbird |
From: Gianluca S. <gi...@gm...> - 2007-07-26 21:42:30
|
On 7/26/07, Jeferson Oliveira <jef...@gm...> wrote: > Thinking about it I have noticed that ChangeLog shows all resolved bugs, > even when not yet closed, as resolved in version X.x.x. In my scenario, > "Resolved" means that some developer have fixed some code, and the test > team is working on a test version. When the test is ok, the issue is > closed. So "Closed" means that the fix is able to be part of the next > release. > > Considering that between the "Resolved" and "Closed" status some version > could be released, and the code wasn't committed yet, shouldn't the > ChangeLog consider only the closed issues? Is there some ChangeLog's > option to indicate which status should be considered part of a version? > Maybe a solution could be a "Released in version" field distinguishing > the fixed version from the released one(?). > I think an option is to mark the version as "Not released" which is doable in the "Manage project" page. IIRC, versions not marked as released are not shown in the Changelog page so your workflow would be: * Create new version as "not released" * Mark bugs as fixed in that release * test bugs until all are closed * mark the version as released * release |
From: Jeferson O. <jef...@gm...> - 2007-07-26 21:50:36
|
Gianluca Sforna wrote: Hi Gianluca! > I think an option is to mark the version as "Not released" which is > doable in the "Manage project" page. IIRC, versions not marked as > released are not shown in the Changelog That's a good suggestion, and I have controlled the release mark of all versions, but at the moment all versions are shown in the ChangeLog. If there is some option to configure what will be shown, please let me know. Regards, Jeferson Oliveira Brazil Sent by Mozilla Thunderbird http://br.mozdev.org/thunderbird |
From: Jeferson O. <jef...@gm...> - 2007-07-26 22:10:59
|
Jeferson Oliveira wrote: > If there is some option to configure what > will be shown, please let me know. By the way, would be good if it was possible to show in ChangeLog some version details, as released date for example. Regards, Jeferson Oliveira Brazil Sent by Mozilla Thunderbird http://br.mozdev.org/thunderbird |
From: Gianluca S. <gi...@gm...> - 2007-07-26 21:36:31
|
On 7/26/07, Glenn Henshaw <thr...@lo...> wrote: > > On 26-Jul-07, at 4:40 AM, Gianluca Sforna wrote: > > > I just realized in the summary page, the "Resolved" column of the "By > > Date" table does not take into account bugs closed directly without > > passing first on the "resolved" state. > > Which table are you referring to? > > The one headed with 'By Date' has two columns. The number in the > second column is the count of bugs submitted in the last x days > (where x in the number in the first column). It HAD two columns until I added 2 more; please see: http://www.mantisbt.org/bugs/summary_page.php > > > > > So a question for everyone: do we want to count them as "resolved" > > or not? > > > > > > I would dissent and not count them as 'resolved'. I believe that > 'resolved' means that there is some process still to be done before > they are closed. If the bug was legitimately closed, there is nothing > more to do. (For Mantis, resolved means that the code is in CVS and > tested. Closed means it is in a public release. Only non-code > affecting issues could go from open directly to closed without being > resolved first.) This exactly why I am in doubt about what to do: if something was not explictly "resolved", it could be something not fixable, or an invalid report, etc so not counting them in the "Resolved" count makes sense. However, if we stick to this interpretation, the colunm Balance will always be slightly "pessimistic" because those bugs will be counted in the Opened colums, but not in the Resolved one. Probably the best would be to exclude, from the "Opened" count, the ones closed w/o being resolved, but that does not sound trivial to implement... |