Bruce Momjian <bruce(at)momjian(dot)us> 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
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?
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2009-07-01 14:31:06|
|Subject: Re: Extensions User Design |
|Previous:||From: Toshihiro Kitagawa||Date: 2009-07-01 14:25:31|
|Subject: Did COPY performance regression solve in 8.4rc2?|