FAQ
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

Search Discussions

  • The Hermit Hacker at Jun 29, 1999 at 6:28 pm

    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
  • Bruce Momjian at Jun 29, 1999 at 6:34 pm

    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, Pennsylvania 19026
  • Jackson, DeJuan at Jun 29, 1999 at 6:53 pm
    Would a PostgreSQL / PHP solution be practical for the Feature/Bug tracking?
    (I'm thinking specifically of the mirrors here.)
    -DEJ
    -----Original Message-----
    From: Bruce Momjian [SMTP:maillist@candle.pha.pa.us]
    Sent: Tuesday, June 29, 1999 1:31 PM
    To: Fred Wilson Horch
    Cc: pgsql-hackers@hub.org
    Subject: Re: [HACKERS] 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.
    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, Pennsylvania 19026
  • Vince Vielhaber at Jun 29, 1999 at 7:19 pm

    On 29-Jun-99 Jackson, DeJuan wrote:
    Would a PostgreSQL / PHP solution be practical for the Feature/Bug tracking?
    (I'm thinking specifically of the mirrors here.)
    -DEJ
    How 'bout JitterBug? http://samba.anu.edu.au/jitterbug/
    or GNATS: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html


    Vince.
    -----Original Message-----
    From: Bruce Momjian [SMTP:maillist@candle.pha.pa.us]
    Sent: Tuesday, June 29, 1999 1:31 PM
    To: Fred Wilson Horch
    Cc: pgsql-hackers@hub.org
    Subject: Re: [HACKERS] 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.
    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, Pennsylvania 19026
    --
    ==========================================================================
    Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
    # include <std/disclaimers.h> TEAM-OS2
    Online Campground Directory http://www.camping-usa.com
    Online Giftshop Superstore http://www.cloudninegifts.com
    ==========================================================================
  • The Hermit Hacker at Jun 29, 1999 at 8:40 pm

    On Tue, 29 Jun 1999, Vince Vielhaber wrote:

    On 29-Jun-99 Jackson, DeJuan wrote:
    Would a PostgreSQL / PHP solution be practical for the Feature/Bug tracking?
    (I'm thinking specifically of the mirrors here.)
    -DEJ
    How 'bout JitterBug? http://samba.anu.edu.au/jitterbug/
    or GNATS: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html
    I've tried GNATs, and didn't really like it...its worked effectively at
    FreeBSD, but...

    Ouch, JitterBug looks painful :(

    I'm willing to install either, but I think that GNATs, from what I'm used
    to of it, is the better one, since it allows for email based bug
    reports...

    Vince.
    -----Original Message-----
    From: Bruce Momjian [SMTP:maillist@candle.pha.pa.us]
    Sent: Tuesday, June 29, 1999 1:31 PM
    To: Fred Wilson Horch
    Cc: pgsql-hackers@hub.org
    Subject: Re: [HACKERS] 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.
    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, Pennsylvania 19026
    --
    ==========================================================================
    Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
    # include <std/disclaimers.h> TEAM-OS2
    Online Campground Directory http://www.camping-usa.com
    Online Giftshop Superstore http://www.cloudninegifts.com
    ==========================================================================

    Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
    Systems Administrator @ hub.org
    primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
  • Jackson, DeJuan at Jun 29, 1999 at 8:52 pm

    On 29-Jun-99 Jackson, DeJuan wrote:
    Would a PostgreSQL / PHP solution be practical for the Feature/Bug
    tracking?
    (I'm thinking specifically of the mirrors here.)
    -DEJ
    How 'bout JitterBug? http://samba.anu.edu.au/jitterbug/
    or GNATS: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html
    I've tried GNATs, and didn't really like it...its worked effectively at
    FreeBSD, but...

    Ouch, JitterBug looks painful :(

    I'm willing to install either, but I think that GNATs, from what I'm used
    to of it, is the better one, since it allows for email based bug
    reports...
    Will it allow for feature requests as well as bug reports/updates?
    And how will this affect the mirrors? Do they have to install the
    same software? Will they get static bug report pages that they update once
    a day?
    I have no clue how the mirroring works.
    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.
  • Mark Hollomon at Jun 29, 1999 at 9:10 pm

    The Hermit Hacker wrote:


    I've tried GNATs, and didn't really like it...its worked effectively at
    FreeBSD, but...

    Ouch, JitterBug looks painful :(

    I'm willing to install either, but I think that GNATs, from what I'm used
    to of it, is the better one, since it allows for email based bug
    reports...
    So does JitterBug.


    --

    Mark Hollomon
    mhh@nortelnetworks.com
    ESN 451-9008 (302)454-9008
  • The Hermit Hacker at Jun 29, 1999 at 9:15 pm

    On Tue, 29 Jun 1999, Jackson, DeJuan wrote:
    On 29-Jun-99 Jackson, DeJuan wrote:
    Would a PostgreSQL / PHP solution be practical for the Feature/Bug
    tracking?
    (I'm thinking specifically of the mirrors here.)
    -DEJ
    How 'bout JitterBug? http://samba.anu.edu.au/jitterbug/
    or GNATS: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.html
    I've tried GNATs, and didn't really like it...its worked effectively at
    FreeBSD, but...

    Ouch, JitterBug looks painful :(

    I'm willing to install either, but I think that GNATs, from what I'm used
    to of it, is the better one, since it allows for email based bug
    reports...
    Will it allow for feature requests as well as bug reports/updates?
    And how will this affect the mirrors? Do they have to install the
    same software? Will they get static bug report pages that they update once
    a day?
    I have no clue how the mirroring works.
    The mirrors are pretty much only those that are 'static'...anything using
    a database backend (or similar...ie. ht/Dig) are purely on the main
    site...
    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.
    Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
    Systems Administrator @ hub.org
    primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
  • Mikhail Terekhov at Jun 29, 1999 at 9:39 pm
    Hi,

    How about Bugs, Features and Doc Requests Collector from
    Zope progect?
    http://www.zope.org/Collector/
    Mikhail
  • Tom Lane at Jun 29, 1999 at 10:12 pm

    Fred Wilson Horch 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
  • The Hermit Hacker at Jun 30, 1999 at 12:02 am

    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
  • Chris Bitmead at Jun 30, 1999 at 12:03 am

    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.
  • Mike Embry at Jun 30, 1999 at 1:19 am

    Mark Hollomon wrote:

    The Hermit Hacker wrote:

    I've tried GNATs, and didn't really like it...its worked effectively at
    FreeBSD, but...

    Ouch, JitterBug looks painful :(

    I'm willing to install either, but I think that GNATs, from what I'm used
    to of it, is the better one, since it allows for email based bug
    reports...
    So does JitterBug.
    How about W3PDB? http://www.bawue.de/~mergl/export/w3pdb-0.20.tar.gz

    It was written by Edmund Mergl and uses PostgreSQL + Apache to provide
    a GNATS-like database enabled problem tracking system. I'm using
    WWWGNATS which is very dated but was the best Open Source option 5
    years or so ago. I looked at moving from GNATS to W3PDB but haven't
    had the time. Looked promising though.

    There's also bugzilla. http://bugzilla.mozilla.org/

    MikE
  • Adam Haberlach at Jun 30, 1999 at 1:43 am

    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.
  • Adriaan Joubert at Jun 30, 1999 at 5:36 am

    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
  • Oleg Broytmann at Jun 30, 1999 at 8:01 am
    Hi!
    On Tue, 29 Jun 1999, Mikhail Terekhov wrote:
    How about Bugs, Features and Doc Requests Collector from
    Zope progect?
    http://www.zope.org/Collector/
    Collector is based on ZTable, which is commercial. DigiCool announced
    they will open ZTable Core sometime in the future, probably Collector will
    be open too.
    Mikhail
    Oleg.
    ----
    Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
    Programmers don't die, they just GOSUB without RETURN.
  • Thomas Lockhart at Jun 30, 1999 at 1:42 pm

    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

Related Discussions

People

Translate

site design / logo © 2022 Grokbase