Thread: RE: [HACKERS] Status report: long-query-string changes

>> > The goal used to be a major release every three months, but we haven't
>> > met that in some time.  And, since it seems like we are now putting
>> > out major releases in order to do significant upgrades and not just
>> > incremental stability improvements, I kinda think that a slower cycle
>> > (six-month intervals, say) might be a more useful goal at this stage.
>> > Has the core group thought about this issue lately?
>> 
>> I got a good laugh on this one.  That we actually planned ahead...  :-)

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
This doesn't include bugs.  Bugs must still be fixed and release in the
point releases, which should be every, say, three months.
As new stuff gets added to the TODO list (not bugs), it gets shuffled into
the release cycle.  This isn't hard to manage once the first one has been
done, and you make a policy of only planning four or so releases ahead.
Then ou can post this plan on the web site, so that people know what stuff
is being worked on.  Of course, CVS management becomes an issue, because if
someone feels like working on something that is not due for two releases,
does it go into the current source tree?  If necessary, you can open up
branches for each planned release, and people can check out whichever one
they feel like working on.  Of course, merging bug fixes becomes more of an
issue.  Actually the more I think about it, the more complex it becomes, but
if the CVS management is not really an issue, then this is a possible
approach.  Otherwise, we'll have to think of something else.
Of course, the core team are responsible for merging changes into the CVS
tree, so they could just implement a policy of only adding new functionality
that is required for the current release.
If somebody desperately wants something added, and can convince the core
team to include it in the current release cycle, then the code can be added
immediately (assuming that somebody has actually done).  Alternatively, they
manage their own source tree, until such time as the code gets included.

MikeA

[Charset iso-8859-1 unsupported, filtering to ASCII...]
> >> > The goal used to be a major release every three months, but we haven't
> >> > met that in some time.  And, since it seems like we are now putting
> >> > out major releases in order to do significant upgrades and not just
> >> > incremental stability improvements, I kinda think that a slower cycle
> >> > (six-month intervals, say) might be a more useful goal at this stage.
> >> > Has the core group thought about this issue lately?
> >> 
> >> I got a good laugh on this one.  That we actually planned ahead...  :-)
> 
> 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.

Hard to plan any of that.

--  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
 

> > 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

Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> 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.

The facts of the matter are that contributors work on the problems that
they find interesting, and/or the things that are getting in the way of
their own use of Postgres at the moment.  If the core team tried to tell
people what to work on, less would get contributed, and that would
benefit no one.

When 6.5 was released, I tried to stir up a little discussion about the
major things to work on for 6.6, and couldn't even get any consensus
on a plan for *one* revision.  So I think a longer-term plan would be
an exercise in wishful thinking.  Things will get done when someone
steps up to the plate and does them.

> 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...

Indeed, the TODO list is awfully bare-bones; many of the entries don't
convey much information to someone who's not already familiar with the
issue.  Something more fleshed-out would be a useful project.
        regards, tom lane