On Tue, Feb 8, 2011 at 2:13 PM, David Fetter <da...@fetter.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
