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

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

From: Noah Misch <noah(at)leadboat(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
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-16 15:56:14
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jan 16, 2013 at 01:08:27PM +0100, Magnus Hagander wrote:
> On Wed, Jan 16, 2013 at 9:21 AM, 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?
> Not sure. One start might be to actually start having commitfest
> managers. I haven't actually checked numbers, but my feeling is that
> last round most commitfests (maybe not all) had a commitfest manager
> that worked (usually hard) at keeping things moving, whereas this
> round most (or all?) commitfests have been unmanaged. I'm not sure if
> that's the reason for it, but it's a feeling I have..


> > 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?
> I'm not one of the committers that pick up the most patches, but from
> reading messages on the lists I think fairly often patches that are
> marked as ready, aren't. Sometimes they require a small change, which
> is fine, but more often than not once it hits a committer it ends up
> with a lot of feedback requiring rather extensive changes.

That's an intrinsic hazard of non-committer reviews.  All the people who are
truly skilled at distinguishing ready patches from not-ready patches are
already committers, but a non-committer review catching even one important
problem adds value.  I'd rather have more people getting involved in the
process with high-effort reviews, however imperfect.

> As in it
> technical works, but it's better to do it in a different way. I'm not
> sure how to catch those better.

That's even harder, because it's subjective.  Committers often disagree on
such matters.

In response to

pgsql-hackers by date

Next:From: Noah MischDate: 2013-01-16 16:02:10
Subject: Re: Parallel query execution
Previous:From: Tom LaneDate: 2013-01-16 15:37:05
Subject: Re: Curious buildfarm failures (fwd)

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