Now that we are half-way though the scheduled feature freeze, I wanted
to share my thoughts about this period.

Having just pushed all open items into the patches queue or 8.4 hold
queue, I am seeing that we have many more in-process patches than we
normally do at this stage of the process.  I think there are three
reasons for this:

1)  The patches are not necessarily larger, but are more complex because
much most of the easy TODO items have already been written for previous
PostgreSQL releases.

2)  We have a number of new developers who took on some of these complex
TODO items, and some of the TODO items were significantly beyond the
developer capabilities at the start of the process.

3)  Many of the complex patches are hard to review because they deal
with very complex areas of the code, like reliability or transaction

Our community could probably handle a few of these complex patches, but
the volume for this release is significantly higher than previous
releases.  The community is doing a good job of giving patch writers
feedback and new patch versions are getting generated.  However, this
amount of patch churn is not normal.

There are a few possible results that might come out of this:

1)  Feature freeze will be much longer.
2)  More patches will be postponed for later releases than usual.
3)  Most patches will be included but beta will be longer because
    of bug fixing.
4)  Most patches will be included but beta will not be any longer.

I think we all hope for #4, but right now, I don't know the probability
of that.  We are going to have to think creatively in the coming weeks
to increase the likelihood of a #4 result.  However, right now, I can't
think of what we can do to improve the odds.  I think the community has
to come up with ideas on how to accomplish this.

[ FYI, I leave on a 2-week trip tomorrow/Friday.]

  Bruce Momjian  <[EMAIL PROTECTED]>

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to