Robert Haas <robertmh...@gmail.com> writes:
> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut <pete...@gmx.net> wrote:
>> 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.
It strikes me that there are two different scenarios being discussed
here, and we'd better be sure we keep them straight: small-to-trivial
patches, and complex patches.
I think that for the trivial case, what we need is less tooling not more.
Entering a patch in the CF app, updating and closing it will add a
not-small percentage to the total effort required to deal with a small
patch (as Peter already noted, and he wasn't even counting the time to
put the patch into CF initially). The only reason to even consider
doing that is to make sure the patch doesn't get forgotten. Perhaps
we could have some lighter-weight method of tracking such things?
At the other end of the scale, I think it's true that the CF app could
be more helpful than it is for tracking the state of complex patches.
I don't really have any concrete suggestions, other than that I've
seen far too many cases where the latest version of a patch was not
linked into the CF entry. Somehow we've got to make that more robust.
Maybe the answer is to tie things more directly into git workflows,
though I'm not sure about details. I am concerned about losing
traceability of submissions if all that ever shows up in the list
archives is a URL.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
