Bruce, Tom, all: > No rejiggering is going to get people to complete things they didn't > complete under the old system.
It'll help the new people. A lot of people -- if not most -- submitting their first major patch to PostgreSQL dramatically underestimate the amount of fix-up that's going to be required, and assume that there won't be a spec discussion, which there often is. By getting them to submit a little at a time, *earlier*, we can avoid doing those things at the last minute. Alternately, we can just make sure that first-time patchers have mentors who check progress well before feature freeze. > The plan you list above is what we did > for this release. No, it's not. There's a bunch of patches which we had nothing on -- not spec, not design draft, not anything -- until we got them on July 20th. Our current system is to have only one deadline, at which point you're expected to have 85% of the patch done and up to PostgreSQL standards. That's quite a bit of "jumping in with both feet" for a newbie. > I did try to get us additional help in reviewing. Neil was unavailable, > and Alvaro could only give part of his time Asking two people is not exactly an all-out effort to get reviewers. > It strikes me that setting feature freeze in midsummer might not be the > best strategy for having manpower available to review --- people tend to > be on vacation in August. Maybe the answer is just to move the dates a > bit one way or the other. We've discussed that issue before, yes. Since we're proposing a new roadmap process for 8.3, and will likely be dealing with a lot of major patches, maybe that's the release to delay? However, as PR maven I do want to point out that doing the final release in December would be a bad idea. Hard to get news coverage. Also, we'd have the same issue with people being gone. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq