Re: Considering Gerrit for CFs - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Considering Gerrit for CFs
Date
Msg-id 511447A4.3070700@agliodbs.com
Whole thread Raw
In response to Re: Considering Gerrit for CFs  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Considering Gerrit for CFs  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
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
losingstrategy.   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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: performance bug in instrument.c
Next
From: Tomas Vondra
Date:
Subject: Re: issues with range types, btree_gist and constraints