On Thu, Apr 21, 2011 at 11:46 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > But aren't those two sides of the same coin, ie, people's natural > tendency to work to a deadline? If you approve of a lot of patches > showing up just in time for a commitfest, why don't you approve of > big patches showing up just in time for a release? I mean, I've been > heard to complain about that too, but complaining hasn't changed > anyone's behavior and it's foolish to expect that it will in the > future. (See insanity, definition of.)
Well, I guess I approve of the first behavior because it doesn't feel like having a red-hot iron spike driven through my foot, and I disapprove of the second one because it does. That may not be entirely consistent taken in the abstract, but it has some solid practical roots. > We need to find a way to work with that behavior, not try to change it. > I don't know what exactly. > > One idea that comes to mind is to give up on the linear development-mode- > then-beta-mode management model, ie, allow development of release N+1 > to start while beta is still going on for release N. The principal > objection to this in the past has been that the PG development community > is too small to do more than one thing at once, but maybe that's not > true anymore. The thing I'd be most worried about is how we get enough > energy directed at the release-stabilization part of the work, when for > most developers the new-development part is much more interesting/fun. > But we have that problem in some form already --- it's not clear to me > how much of the community really engages in what happens during beta, > rather than quietly working on stuff for the next release. I totally agree. In fact, I think that trying to close off that activity is one of the most self-destructive things we could possibly do. It makes missing the release far more painful if you're thinking about not only a 12-month slip on GA but also a 6-month slip on any meaningful further review. Encouraging people to hold off major proposals for the next release while we are focusing on beta also tends to slow them down, which then exacerbates the pile-up at the end of the release cycle. I would like to blow the doors on that wide open and encourage people to start submitting design proposals for 9.2 NOW. NOW, NOW, NOW! Not in July! And *really* not next January! And frankly, the sooner we can realistically start working on integrating the code that has *already* been written for 9.2, the better. The patches are going to land on us at some point, and dealing with them earlier will allow those people to move on to other things (which is good), reduce the pile-up at the end of the cycle (even better), or possibly both. I'm willing to make a serious commitment to being involved in the release stabilization work and to give it some degree of priority over new patches, if that's what it takes to make the process work smoothly. We are fundamentally resource-constrained, and no process is going to change that unless the process change, of itself, causes more people to contribute more time. But even if the first CommitFest involves a slightly higher bounce rate due to lack of reviewer/committer bandwidth, it's still better than not having one. There have been maybe half a dozen people who have been principally responsible for the stabilization that we have done since CF4, and the community is much larger than that. Everyone else is either doing nothing (which is bad), or working without on-list discussion (which is also bad). Even for the people who are deeply committed to release stabilization would probably be happier and more motivated to continue contributing if they weren't being limited to ONLY that. -- 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