Re: CF3+4 (was Re: Parallel query execution)

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CF3+4 (was Re: Parallel query execution)
Date: 2013-01-17 07:19:08
Message-ID: CABOikdOS=WEpj5vZM5qTjC9Ma45GeXHOAgEAbGgB3bZrugiBsA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 16, 2013 at 1:51 PM, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>wrote:

> At 2013-01-16 02:07:29 -0500, tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2013-01-17 07:49:47 Re: Hot Standby conflict resolution handling
Previous Message Abhijit Menon-Sen 2013-01-17 07:15:52 Re: CF3+4