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 

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 Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?


Reply via email to