Point 2 is I think necessary. I'm not sure that there is a great
difference between 'open' and 'uncomfirmed', but we could make one if
needed.
We could use 'analyzed' to confirm bugs, sure.
With the other points, I'm wary of making things too difficult for
users to register a bug. I know that it would cut our workload a bit...
but on the whole I think it is better to have a few bogus bug reports
and have us clean them out, then have people feel too intimidated to
submit a bug.
If the user is forced to spend 5 minutes writing a bug instead of 1 minute it won´t intimidate the users that are really interested in getting that bug fixed and writing a proper bug report.
I don't really understand what you mean by 'combine the bug system with
regression testing', as I see these things as being quite seperate. The
bug system is a way for us to track what bugs there are, and what stage
they are at. Regression testing is a way to make sure that they don't
reappear at a later date. In other words, a bug is reported, confirmed
and (hopefully) fixed. A test can be written and plugged in, so that in
future it could be run to make sure the bug has not reappeared. I have
been looking into how to set up some kind of automated testing system,
and I'll get back to y'all at a later date.
I thought that has to be linked somehow. But regression tests (used for automated regression testing) can live in another database, sure.
reagards
--
o----------0-¬---------O-·---¬----o---®-----o o O ° .
| http://www.kiffen.de | pRoteçt y0ur bRaín |0 O ° ¤ °
·
0°·³°²'²³-¹'³´³°^°³~³²³°'³²²¨³²^³¹³²°²³`³º³°Þ °
o © ° . ·
| psychedelic experience | gott@kiffen.de | O ° o °
o-¬--o--0-----©-·--O-----o-----0-¤----------o 0 ° · ° . ¤ ·