Re: Considering Gerrit for CFs

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Daniel Farina <daniel(at)heroku(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Considering Gerrit for CFs
Date: 2013-02-08 00:32:36
Message-ID: 511447A4.3070700@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

Folks,

First, thanks for the serious discussion of this.

>> There are obvious tooling gaps (aren't there always?), but I don't
>> really see the model as broken, and I don't think I've been around
>> pgsql-hackers exclusively or extensively enough to have developed
>> Stockholm syndrome.

I don't see the model as broken either. Just the tooling, which is why
I'm looking at tooling. As in, I'm looking for better tooling in order
to solve two problems:

1. maximize the efficiency of existing reviewer time

2. make tooling not be an obstacle to getting new reviewers

Of these two, (2) is actually the more critical. We have been losing,
not gaining, active committers and reviewers for the last couple years.
Clearly "do more of what we've been doing" is a losing strategy. We
need to be sucessfully moving people up the contributor chain if we're
ever going to get out of this "not enough reviewers" hole.

I agree that tooling is a minority of this, but tooling is also the
easiest thing to change (compared with project organization), so that's
what I'm tackling first. Expect a discussion on the people aspects at
the developer meeting.

> Personally, I find the most annoying thing with the current process
> being when reviewers post their reviews as a completely separate
> thread, instead of replying in the original thread. This causes
> context switches when parsing things, because now you have to jump
> back and forth between the CF app and your mail reader. But it's still
> only on the annoyance side, I think the process in general is not
> broken. (That said, I *have* been on the inside a long time, *and* I
> live in Stockholm, so I might well have that syndrome)

So, look at this from the perspective of a casual reviewer, say at a PUG
reviewfest. Instructions to new reviewer:

1. find the feature you want to review on the CF app.

2. Click the link to the mailing list archives.

3. Click all the way through the list thread to make sure there isn't a
later version of the patch.

4. Download the patch. Hopefully it's not mangled by the archives
(this has gotten much better than it was last year)

5. Apply the patch to HEAD clone.

6. Do actual reviewing/testing.

7. Write an email review.

8. Send it to pgsql-hackers
8.a. this requires you to be subscribed to pgsql-hackers.

9. wait for the email to show up in the archives.

10. create a review comment in the CF app.
10.a. this requires you to be signed up for a community account
10.b. sign up for one now
10.c. wait for it to be approved

11. link the review comment to the messageID

12. change status of the patch

This is a few too many steps, and certainly appears completely broken to
any newcomer.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2013-02-08 01:41:12 Re: issues with range types, btree_gist and constraints
Previous Message Tom Lane 2013-02-08 00:28:04 Re: performance bug in instrument.c

Browse pgsql-www by date

  From Date Subject
Next Message Magnus Hagander 2013-02-08 10:23:52 Re: Considering Gerrit for CFs
Previous Message Magnus Hagander 2013-02-07 12:41:17 Re: Proposed changes to security.html