Re: commit fests - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: commit fests
Date
Msg-id 4B5D7FC0020000250002EB83@gw.wicourts.gov
Whole thread Raw
In response to Re: commit fests  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
Greg Smith <greg@2ndquadrant.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


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: MySQL-ism help patch for psql
Next
From: Selena Deckelmann
Date:
Subject: Dividing progress/debug information in pg_standby, and stat before copy