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.
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.
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 thedevelopers 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 visibilityfeatures, 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.
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
