Skip site navigation (1) Skip section navigation (2)

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

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Cc: Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, 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>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: CF3+4 (was Re: Parallel query execution)
Date: 2013-01-17 09:22:48
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jan 17, 2013 at 8:19 AM, Pavan Deolasee
<pavan(dot)deolasee(at)gmail(dot)com> wrote:
> 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.

While we can certainly do that, it would probably help just to havae a
"second line of reviewers". Basically a set of more senior reviewers -
so a patch would go submission -> reviewer -> senior reviewer ->
committer. With the second line of reviewers focusing more on the
whole "how to do things", etc.

As you, I'm not sure if it creates more overhead than it solves, but
it might be worth a try. In a way it already exists, because I'm sure
committers pay slightly more attention to reviews by people who ahve
been doing it a lot and are known to process those things, than to new
entries. All that woudl bee needed was for those people to realize it
would be helpful for them to do a second-stage review even if somebody
else has done the first one.

 Magnus Hagander

In response to


pgsql-hackers by date

Next:From: Abhijit Menon-SenDate: 2013-01-17 09:27:13
Subject: Re: Removing PD_ALL_VISIBLE
Previous:From: Pavan DeolaseeDate: 2013-01-17 08:49:07
Subject: Re: Removing PD_ALL_VISIBLE

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group