Re: CommitFest July Over - Mailing list pgsql-hackers

On Tuesday 05 August 2008 04:36:24 Magnus Hagander wrote:
> Robert Treat wrote:
> > On Monday 04 August 2008 15:38:35 Josh Berkus wrote:
> >> Post-mortem things we've learned about the commitfest are:
> >>
> >> 1) It's hard to get anything done in June-July.
> >
> > True... vacations and conferences abound. September should be better in
> > this regard I would think.
>
> Um. Looking at my calendar, the second half of september and all of
> october is packed solid with conferences. Unlike June, July & August
> which were completely empty.
>
> Perhaps it's a US vs EU thing?
>
> (Vacations are July/August though, so that matches)
>

Hmm... Pg.br is the only thing I could think of in September, which I don't 
think involves either of us, unless you're going on yet another world 
adventure ;-)

I do agree that October looks packed, I'm glad we're not doing a commitfest 
then. 

> >> 2) The number of patches is going to keep increasing with each
> >> commitfest.  As such, the patch list is going to get harder to deal
> >> with.  We now urgently need to start working on CF management software.
> >>
> >> 3) Round Robin Reviewers didn't really work this time, aside from
> >> champion new reviewer Abhjit.  For the most part, RRR who were assigned
> >> patches did not review them for 2 weeks.  Two areas where this concept
> >> needs to be improved:
> >>     a) we need to assign RRR to patches two days after the start of
> >> commitfest, not a week later;
> >
> > This seems tricky, since you want people to volunteer to review patches
> > ideally, will two days be enough? Should people interested in reviewing
> > be signing up ahead of time? Looking at the next commitfest, it is going
> > to start on a Monday... maybe auto-assigning reviewers on Wednesday is
> > OK.
>
> Um, didn't they already sign up ahead of time? We can't very well hand
> out patches to someone who's not interested, can we?
>

ISTR, and Josh's info above indicated, that after a week or so, patches with 
no volunteers simply got assigned to someone. Josh, want to confirm. 

> >>     b) there needs to be the expectation that RRR will start reviewing or
> >> reject the assignment immediately.
> >
> > I wonder if too much time was spent on patches like the WITH patch, which
> > seemed pretty early on it was not ready for commit... thoughts?
>
> I think that happens a lot. Once discussion "takes off" on a patch, it
> attracts more people to comment on it, etc.
>
> Plus the whole "hey, i've added a git repo" starts it's own thread :-P
>

I have a git repo for ppa, want to do some hacking? :-)

> >> 4) We need to work better to train up new reviewers.  Some major
> >> committer(s) should have worked with Abhjit, Thomas and Martin
> >> particularly on getting them to effectively review patches; instead,
> >> committers just handled stuff *for* them for the most part, which isn't
> >> growing our pool of reviewers.
>
> True.
>
> >> 5) Patch submitters need to understand that patch submission isn't
> >> fire-and-forget.  They need to check back, and respond to queries from
> >> reviewers.  Of course, a patch-tracker which automatically notified the
> >> submitter would help.
> >
> > Reviewers should be responding to the email on -hackers that is pointed
> > to by the wiki, so patch submitters should be getting notified... right ?
>
> Well, there's really no way to easily do that. I mean, you can't hit
> "reply" once you find something in the archives. You'll need to manually
> put everybody back in the CC list, so it's much easier to just post to
> -hackers.
>

Ah, I keep a healthy backlog of email sent to hackers, so if I want to respond 
to a patch, I find it in my email program and reply to that, with CC 
list/threading intact. 

> Thus, I think requiring the submitters to check back on -hackers
> regularly is necessary, for now.
>

Well, probably a good idea anyway, I certainly don't want to discourage it.  

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL