Re: CF3+4 (was Re: Parallel query execution) - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: CF3+4 (was Re: Parallel query execution)
Date
Msg-id CABOikdOS=WEpj5vZM5qTjC9Ma45GeXHOAgEAbGgB3bZrugiBsA@mail.gmail.com
Whole thread Raw
In response to CF3+4 (was Re: Parallel query execution)  (Abhijit Menon-Sen <ams@2ndQuadrant.com>)
Responses Re: CF3+4 (was Re: Parallel query execution)
List pgsql-hackers


On Wed, Jan 16, 2013 at 1:51 PM, Abhijit Menon-Sen <ams@2ndquadrant.com> wrote:
At 2013-01-16 02:07:29 -0500, tgl@sss.pgh.pa.us wrote:
>
> In case you hadn't noticed, we've totally lost control of
> the CF process.

What can we do to get it back on track?

I know various people (myself included) have been trying to keep CF3
moving, e.g. sending followup mail, adjusting patch status, etc.

I want to help, but I don't know what's wrong. What are the committers
working on, and what is the status of the "Ready for commiter" patches?
Is the problem that the patches marked Ready aren't, in fact, ready? Or
is it lack of feedback from authors? Or something else?


ISTM that even committers are often overwhelmed with the work, their own as well as that of reviewing other's patches and committing them. Especially when a patch is large or touches core areas, I can feel the significant work that the committer has to do even after some help and initial review from CF reviewers. On the other hand, if the patches are not committed in time, we loose context, interest dies down and when the patch is actually picked up by a committer who is often not involved in the original discussion, many points need to be revisited and reworked.

Would it help to step up a few developers and create a second line of committers ? The commits by the second line committers will still be reviewed by the first line committers before they make into the product, but may be at later stage or when we are in beta. I thought of even suggesting that the master branch will contain only commits by the first line committers. We then maintain a secondary branch which also have commits from the second line committers in addition to all commits from the master branch. The first line committers can then cherry pick from the secondary branch at some later stage. But not sure if this will add more overhead and defeat the problem at hand. 

My 2 cents on this difficult topic.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee

pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: CF3+4
Next
From: Pavan Deolasee
Date:
Subject: Re: Hot Standby conflict resolution handling