Re: commit fests

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Greg Smith" <greg(at)2ndquadrant(dot)com>
Cc: <andrew(at)dunslane(dot)net>,<robertmhaas(at)gmail(dot)com>, <peter_e(at)gmx(dot)net>, <dfontaine(at)hi-media(dot)com>, <gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: commit fests
Date: 2010-01-25 17:25:52
Message-ID: 4B5D7FC0020000250002EB83@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Kevin Grittner wrote:
>> Other posts have suggested that "review fests" might be helpful
>> in this period. Again, it sounds to me, from other posts on this
>> thread, as though the primary risk is that people working on the
>> release could see something they couldn't resist getting drawn
>> into -- taking them off-task and delaying the release. The
>> obvious solution to that would be to create a
>> pgsql-journeyman-peer-review list for review fests during the
>> release window.
>
> Be careful, you're wandering quickly down the classic path by
> which you'll find yourself in charge of doing some work here.

Worse things could happen. ;-)

I've shied away from stepping up to bigger commitments here because
of family situations which can make unpredictable demands on my
time; however, those seem to have settled down somewhat in recent
months, so I might venture such a commitment.

> I think it's completely reasonable to say that someone could
> organize pgsql-rrreviewers (as an initial working area, maybe
> another list eventually) for periodic ReviewFest during periods
> where those patches won't be considered for commit, such as beta.
> Now that most patch submitters have gotten used to doing a
> matching bit of peer review, the pool of people to do the reviews
> is there without having to pull anyone else into that. I could
> even see the rrreviewers list or another one split out of it grow
> into a somewhat gentler place for people to ask for help with
> their patch development too--just ban all the grumpy people from
> there (I'll unsubscribe myself).

LOL.

> The important thing is that everyone would need to careful to
> respect not letting that spill over onto this list during the
> periods there is no official CommitFest going on, or there will be
> a net increase in said grumpy people.

Understood.

> Looking at stats here for the recent CFs, about 40% of patches
> submitted are returned with feedback (or rejected) rather than
> being committed anyway. And I'm estimating that >80% of patches
> only reach comittable after a round of review+corrections first.
> Getting a lot of that work out of the way outside of the regular
> CF seems a worthwhile goal.
>
> Starting the first CommitFest of the next version (normally a
> quite painful one) with a set of patches already marked "Ready for
> Committer" or pruned out with feedback already, all because
> they've been through a round or two of initial review, would be a
> nice improvement. Just drop a summary of what's been done onto
> pgsql-hackers once the CF opens again for the ones still in the
> running and off you go. The existing CF app could be used to track
> the early review work too, so someone who wasn't on
> pgsql-rrreviewers could dig into the archives to catch up in a
> few minutes by following the message ID links. I do that all the
> time for patches I had previously been ignoring and deleting out
> of my mailbox.

I see all those benefits, plus the possibility of a few more subtle
but potentially significant ones.

What next?

-Kevin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Selena Deckelmann 2010-01-25 17:45:55 Dividing progress/debug information in pg_standby, and stat before copy
Previous Message hywel 2010-01-25 17:17:26 Possible changes to pg_restore