Re: Bug tracking (was Re: +/- Inf for float8's)
От | Wim Ceulemans |
---|---|
Тема | Re: Bug tracking (was Re: +/- Inf for float8's) |
Дата | |
Msg-id | 399FBEC7.3B2CA26@nice.be обсуждение исходный текст |
Ответ на | Re: Bug tracking (was Re: +/- Inf for float8's) (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
Peter Eisentraut wrote: > > Tom Lane writes: > > > (a) a bug *tracking* system is not the same as a bug *reporting* > > system. A tracking system will be useless if it gets cluttered > > with non-bug reports, duplicate entries, etc. There must be a human > > filter controlling what gets entered into the system. > > Letting any user submit bug reports directly into any such system is > certainly not going to work, we'd have "query does not use index" 5 times > a day. I consider the current *reporting* procedure pretty good; web forms > are overrated in my mind. > > What I had in mind was more a databased incarnation of the TODO list. I > mean, who are we kidding, we are writing a database and maintain the list > of problems in flat text. The TODO list has already moved to the > TODO.detail extension, but we could take it a bit further. > I maintain my todo items for my projects in a postgres database. But there are a lot of issues to consider there too: - a table of projects (or topics) - a table of todo items with synopsis, full description, ... - a table of versions (item is planned to be solved in version, x.x.x, actually solved in y.y.y) - a table of developers - assign table (projects -> developers, items -> developers) - change type: bug,doc,rfe (request for enhancement),idc (internal design change), ... - change state (accepted, evaluated, fixed, rejected, incomplete, committed, ... - severity or priority of each item, project - search functionality Regards Wim
В списке pgsql-hackers по дате отправления: