Re: Last gasp - Mailing list pgsql-hackers

On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On ons, 2012-04-11 at 14:29 -0400, Tom Lane wrote:
>> I hear you ... but, given that the source material is a mailing-list
>> thread, *somebody* has to do all that work to produce an acceptable
>> commit.  And if you're just going to commit what that somebody sends
>> you without further review, then you might as well give that person a
>> commit bit, because you're trusting them to get all this right.
>
> I'd still review it, but I'd be able to spend say 3 minutes on review
> and 30 seconds on committing it, versus 3 minutes on review, 3 minutes
> on research, and 8 minutes on bookkeeping.

Well, I am not averse to figuring out a better workflow, or some
better tools.   In practice, I think it's going to be hard to reduce
the time to review a trivial patch much below 5-10 minutes, which is
what it takes me now, because you've got to read the email, download
the patch, check that it doesn't break the build, review, commit, and
push, and I can't really see any of those steps going away.  But that
doesn't mean we shouldn't make the attempt, because I've got to admit
that the current workflow seems a little cumbersome to me, too.  I'm
not sure I have a better idea, though.  git remotes seem useful for
collaborating on topic branches, but I don't think they can really be
expected to save much of anything during the final commit process -
which is basically all the process there is, when the patch is
trivial.

Now what would be sort of neat is if we had a way to keep all the
versions of patch X plus author and reviewer information, links to
reviews and discussion, etc. in some sort of centralized place.  The
CommitFest app was actually designed to track a lot of this
information, but it's obviously not completely succeeding in tracking
everything that people care about - it only contains links to patches
and not patches themselves; it doesn't have any place to store
proposed commit messages; etc.  There might be room for improvement
there, although getting consensus on what improvement looks like may
not be totally straightforward, since I think Tom's ideal process for
submitting a patch starts with attaching a file to an email and many
other people I think would like to see it start with a pull request.
This is not entirely a tools issue, of course, but it's in there
somewhere.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company