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
