On Wednesday, April 20, 2011 08:39:47 PM Josh Berkus wrote:
> Robert,
>
> > Unfortunately, my memory of this project only goes back to about
> > September 2008, which isn't far enough to remember why CommitFests
> > were created in the first place. So Alvaro may be correct in saying
> > that things have mutated over time, but that isn't necessarily a bad
> > thing. Maybe we've settled into something that works reasonably well.
> >
> > Or maybe we should make some changes; nothing is set in stone.
>
> Review of design concepts and WIP patches has *always* been a problem
> for this project. Andrew Sullivan bitched about it at some length back
> in 2004 ("Why there is no traffic on pgsql-replicationhooks", but
> Andrew's blog is down now unfortunately). And I've gotten complaints
> from numerous people: the Drizzle student, the person who e-mailed me,
> Afilias, Greenplum, Aster Data, others. It's just a broken process, and
> it particularly leads PostgreSQL forks to not contribute back stuff.
Well. But very few company people to contribute back in reviewing stuff from
others. At least in the time I have somewhat regularly
> We tell people to submit a design concept, but then such submissions are
> often ignored. When they're not ignored, they often are subject to
> either extreme bikeshedding or a lot of negativity around things the
> author hasn't implemented yet ... even if the author warns that they're
> not implemented.
I can see that point.
> I think that Robert is right and what we need is a completely different
> process for WIP patches and design concepts. It's pretty clear that
> none of the processes we've tried so far ("just post it to
> pgsql-hackers", "get a submission mentor" and "commitfest") have worked
> consistently.
>
> So in the spirit of NOT reinventing the wheel: ReviewBoard. Yes,
> really. One of the big issues with working through design reviews etc.
> on this mailing list is the lack of continuity and timeliness in
> comments on the idea/WIP patch. Having an interface which presents all
> of the discussion around a specific patch in a threaded and
> chronological way would help cut down on bikeshedding and dogpiling, as
> well as allowing both the idea/patch author to review all commentary in
> a coherent way.
I don't believe a second that problem is solved by any tool. In my opinion
there simply are very few people being able to do in-depth reviews of complex
patches. And those are also needed to implement complex features or do parts
of features others could not do.
A RRR like process doesn't really help in those cases except catch the most
obvious problems.
Andres