In summary, for a patch to be applied, someone has to understand the
patch and the subsystem it modifies.  In the past, most complex patches
came from experienced developers, so even if no one but the author fully
understood the patch, we could rely on the author to some extent.  With
new people developing complex patches, we don't have the same experience
level of the authors, so we have to do extra work to verify the patch
isn't going to break things.  That is the crux of the difficulty during
the 8.3 feature freeze period.


bruce wrote:
> 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
> semantics.
> 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]>
>   EnterpriseDB                     
>   + If your life is a hard drive, Christ can be your backup. +

  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