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.
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.
(btw, I'm not talking about the MMAP patch here, which has gotten
excellent review at this point. I'm talking about a lot of other patches)
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.
Maybe we don't want to use ReviewBoard specifically. Maybe we want to
use bugzilla or Crucible or Redmine something more specific for
patch/spec review. But I think it's time to try something else, maybe
several other things.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
