Re: postponing some large patches to 9.2

On Tue, Feb 8, 2011 at 2:13 PM, David Fetter <david(at)fetter(dot)org> wrote:
>> I agree that we have some problems in that area - particularly with
>> writeable CTEs - but prolonging the schedule isn't going to fix that
>> problem.
>
> What is?

I think the best solution would probably be to find corporate sponsors
for more PostgreSQL committers, or other senior community members who
might become committers if they had more time to spend on it. The
problem is that there are basically two people who understand the
executor well enough to commit that patch: Tom, and Heikki. And Tom
doesn't really like the feature (for reasons that are totally baffling
to me, BTW). If I had three weeks to spend on that patch, it would be
in by now, and I'd know the executor a lot better too, which would
make things easier for the next guy who wants to do somethign of that
type. But I (with some exceptions) don't get paid to commit other
people's patches, so that limits the amount of time I can spend on it
to (a) time when I'm not working on something that's a higher priority
for my employer and (b) evenings and weekends. I invest as much of
that time as I can in community work (which is why I have "nerd"
tatooed on my forehead) but there's a limited amount of it, and I tend
to invest it in patches where I'm already somewhat familiar with the
relevant portion of the code, because that lets me get through more
patches, if not always the best patches.

> This development cycle was a change from other development cycles in
> that it "began" before development had closed in the previous cycle.
> I will not take a position at the moment as to the wisdom of making
> this change, but it's been clear from feedback from lots of
> developers, even ones who'd be expected to be "in the know," that this
> vital piece of information did not gotten out in time.

The schedule was posted publicly, so I'm not sure how that
communication gap happened.

> Let's assume for the moment that we're going with overlapping
> development cycles into the future.  I'd submit that given the
> propagation delay of this change, the schedule for the first iteration
> of this never was reasonable, and "slipping" two months is a small
> price to pay for the huge flock of things we're epsilon short of
> getting.

I think you're being considerably over-optimistic about how close the
remaining patches are to commit, and even more optimistic about the
effects of another two months on the quality of the release. Here's
my prediction: if we slip the schedule for two months, all the
pressure that now exists to get things wrapped up will disappear, and
we'll be back in approximately the same place two months from now. A
few more things will have been committed, but at least as many new
patches will materialize, so that the remaining volume of work is the
same as before, or even larger. We'll still end up punting the same
number of patches, but in the meantime we'll have managed to rush a
few things in that will destabilize the tree and require months of
extra beta time during which no new work will be able to be committed.

The point is this: We're not going to punt major patches because they
are close to commit but yet some arbitrary deadline has expired.
We're going to punt them because they're NOT close to commit and a
long-agreed deadline has expired. I don't think I'd get much support
if I proposed punting everything that isn't yet committed at
2011-02-15 00:00:00, but it's just a mistake to think that if we only
wait another day or another week, we'll get it all done. We've tried
that before and it usually doesn't work out. The limiting factor
isn't primarily the amount of time that it takes to write the code;
it's the amount of motivation to get it done.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company