> On Thu, 2008-09-04 at 10:45 -0700, Josh Berkus wrote:
> > We currently have 38 patches pending, and only nine people reviewing them.
> > At this rate, the September commitfest will take three months.
> >
> > If you are a postgresql hacker at all, or even want to be one, we need your
> > help reviewing patches! There are several "easy" patches in the list, so
> > I can assign them to beginners.
> >
> > Please volunteer now!
>
>
> Everybody is stuck in "I'm not good enough to do a full review". They're
> right (myself included), so that just means we're organising it wrongly.
> We can't expect to grow more supermen, but we probably can do more
> teamwork and delegation.
>
> I think this should be organised with different kinds of reviewer:
The list is correct but too verbose. And it does not attack the core
of the problem. I think the problem is not:
What can/should I do?
but instead:
Can I take the responsibility?
Lets say reviewer would like look on coding style or performance.
ATM it seems to him he well be now fully responsible for that aspect.
I think we have better results and more relaxed atmospere if we
use following task description for reviewers:
The committer will do in-depth review. You task as a reviewer
is to take off load from committers by catching simple problems.
Your task is done if you think the patch is ready for in-depth
review from committer.
Note1 - Yes, the trick is to emphasize that all responsibility
lies on committer.
Note2 - detailed lists of areas to look at and reviewer types are not
useful as each patch is different and each revier is different.
Long lists just confuse people. The simpler the better.
The main thing is to make easy for reviewer to take the first look.
--
marko
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment