> > Maybe the core team should take a look at the TODO list, and split it over
> > the next couple of release cycles. Then you can just say, when a and b and
> > c have been achieved, and are stable, then we release 6.x
> I would be nice if we could do that, but people work as they have time
> and interest in certain areas. Also, things get fixed as people find
> problems and we become more capable with the source code.
I used to be more certain that at least a "notice of intent" for
future development would help the project. But very little of the
specific improvements and fixes over the last few releases were ones
we would have predicted would happen, and we certainly would not have
gotten the order right.
As Bruce points out, things just seem to happen. And one can't plan
for, for example, Tom Lane getting bit by the bug and becoming a major
contributor over the last few months. We've gotten very far (farther
than I would have imagined) by letting others come up with ideas for
improvements. The core group ain't as smart as you might think ;)
Though it drove me nuts earlier, resisting the temptation to cast into
concrete a short- or medium-range plan has been a real plus for the
project as a whole. We don't very often reject ideas which pass the
discussion phase, and people know that their ideas will make it into
the release cycle asap.
otoh, you might consider your suggestion as a "docs project", rather
than firm planning, and one could put some time into taking Bruce's
ToDo list, sorting it into topics, and writing up a more verbose
description for some of the topic areas. Just an idea...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California