Обсуждение: User requests now that 6.5 is out
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
On Tue, 29 Jun 1999, Fred Wilson Horch wrote: > 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. MySQL is *not* an RDBMS...our comparision chart compares RDBMSs... > 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. 'scheduales' are *generally* accepted as being 3 months of development plus 1 of testing, so a 4 month release scheduale. More realistically, its slightly longer, with this one being the most "out of sync" yet, but alot of good came out of that, IMHO... > > 3. Fix the PostgreSQL user gallery (linked from > http://www.postgresql.org/helpus.html). Working on it... Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> 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. These are all good ideas. The problem is getting someone to devote the time to it. We normally focus on announcing features as they are completed, not tracking features and request counts. They would be of value, but we have to weigh the value against actual development time. It would certainly be nice to have all the things you mention, but considering our time is limited, I think we are properly allocating the time we have. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Fred Wilson Horch <fhorch@ecoaccess.org> writes:
> 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.
This requires a degree of community agreement about what to do next
that I doubt you will see coming to pass around here. Check the hackers
archives from a couple weeks ago to observe my dismal failure at
creating a consensus on goals for 6.6 --- never mind further-out
releases.
Reality is that features get added when someone is sufficiently
motivated to do them (and doesn't have anything else he considers
higher priority). Many things are on people's to-do lists, but
I think trying to make a schedule saying "this feature will be in
release such-and-such" would be an exercise in wishful thinking.
At this point I doubt we could even say what will be in 6.6 with
any great confidence.
> 4. Provide a better feature request method.
This might be a worthwhile idea. Again, though, I think most of the
developers are driven by what they personally need and/or find
interesting to work on more than by the volume of requests for a
given feature. What would be valuable would be the ready availability
of the secondary documentation aspects you mention:
> 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
since that would (I hope) cut down repetition on the mailing lists.
> 5. Install a bug tracking system.
We desperately need a better system than we have, IMHO; the visibility
of bug status is just horrible. But finding the manpower to set up
a better system is a problem :-(
Since some folks have mentioned possible sources of bug-tracking
systems, I'll suggest Mozilla's Bugzilla and related software as
another thing worth looking at, if anyone is feeling motivated to
go look...
regards, tom lane
On Tue, 29 Jun 1999, Tom Lane wrote:
> > 5. Install a bug tracking system.
>
> We desperately need a better system than we have, IMHO; the visibility
> of bug status is just horrible. But finding the manpower to set up
> a better system is a problem :-(
>
> Since some folks have mentioned possible sources of bug-tracking
> systems, I'll suggest Mozilla's Bugzilla and related software as
> another thing worth looking at, if anyone is feeling motivated to
> go look...
Saw that one, but it uses a MySQL backend, and, for some very odd reason,
I'm not willing to install that on my servr :) Anyone want to look at
what it would take to make use of PostgreSQL?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote: > MySQL is *not* an RDBMS...our comparision chart compares > RDBMSs... I don't know much about MySQL. Why isn't it a RDBMS? In any case, if MySQL is lacking some features to qualify as an RDBMS, then all the more reason to include it in the chart and say why! Otherwise people will use it without knowing.
On Tue, Jun 29, 1999 at 09:00:46PM -0300, The Hermit Hacker wrote: > On Tue, 29 Jun 1999, Tom Lane wrote: > > > > 5. Install a bug tracking system. > > > > We desperately need a better system than we have, IMHO; the visibility > > of bug status is just horrible. But finding the manpower to set up > > a better system is a problem :-( > > > > Since some folks have mentioned possible sources of bug-tracking > > systems, I'll suggest Mozilla's Bugzilla and related software as > > another thing worth looking at, if anyone is feeling motivated to > > go look... > > Saw that one, but it uses a MySQL backend, and, for some very odd reason, > I'm not willing to install that on my servr :) Anyone want to look at > what it would take to make use of PostgreSQL? I implemented (well, ported) the bug tracking system we use at Be. It is Apache/PHP/Postgres and seems to be working just fine with about 22,000 records. I would be willing to modify it and set it up, but am currently lacking somewhat in bandwidth. I may be lacking in hardware depending on the amount of traffic.
The Hermit Hacker wrote: > > On Tue, 29 Jun 1999, Tom Lane wrote: > > > > 5. Install a bug tracking system. > > We've been using keystone (which I got from a reference on the old postgresql web-site ;-)) for a while and it is really quite neat. It runs on postgres and php. Only problem is that the web pages are very nice, but can get kind-of slow to load if you are only on the end of a very slow line. Also, it isn't entirely free (only free for small groups). It may of course be possible to come to some arrangement, as they are using postgres and it is free advertising. url is http://www.stonekeep.com Adriaan
> I implemented (well, ported) the bug tracking system we use at
> Be. It is Apache/PHP/Postgres and seems to be working just fine with about
> 22,000 records. I would be willing to modify it and set it up, but am
> currently lacking somewhat in bandwidth. I may be lacking in hardware
> depending on the amount of traffic.
Presumably the long-term hosting would be most conveniently done at
hub.org (which hosts the Postgres project). scrappy has great
bandwidth and the accessibility has (almost) always been very good,
even if it *is* housed in some trapper's cabin in the Great White
North...
I'm sure that access (an account, etc) can be arranged once we settle
on the system to try first. Does the BeOS system have an external
interface we can look at, or is it only used in-house? I should point
out that you're the first person to actually offer to do the work with
a concrete proposal, which is what we'll need to get anything going ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California