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
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, Pennsylvania 19026
Would a PostgreSQL / PHP solution be practical for the Feature/Bug tracking?
(I'm thinking specifically of the mirrors here.)
-DEJ
Show quoted text
-----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 outFolks,
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
Import Notes
Resolved by subject fallback
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 outFolks,
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
==========================================================================
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.)
-DEJHow '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 outFolks,
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
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.)
-DEJHow 'bout JitterBug? http://samba.anu.edu.au/jitterbug/
or GNATS: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.htmlI'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.
Show quoted text
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 beof
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 allocatingthe
time we have.
Import Notes
Resolved by subject fallback
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
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.)
-DEJHow 'bout JitterBug? http://samba.anu.edu.au/jitterbug/
or GNATS: http://www.cs.utah.edu/csinfo/texinfo/gnats/gnats.htmlI'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 beof
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 allocatingthe
time we have.
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Hi,
How about Bugs, Features and Doc Requests Collector from
Zope progect?
http://www.zope.org/Collector/
Mikhail
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
Import Notes
Reply to msg id not found: YourmessageofTue29Jun1999141612-040037790D6C.BA4763CC@ecoaccess.org | Resolved by subject fallback
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.
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
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
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.
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