8.5 development schedule

[Josh Berkus]

Andrew,

> I thought we discussed that at pgCon in May and rejected it.

That's not what we have in my notes:

http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#CommitFests

Of course, I may have missed some options, a lot of people were talking.

> I have very, very serious reservations about it. I think we need to get
> better about proper triage, especially on the final commitfest, rather
> than moving the effective feature freeze back a whole commitfest.

Thing is, if we're getting 15,000 lines of code we've never seen before
(collectively) at the final commitfest, there's simply no way we're
getting a release out within 3 months of that.

> ISTM we're in danger of becoming dominated by procedures. Let's keep it
> light and loose.

Hmmm ... actually, I think Andrew's right that we don't need a specific
"last commitfest" rule which is special.  Really, any patch which gets
submitted to any commitfest gets returned if it's not ready to be
committed immediately after review.  The only way the last CF is special
is that anything bounced goes to the next version.

We forgot that with the November CF, which is why it dragged on for 3.5
months and burned a lot of people out.   Let's just stick to that this
time and we don't need any new rules.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Robert Haas]

On Wed, Jul 1, 2009 at 1:16 AM, Josh Berkus<josh@...> wrote:
> Hmmm ... actually, I think Andrew's right that we don't need a specific
> "last commitfest" rule which is special.  Really, any patch which gets
> submitted to any commitfest gets returned if it's not ready to be committed
> immediately after review.  The only way the last CF is special is that
> anything bounced goes to the next version.
>
> We forgot that with the November CF, which is why it dragged on for 3.5
> months and burned a lot of people out.   Let's just stick to that this time
> and we don't need any new rules.

Ugh, I disagree.  I agree that we were too generous with letting
people rework patches while the CommitFest was in progress (mostly, we
let people drop off the map for 3 weeks and then come back and say,
oh, here's my revised version).  But you have to allow a certain
amount of reworking as the CommitFest progresses, I think.  Otherwise,
it just takes way too long to get anything done.

Suppose someone submits a patch that has minor issues to the first
CommitFest.  The reviewer points the issues he sees, so the author
fixes the patch up and resubmits to the second CommitFest.  The patch
is now assigned for review again (possibly to a different reviewer),
and one more minor issue is discovered, so the author fixes up the
patch again and resubmits to the third CommitFest.  Upon third review,
it's discovered that one of the comments is poorly written, so the
author fixes it up again and resubmits to the final CommitFest,
whereupon it is committed.  That's about 7 months to get that patch
committed, and it would be twice that if the initial commitfest was to
the SECOND commitfest rather than the first, since the release cycle
would intervene.

What should actually happen is that the whole thing should be handled
by a single reviewer during one CommitFest.  It's much easier to
re-review a patch that you've read through just a few days prior than
it is to review a whole new patch from scratch, so I don't think it's
imposing an undue burden on the reviewers; in fact it should produce a
net REDUCTION in work by concentrating all the work for a particular
patch into a relatively compact period of time.  What WAS a big
problem during the last CommitFest, at least for me, was resubmits
that didn't happen promptly.  I couldn't decide whether I should
continue starting to review new patches, or whether that would lead to
chaos when all the resubmits from the ones I'd previously reviewed
came back around, leaving me with 4 or 5 patches that all needed to be
reviewed at the same time.  So I'm strongly in favor of a very firm
deadline for resubmits: except for very large patches like HS,
resubmits should be required within, say, 96 hours of the time the
review hits the list; otherwise, we bump it.

Basically, if we're too quick to bump patches to the next CommitFest,
there will be only moderate resistance for the first N-1 CommitFests,
but then for the last CommitFest people won't want to be bumped by a
whole major release for what are basically minor issues.  So we'll be
back in a situation where the last CommitFest is the pits.  We have to
find a middle ground where we're bumping things that are truly holding
things up (tying up reviewer resources or unduly lengthening the
CommitFest) but at the same time avoid bumping things so quickly that
we don't really provide a patch authors with a fair shake at getting
something committed in a reasonable period of time.

...Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Simon Riggs]

On Tue, 2009-06-30 at 21:04 +0300, Heikki Linnakangas wrote:

> Merlin Moncure wrote:
> > Given that there is also a lot of work on synchronous replication, is
> > it better to get the HS in so the SR stuff can use that as a baseline,
> > or to triage in both patches together?
>
> Whichever finishes first. Although they're very useful together, there
> is little if any code-level dependency between them. It would be
> dangerous to have one wait for the other, as one or the other could well
> be delayed for some reason. We can't even be sure that both are finished
> in time for 8.5.

Code dependency is not the main worry. Developer and committer time and
attention is our scarcest resource and I expect it to remain so.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Simon Riggs]

On Tue, 2009-06-30 at 09:35 -0400, Robert Haas wrote:

> In any case, we probably need some weigh-in from Heikki and Simon on
> their plans for Hot Standby before we make any decisions...

We discussed this at the developer meeting in May.

I gave a clear commitment to getting Hot Standby into Postgres, and a
wish to see it in 8.5.

I'm going to attempt to get Sync Rep into core first, then Hot Standby.
There are not too many people that have good insight in these areas and
I think we need them all working together to successfully commit
anything to Postgres core that we all agree with. I believe its possible
that individuals may produce working solutions on their own, though I
also believe that constructive teamwork can produce better solutions.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Simon Riggs]

On Tue, 2009-06-30 at 08:33 +0300, Peter Eisentraut wrote:

> Now that 8.4.0 is out the door, development for 8.5devel will be
> opened any day now.  But we haven't discussed the development timeline
> so far.

This is a wonderful thing. Development opening quickly and the idea of a
discussed and explicit dev schedule are both good news.

The differences between proposed schedules seems fairly small, so I have
no comment on them other than expressing happiness that they exist.
Thanks.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Simon Riggs]

On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote:

> Basically, if we're too quick to bump patches to the next CommitFest,
> there will be only moderate resistance for the first N-1 CommitFests,
> but then for the last CommitFest people won't want to be bumped by a
> whole major release for what are basically minor issues.

That is an important point. Remember we are talking about non-committers
here.

Each commitfest needs to be about wrangling in the patches that are
exact or nearly there. Nothing is perfect, especially when the
definition of perfection is not controlled by the patch author. How can
anybody know what will or will not be objected to until the patch is
reviewed?

Committers don't submit perfect patches, they apply them piece by piece,
with comments about "I'll get back to that" or "still thinking of best
way to do it.". Look at the way FOREIGN DATA WRAPPERS got in. Half a
feature, piece by piece (I have zero objection to that, just an
example).

Saying that non-committers need to submit perfect patches or we reject
them just ends up with a pile up. Expecting people that haven't passed a
the bar exam to provide a higher standard of code than those that have
passed the test is obviously not going to work.

--
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

Bruce Momjian <bruce@...> wrote:
 
> I realize there is the perception that the large patches that were
> eventually rejected held up the release, but for all the patches I
> can think of, they were not rejected immediately _because_ we had
> other valid patches to work on.  Once all valid patches were
> applied, we were quickly able to reject the large unready patches.
>
> So, rejecting the large patches earily would not have significantly
> moved the release date earlier.
 
Like Robert, I'm extremely skeptical of this claim, for the same
reasons.
 
However, even the *possibility* that this could be true is pretty
scary.  If we need to effectively shut down new development for seven
months at the end of a release, in addition to the interim commit
fests, we'd better get a handle on why, so that can change.  To what
do you attribute the extended time needed to handle the final CF?
How can that be made better?
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Josh Berkus]

> Ugh, I disagree.  I agree that we were too generous with letting
> people rework patches while the CommitFest was in progress (mostly, we
> let people drop off the map for 3 weeks and then come back and say,
> oh, here's my revised version).  But you have to allow a certain
> amount of reworking as the CommitFest progresses, I think.  Otherwise,
> it just takes way too long to get anything done.

Sure.  The key is "a *certain amount* of reworking".  Not failing to
respond to review for 3 weeks at a time.  Not introducing APIs or syntax
extensions which have never been discussed on -hackers before.  Not
extensive performance testing.  Not saying "here's 3 parts out of 5 of
the patch, I'll have the other two by the 15th". Not sumbitting a patch
with no written specification or (for user-facing features) documentation.

That is, the *submitter* should at least think the patch is ready to go.
  If people are submitting stuff they *know* isn't ready to commit, it
should be with a "WIP" flag, which to the reviewers says "review this
last, or not at all if we run out of time".

And, even if the submitter is being responsive, if we've spent 30 days
being back-and-forth with the patch, it's just not ready.  Dragging that
out to 60 days doesn't, according to our history, help.

 > I also believe, although I cannot prove it, that it would have
 > increased the pressure to get the remaining items dealt with.  When
 > there are 100 patches, everyone can say "oh, well it doesn't matter
 > whether I get this taken care of today, because there will still be 99
 > other patches".  When there are 3 patches, that argument doesn't hold
 > water.

I agree.  Closing out 11/08 accelerated once we were down to the last 5
patches.

 > If we need to effectively shut down new development for seven
 > months at the end of a release, in addition to the interim commit
 > fests, we'd better get a handle on why, so that can change.  To what
 > do you attribute the extended time needed to handle the final CF?
 > How can that be made better?

Exactly.  What I think we should be moving towards is the idea that
*any* commitfest could, with another 30 days of housekeeping, become a
final release.  The only way to release in a timely fashion is to always
be ready to release -- this is not just my opinion, but the experience
of the Ubuntu, Parrot, and several other projects.

Let me point out a worrisome trend:

7.2: 10 months
7.3: 9 months
7.4: 12 months
8.0: 13 months
8.1: 11 months
8.2: 13 months
8.3: 14 months
8.4: 16 months

That's a dangerous-looking progression.  What's worse is that the
increasing time has always been associated with post feature-freeze;
i.e. the not-fun post-development period.

Until we embrace the idea that patches will get integrated or rejected
in a timely fashion, and that we *can* make a target release date, we
won't.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Robert Haas]

On Wed, Jul 1, 2009 at 10:30 AM, Kevin
Grittner<Kevin.Grittner@...> wrote:

> Bruce Momjian <bruce@...> wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I
>> can think of, they were not rejected immediately _because_ we had
>> other valid patches to work on.  Once all valid patches were
>> applied, we were quickly able to reject the large unready patches.
>>
>> So, rejecting the large patches earily would not have significantly
>> moved the release date earlier.
>
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

Hear, hear!

Tom wrote upthread:
# If you find yourself with nothing else to do except review a new patch
# during beta, then sure, go do it.  But is there *really* nothing you
# could be doing to help expedite the beta?

My honest answer to this question is that I have no idea. It was
pretty clear to me what I was supposed to be doing during CommitFest
(reviewing patches) but a lot less clear to me what I should be doing
during beta.  I know that there was an open items list, but it was
never really clear to me how I should help with that.   A lot of the
open items were pretty mushy, subjective issues, or that was how they
seemed to me - not so much "How are we going to fix this?" but "Is
this worth fixing?" and "What kind of fix is appropriate?".  IOW, what
they needed before any useful technical work could be done was
consensus.

Of course, both committers and non-committers need consensus to make
changes, but committers need a lot less consensus.  If no one strongly
objects, they just apply.  Non-committers, on the other hand, need the
affirmative support of a committer to actually perform the commit.
It's a lot easier to get to "no one things this is a really bad idea"
than it is to get to "one of these six people thinks this is a good
idea and that person is willing to devote an hour of their day (or
more) to making it happen".

It seems to me that the solution to this problem is pretty simple.
Committers need to say exactly what kind of help they want; they need
to affirmatively tell other people what to do.  If Tom wants someone
to develop a patch for bug XYZ, he should say that he is prepared to
apply such a patch and ask for volunteers.  That helps path authors in
three ways:

1. Prospective patch authors know that Tom thinks this is important
and that it could hold up the release.
2. Prospective patch authors know that this isn't something that Tom
is already working on.
3. Prospective path authors know that they have a good chance of
getting something applied quickly, without waiting 1-7 months for the
next CommitFest.

I think committers are reluctant to do this for fear of being seen as
pushy, or for fear of being seen to use their status as committers as
way to throw their weight around.  In fact, I've heard more than one
committer make statements of the form, well, we don't really have any
more weight to throw around than anyone else.  The problem with this
is that it's blatantly false, and no non-committer who has taken the
time to write a patch is under any contrary illusion.  If a hamster
and an elephant are trying to sit on the same bench, the hamster does
not want the elephant to assert that he is a hamster; he wants the
elephant to announce his choice of seat prior to putting his bottom in
it.

...Robert

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Ron Mayer]

Tom Lane wrote:
> "Joshua D. Drake" <jd@...> writes:
>> We already push and pull our release dates based are what in the queue,
>> we just do so informally. Why not just make it part of the process?
>
> I think we used to do it more or less like that, but people didn't like
> it because they couldn't do any long-range planning.

Does the current system help long-range planning?

I could imagine an enterprise plan that says "we'll upgrade to
the current production release in January [after christmas sales]";
or "we'll begin to upgrade the January after [feature-x] is in
production".

But in neither case does it help my long term planning to know if
the current version January release is scheduled to be called 8.4
or 8.5 or 9.1 (which is really all that the current system helps
me predict).


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Joshua Tolley]

On Wed, Jul 01, 2009 at 11:51:28AM -0400, Robert Haas wrote:

> Tom wrote upthread:
> # If you find yourself with nothing else to do except review a new patch
> # during beta, then sure, go do it.  But is there *really* nothing you
> # could be doing to help expedite the beta?
>
> My honest answer to this question is that I have no idea. It was
> pretty clear to me what I was supposed to be doing during CommitFest
> (reviewing patches) but a lot less clear to me what I should be doing
> during beta.  I know that there was an open items list, but it was
> never really clear to me how I should help with that.

My feelings as well. During beta, there was clearly work for those with
experience in the areas with open items, and probably for committers
generally, but each time I reviewed the open items list I found little I could
do to help. If there's something I should have found, I'd love for someone to
point it out; in the meantime I tested betas and release candidates in
situtations common to my use of PostgreSQL, and found that it worked to my
satisfaction, after which I was left trying to figure out what to do, and
started dabbling in a patch or two that interested me.

> If a hamster
> and an elephant are trying to sit on the same bench, the hamster does
> not want the elephant to assert that he is a hamster; he wants the
> elephant to announce his choice of seat prior to putting his bottom in

Thanks, Robert -- this made me giggle :)

--
Joshua Tolley / eggyknap
End Point Corporation
http://www.endpoint.com

[Kevin Grittner]

Ron Mayer <rm_pg@...> wrote:
 
> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".
>
> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).
 
It would help with that if you didn't plan on features which had not
been committed, and the release date didn't slip.  It's been a little
embarrassing at times to have told people not to try to mitigate
performance problems on the application side because I've confirmed
that the semijoin / antijoin code already committed to the 8.4 release
solves the problem, and the release was expected around the start of
the year.
 
Ultimately, I don't know that it makes sense to plan on any
feature until its patch is accepted, so the best you can do is try to
plan on when the accepted patches will become available.  Almost by
definition, if you want a guarantee that the feature will be in some
release, the date of the release becomes unknowable in advance.
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Alvaro Herrera-7]

Ron Mayer wrote:

> But in neither case does it help my long term planning to know if
> the current version January release is scheduled to be called 8.4
> or 8.5 or 9.1 (which is really all that the current system helps
> me predict).

The numbering is typically decided near the end of the devel cycle; it's
not set in stone from the beginning.  Witness how 8.0 was slated to be
called 7.5 until it was almost ready ...

--
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Kevin Grittner wrote:

> Bruce Momjian <bruce@...> wrote:
>  
> > I realize there is the perception that the large patches that were
> > eventually rejected held up the release, but for all the patches I
> > can think of, they were not rejected immediately _because_ we had
> > other valid patches to work on.  Once all valid patches were
> > applied, we were quickly able to reject the large unready patches.
> >
> > So, rejecting the large patches earily would not have significantly
> > moved the release date earlier.
>  
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>  
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

We had many patches that had been through previous commit-fests with
minor adjustments and we had to finalize them before we could close the
final commit-fest.  To be clear I am talking about patches that were
eventually applied in 8.4, not patches that were rejected for 8.4.

--
  Bruce Momjian  <bruce@...>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

Bruce Momjian <bruce@...> wrote:
> Kevin Grittner wrote:
>> To what do you attribute the extended time needed to handle the
>> final CF? How can that be made better?
>
> We had many patches that had been through previous commit-fests with
> minor adjustments and we had to finalize them before we could close
> the final commit-fest.  To be clear I am talking about patches that
> were eventually applied in 8.4, not patches that were rejected for
> 8.4.
 
Thanks.  That answers the first question.
 
I guess it suggests that the second question could be refined to:
 
What could have been done to finalize these patches in earlier
commit-fests or bump them to 8.5 before they dragged the process of
wrapping the release by half a year?
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Tom Lane-2]

Ron Mayer <rm_pg@...> writes:
> Tom Lane wrote:
>> I think we used to do it more or less like that, but people didn't like
>> it because they couldn't do any long-range planning.

> Does the current system help long-range planning?

> I could imagine an enterprise plan that says "we'll upgrade to
> the current production release in January [after christmas sales]";
> or "we'll begin to upgrade the January after [feature-x] is in
> production".

You have forgotten the context.  This discussion is not about end-user
planning, it is about developer planning.  The issue is whether a
developer should work on feature A that he thinks will take about X
months to finish, or feature B that he thinks will take Y months.
For this purpose it is useful to have an idea of how long it will
be until the next feature freeze.  How long after that the release
will actually hit the street is interesting, but not directly relevant
to whether he's got a chance to get the feature in.

                        regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Kevin Grittner wrote:

> Ron Mayer <rm_pg@...> wrote:
>  
> > I could imagine an enterprise plan that says "we'll upgrade to
> > the current production release in January [after christmas sales]";
> > or "we'll begin to upgrade the January after [feature-x] is in
> > production".
> >
> > But in neither case does it help my long term planning to know if
> > the current version January release is scheduled to be called 8.4
> > or 8.5 or 9.1 (which is really all that the current system helps
> > me predict).
>  
> It would help with that if you didn't plan on features which had not
> been committed, and the release date didn't slip.  It's been a little
> embarrassing at times to have told people not to try to mitigate
> performance problems on the application side because I've confirmed
> that the semijoin / antijoin code already committed to the 8.4 release
> solves the problem, and the release was expected around the start of
> the year.

Where did you see 8.4 was scheduled to be released around the start of
the year?  I never never seen that and would have disputed anyone saying
it publicly.

--
  Bruce Momjian  <bruce@...>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Joshua D. Drake]

On Wed, 2009-07-01 at 13:39 -0400, Bruce Momjian wrote:

> Where did you see 8.4 was scheduled to be released around the start of
> the year?  I never never seen that and would have disputed anyone saying
> it publicly.

As I understood it, 8.4 was supposed to released at the beginning of Q2.
I never heard or read beginning of the year either.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@...
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Kevin Grittner]

Bruce Momjian <bruce@...> wrote:
> Where did you see 8.4 was scheduled to be released around the start
of
> the year?  I never never seen that and would have disputed anyone
saying
> it publicly.
 
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
 
That showed a January 1 beta release and a March 1 production release.
 
-Kevin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Joshua D. Drake]

On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote:

> Bruce Momjian <bruce@...> wrote:
> > Where did you see 8.4 was scheduled to be released around the start
> of
> > the year?  I never never seen that and would have disputed anyone
> saying
> > it publicly.
>  
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php
>  
> That showed a January 1 beta release and a March 1 production release.

Right that would be the expectation I had.

Joshua D. Drake

--
PostgreSQL - XMPP: jdrake@...
   Consulting, Development, Support, Training
   503-667-4564 - http://www.commandprompt.com/
   The PostgreSQL Company, serving since 1997


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers