Mantis status meanings

What do these mean?

Status:
 - feedback
 - acknowledged
 - confirmed
 - pending
 - testing
 - resolved (how is this different than closed?)

I searched the forums on: 'mantis status,' but couldn't find anything definitive.  Specifically, I often file a bug and fix it at the same time, and never know what status to pick.

Thanks.
Sean

  The developer(s) are asking the reporter for more information, should
of course be accompanied by one or more posts with the questions.

>  - acknowledged

  The developer(s) acknowledge the receipt of the report and that they
understand it sufficiently to investigate further.

>  - confirmed

  The developer(s) have tested and can confirm that the report is
essentially the accurate and that there is sufficient information to
seek a solution.

In my opinion these last two are nearly synonymous and either one or the
other or both could be used.  Keep in mind that not every issue goes
through every status, in fact I would say that is rarely the case.

>  - pending

  A proposed fix is attached to the report (feedback status may also be
used to request comments on one or more proposed fixes).  This is
another status that is rarely used in my opinion.

>  - testing

 This is much like pending except perhaps further emphasizing that
testing of one or more proposed fixes is requested.

>  - resolved (how is this different than closed?)

  For our purposes this status very specifically means that a fix has
been added to Trunk, but that a new  official version of Squeak has not
been released with the fix applied.  This is also the status if
development snapshots have been released with the fix.

 - closed

This means that the issue is over and done completely.  Either an
official version has been released with the issue addressed (please
indicate the version) or a decision has been made that the report is in
error, or is not be addressed, etc.

>
> I searched the forums on: 'mantis status,' but couldn't find anything
> definitive.  Specifically, I often file a bug and fix it at the same time,
> and never know what status to pick.

Generally speaking if the reporter supplies a fix there is no particular
need to change the status.  I suggest at most you set it at feedback,
indicating you would like opinions on the fix.

>
> Thanks.
> Sean
> --

Sure,

Ken

> View this message in context: http://forum.world.st/Mantis-status-meanings-tp2528870p2528870.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.

Thanks for the detailed explanation!  Where can we put this so it will be available for new contributors?

Sean

> -------- Original Message --------
> Subject: [squeak-dev] RE: Mantis status meanings
> From: "Sean P. DeNigris" <[hidden email]>
> Date: Mon, September 06, 2010 4:47 pm
> To: [hidden email]
>
>
> Thanks for the detailed explanation!  Where can we put this so it will be
> available for new contributors?

Perhaps you can suggest where a new contributor would look.  I put
documentation into the Docs area of the website years ago but it seems
users rarely look there.

Ken

>
> Sean
> --
> View this message in context: http://forum.world.st/Mantis-status-meanings-tp2528870p2528906.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.

On Sep 6, 2010, at 5:57 PM, Ken Causey wrote:
> Perhaps you can suggest where a new contributor would look.  I put
> documentation into the Docs area of the website years ago but it seems
> users rarely look there.

I actually did look in http://bugs.squeak.org/proj_doc_page.php before posting, so maybe there.  But otherwise, how about whatever page on squeak.org links to mantis (I can't check right now because squeak.org is down)?

Sean

Let's take a step back...

1.  First of all, perhaps you didn't realize it, but Mantis is out of
style and never really caught on with this community.  For a while some
of us tried to insist its use was the official policy, but it never
really worked.  With the change to the New Community Development Model
it's use is purely optional and few Core Developers use it.  That said,
frankly I see little point in investing a lot of effort into it,
especially since my experience has been that no matter where you put
Documentation it is rarely read.

2.  Would you really say that barring a few details, particularly
regarding the resolved/closed statuses, that my explanation were at all
unlike what you assumed?  The reality is that I would expect most
developers to guess the appropriate meaning in most cases and also the
use of statuses for anyone other than core developers who should mark
issues resolved/closed as appropriate is really optional and
unnecessary.  In general we can deal with whatever a user does regarding
the statuses.

Ken

Ken Causey wrote

...Mantis is... purely optional and few Core Developers use it.

[shocked]  Okay, problem solved.  The "Bug Reporting" link on http://www.squeak.org/Community/ goes right to Mantis, so I always assumed that's how things were done.  Maybe a more appropriate note would be on that page... something along the lines of "We currently use Mantis for issue tracking... got ya!" ;-)

Ken Causey wrote

2.  Would you really say that barring a few details, particularly
regarding the resolved/closed statuses, that my explanation were at all
unlike what you assumed?

I was really just unclear whether I should set a different status because I put a fix in the inbox, but your answers did make things more clear in general, if only to say "don't worry about it."  Thanks again.

My only outstanding question is: should I not bother entering things in Mantis and just upload to the inbox and be done with it?  That would be simpler, obviously, but what's the most helpful?

Sean

Personally I consider more information helpful; sometimes the extra info
is most valuable months after a fix is incorporated and some other
related issue turns up and we try to understand again why a change was
made.  So I'm entirely in favor of using bugs.squeak.org.  However,
there are not that many interested in dealing with issues in Squeak and
especially any more red-tape than necessary; and I'm aware that many see
the need to use Mantis is nothing more than red-tape, and I can
understand that opinion even if I disagree.

As such I agreed with the decision to consider the use of Mantis
optional and to focus as much as possible on making it easier for bug
fixers.  I think in a few cases we are going to regret not having some
information, but it hasn't happened yet to my knowledge, and may not.

So, if you are happy to use Mantis, please do.  If you also submit your
fix to the Inbox, even better.  Or you can skip Mantis and post it
directly to the Inbox.  It's up to you, just make some effort with the
package version comment if you would.

Ken

>
> Sean
> --
> View this message in context: http://forum.world.st/Mantis-status-meanings-tp2528870p2529121.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.

On 9/6/2010 8:32 PM, Sean P. DeNigris wrote:
> Ken Causey wrote:
>> ...Mantis is... purely optional and few Core Developers use it.
> [shocked]  Okay, problem solved.  The "Bug Reporting" link on
> http://www.squeak.org/Community/ goes right to Mantis, so I always assumed
> that's how things were done.  Maybe a more appropriate note would be on that
> page... something along the lines of "We currently use Mantis for issue
> tracking... got ya!" ;-)

The reality is that Mantis is completely overloaded with old crap. And
we lack the man power to keep it current (if you're willing to help
you're more than welcome). I think that what we should probably do is to
just close all bugs older than two years to get a handle on it. Or
perhaps close 'em all and start over. The real problem with bug trackers
is that if they're not kept current all the time they tend to simply
overflow.

> My only outstanding question is: should I not bother entering things in
> Mantis and just upload to the inbox and be done with it?  That would be
> simpler, obviously, but what's the most helpful?

At this point, the most effective approach is likely to just upload to
the inbox. Since uploads are posted here we see them (we don't see bugs
on Mantis that are posted, fixed, etc. - one of the major shortcomings).
If the fix looks all right you've got a chance it'll be in. And if you
provide a test, you got a *good* chance it'll go in.

Cheers,
   - Andreas

Andreas,

On 9/7/10, Andreas Raab <[hidden email]> wrote:
> On 9/6/2010 8:32 PM, Sean P. DeNigris wrote:
>> Ken Causey wrote:
...snip...
>
> The reality is that Mantis is completely overloaded with old crap. And
> we lack the man power to keep it current (if you're willing to help
> you're more than welcome). I think that what we should probably do is to
> just close all bugs older than two years to get a handle on it.

I support this proposal. We could just mark them as 'Expired' with a
note saying something like.

"This bug has not had any attention for more than two years so it is
considered to be 'Expired' and was closed. It might be that the issue
has been addressed in the latest Squeak 4.1 trunk image, it might as
well be that the issue is still open or it could be that it does not
apply anymore. If you are interested in this bug please do further
investigations and consider reopening it again".



 Or
> perhaps close 'em all and start over. The real problem with bug trackers
> is that if they're not kept current all the time they tend to simply
> overflow.

YES.


>> My only outstanding question is: should I not bother entering things in
>> Mantis and just upload to the inbox and be done with it?  That would be
>> simpler, obviously, but what's the most helpful?

Inbox is fine and we do not want to force people to use it. However
for documentation issues we (Michael, Casey, Sean and me) want to give
it a try. Our efforts have been modest so far but we want to do what
is possible with our time constraints.

BTW there is an RSS feed of open documentation issues
http://bugs.squeak.org/issues_rss.php?project_id=5&filter_id=947


> At this point, the most effective approach is likely to just upload to
> the inbox. Since uploads are posted here we see them (we don't see bugs
> on Mantis that are posted, fixed, etc. - one of the major shortcomings).
> If the fix looks all right you've got a chance it'll be in. And if you
> provide a test, you got a *good* chance it'll go in.

Yes.

Hannes

On 07.09.2010, at 17:03, Hannes Hirzel wrote:

-1.

IMHO just closing old bugs is not going to improve anything. What do we gain from doing that?

Closing a bug just because nobody can be bothered to look right now is bad style, IMHO. Somebody took the time to report it. We should honor that.

I do support cleaning up the tracker, and closing tickets that are not relevant anymore. But age of the ticket is no indication of relevance.

- Bert -

On 9/7/10, Bert Freudenberg <[hidden email]> wrote:
I wanted to check out what kind of issues we are talking about, so I went to

http://bugs.squeak.org/view_all_bug_page.php

I have chosen 'Resolution' = open
sort by 'Last Update - ascending'

I get over 1000 issued, the the ones which are resolved are there as
well, so I did not succeed.

Could somebody who knows more about Mantis provide a filter please?

--Hannes

On 9/7/2010 8:03 AM, Hannes Hirzel wrote:
What do peopple think of the idea of starting over? From what I've seen
at Google code I much prefer their issue tracker. And there's a wiki
associated with it that can hold information such as we just discussed.

Cheers,
   - Andreas

2010/9/7 Bert Freudenberg <[hidden email]>

On Tue, 2010-09-07 at 15:58 +0000, Hannes Hirzel wrote: Hide Status = Resolved ("and above" is implied and shows when you make
this choice).

Ken

Hi,

Am 07.09.2010 um 17:39 schrieb Bert Freudenberg <[hidden email]>:
> IMHO just closing old bugs is not going to improve anything. What do we gain from doing that?
> ...
> I do support cleaning up the tracker, and closing tickets that are not relevant anymore. But age of the ticket is no indication of relevance

do you mean "look at all of the old bugs, try to reproduce them, and keep them if they can be reproduced"?

I'd second that ...

Best,

Michael

CC'd Etoys list.

I was waiting for someone to say this. If people aren't using mantis, could it be that mantis is ill-suited to the current process?

Maybe we don't need a bug database (I cringe, but it could be true.) Maybe we need a different tool, though.

How is Jira working out for the Etoys crowd?

FWIW, I think it's worth archiving mantis (if not just write-locking it somehow) if we did decide to put a bullet in it.



On Sep 6, 2010, at 9:26 PM, Andreas Raab <[hidden email]> wrote:

I just sampled a few entries in Compiler/Kernel/Collections categories.

Some are already fixed and should be closed already.

Some are still not fixed while they should.

Some are not accurate enough or don't give a recipe for reproducing.
In this case, I propose we send feedback requests with a deadline
(like 4 weeks or so) before closing.

Now I don't know how to purge about 1000 entries. That's a huge task
and can only be a collective distributed task.

Nicolas

2010/9/7 Michael Haupt <[hidden email]>:

Below...

On Sep 7, 2010, at 9:01 AM, Andreas Raab <[hidden email]> wrote:

> What do peopple think of the idea of starting over? From what I've seen at Google code I much prefer their issue tracker. And there's a wiki associated with it that can hold information such as we just discussed.

What's Ken Causey think about that? One less web app to keep up, OTOH, introduces a potential dependency on a service we don't control.

I think it's a fine idea myself, but I'd like to see the existing bug DB be preserved while the community figures out what works.

On 07.09.2010, at 21:40, Casey Ransberger wrote:

> CC'd Etoys list.
>
> I was waiting for someone to say this. If people aren't using mantis, could it be that mantis is ill-suited to the current process?
>
> Maybe we don't need a bug database (I cringe, but it could be true.) Maybe we need a different tool, though.
>
> How is Jira working out for the Etoys crowd?

Not too well. It's not really suited to our needs. It seems geared toward tracking agile development with deadlines. But e.g. I can't set a ticket's status to "feedback needed" or "testing needed".  Or add a cc to some other developer (a feature I liked about Trac). While it may be an excellent tool for some, I find most of its features useless to us.

If I could easily migrate all the tickets with their history to a new tracker I'd be a happy camper. It's not so simple unfortunately, and also a lot of URLs would break. Some redirect magic might solve this but it's all work nobody has time to spend on, so for now we're stuck with it.

- Bert -