Re: [Mantisbt-dev] Suggestions and fixes

[Kenzaburo I. <pre...@30...>]

Let's see...

1. I've added a version field to the bug table for 0.17.0.  It'll be used 
for milestone support.

2. In for 0.17.0

3. It should automatically be set to assigned if you specify the 
person.  If not it's a bug.  I've never used bugzilla although I've browsed 
mozilla's installation a few times.

4. Should be fixed in CVS.

5. It shows the total number of bugs in the view_all page.

It may sound weird to say this but I actually prefer the traffic to be low 
right now.  I've been overwhelmed by email and maintenance several times to 
the point of not being able to do any development in the last couple months 
(which is one reason I've semi-disappeared).  Unless I can get more people 
to work together, more users and attention just means more tech-support 
emails.  I am also bad about applying patches.  I don't trust code until 
I've read it and most of the time the code isn't formatted as I wish.

I realize there are several major issues regarding Mantis but I really need 
more time or help.  After 0.17.0 is released I plan on having creating 
lists of tasks that I will ask people to help with.  I'm also going to 
start development of 2.0 (partial rewrite) for those who might be interested.

-Ken

>[reposted to -dev, -beta seems dead more or less]
>
>David Jeske said:
>
> > On Thu, Jan 03, 2002 at 01:55:46PM +0100, Martin Wickman wrote:
>
> >> My users have suggested a few features and fixes. Below is
> >> the list, please comment.
>
> >> 1. There should be a field 'Candidate Version' (or 'Target
> >> Version' or such) which contains the product version where
> >> this bug is to be fixed. That way, one can postpone bugfixes
> >> to a certain release of the product.
>
> > I agree. This has been implemented in one Mantis derivative as
> > "Milestone support". It also needs to let you filter bug to those on
> > before a certain milestone, and push all unclosed bugs from one
> > milestone to the next milestone (i.e. because you released that
> > version without them fixed).
>
>Ok. It seems to be a needed feature. I'll add it later next week. Problem 
>is that I sent a patch some week ago (which adds basic authentication 
>etc), but I have not got any response, so I dont know what the current 
>status is.
>
> >> 2. It should be possible to change product version when
> >> updating a bug. If you miss to provide that product version
> >> for a bug, you must recreate the bug. This is a Mantis bug imo.
>
>
> >> 3. When you assign a bug to a person, the status should be
> >> "assigned" automatically. Now you need to do that manually.
>
> > I don't know Ken's motivation, however, I always assumed this was
> > borrowed from Bugzilla. It opens bugs in a "new" state, and then
> > asks users to "accept" them. However, the real reason it does
> > this is that it sends you a nag-email every day for bugs which
> > are "new", encouraging you to check them out and accept them.
> > This assures that you have a chance to see them before they fall
> > together with all the other bugs. Since Mantis does not do this
> > nag email, the "new" status also seems somewhat superfluous to
> > me.
>
>If this is the general consensus, I guess we better change this behaivor then.
>
> >> 4. When you update a bug, you return to the bug in "simple"
> >> view, even though you have preferences sat to alway use
> >> "advanced" view.
>
> >> 5. When using "show bugs", there is no indication how
> >> many bugs there are in total, just the current shown
> >> (filtered) count.
>
> >> I will probably fix these points sooner or later, but
> >> I figured I could get some feedback from you folks first.
>
> >> Also, I think the traffic in these lists are a bit low,
> >> at least when considering the amount of people using Mantis.
> >> I would like to get the discussions going -- thats the only
> >> way to get Mantis to the point where it can compete for real