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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers