Folks, Here is my proposal for CFs for this year:
We do four CFs, July 15, September 15, November 15, and January 15. However, we rigidly apply the 30-day deadline for the January 15 CF. That is, anything which is not completely ready for commit on February 14 gets punted to the next version. None of the "oh it's almost ready", no "just 2 more weeks of review". Make sure everything gets reviewed promptly (we *can* do it) and commit or punt. == Speeding things up == As far as our annual cycle is concerned, I don't think that the development/CF period is the problem; it's as efficient as we really want it to be. It's what comes after: post-CF cleanup, integration, beta. This period is especially a problem because it is one of little visible activity, no development, and generally waiting-room mentality for most of our contributors. Here are my proposals for making all of that go faster, with the caveat that it probably won't get better until the 2nd time we do it: Post-CF: Make a list (now, not in January) of the tasks which need to be done between CFend and Beta. We'll find that some of them could be done by someone other than Tom and Bruce, and that others could be done before CFend. Beta: Create a mailing list (why don't we have a list for testers? is testing less important than the JDBC driver?) and a simple web app or templated wiki page for testers. Allow people to check in with which version they tested (Alpha1,2,3, Beta 1,2,3) and what tests they ran, and issues encountered (if any). We should do this now so we can get started with Alpha testing. When this testing gets into swing, we can also look at recruiting volunteers to run various popular OSS apps' test suites against the developing version of PostgreSQL. Once beta starts, have a list of pending issues in some editable/commentable location (wiki is ok for this, or we can pervert the commitfest app) *as soon as those issues arise* so that as many hackers as possible can work on those issues. We did do a "pending issues" list for 8.4, but not until we were already over a month into beta, and then the list wasn't very accurate. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers