User requests now that 6.5 is out
От | Fred Wilson Horch |
---|---|
Тема | User requests now that 6.5 is out |
Дата | |
Msg-id | 37790D6C.BA4763CC@ecoaccess.org обсуждение исходный текст |
Ответы |
Re: [HACKERS] User requests now that 6.5 is out
(The Hermit Hacker <scrappy@hub.org>)
Re: [HACKERS] User requests now that 6.5 is out (Bruce Momjian <maillist@candle.pha.pa.us>) Re: [HACKERS] User requests now that 6.5 is out (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Folks, Not sure if this is the right place to request this, but here are some things I, as a satisfied user of PostgreSQL, would like to see done (and I'd be glad to help where I can). All of these are just suggestions geared to the care and feeding of the PostgreSQL user community. 1. Update the comparison chart at http://www.postgresql.org/comp-comparison.html. This is important for those of us who must justify our choice of PostgreSQL to clients, supervisors or funding agencies. Suggestion: add Informix and MySQL and drop BeagleSQL and MiniSQL. 2. Post a schedule for future releases. This is important for those of us who want to know when -- if ever -- we can start to consider PostgreSQL as a solution for projects that require features that are not yet part of PostgreSQL (e.g. replication), and when we should think about upgrading our PostgreSQL installations. It is also crucial to let prospective users know that Postgres is under active development. I know there is a todo list somewhere but I think the schedule needs to be more prominent on the web site. 3. Fix the PostgreSQL user gallery (linked from http://www.postgresql.org/helpus.html). 4. Provide a better feature request method. Mailing lists are a great start. But I'd like to know how many people are requesting which features, whether there is a work-around, if there is a documentation or a terminology issue that causes people to continue to request features that are already in PostgreSQL, and what people have decided to do (upgrade to later version, go with another database, redesign their sytem, etc.). I think two tables would capture this information: one containing feature, which release (if any) of PostgreSQL supports or will support the feature, work-around, documentation issue, and terminology issue; and the other containing reference to feature, name and address of person requesting feature, why feature is needed, and how person resolved the feature request. I assume the PostgreSQL web site can be backed by a PostgreSQL database. Just to clarify, these tables would capture feedback from users (via a web form or e-mail messages) in a more structured and detailed format than a mailing list or the current todo list, and provide a way for PostgreSQL hackers to "close out" feature requests. 5. Install a bug tracking system. I guess the todo list is working pretty well because the quality of the latest release is very good, but I haven't been able to figure where else to search for things that look like bugs to me, except against the mailing lists. Often the discussion of a bug on the (many) mailing lists morphs into something else without appearing on the todo list and I'm left unsure if the bug has been fixed or not. As a user relying on PostgreSQL, I'd feel better if the method used to track bugs was more centralized, transparent and structured. Maybe some of this stuff can be addressed by the new commercial support for PostgreSQL. All in all, PostgreSQL is making great strides and works well. Keep up the good work! Fred Horch
В списке pgsql-hackers по дате отправления:
Предыдущее
От: wieck@debis.com (Jan Wieck)Дата:
Сообщение: Re: [HACKERS] regression bigtest needs very long time