Re: Last gasp - Mailing list pgsql-hackers

On Thu, Apr 12, 2012 at 05:49, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Wed, Apr 11, 2012 at 5:36 PM, Peter Eisentraut <peter_e@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?

If we were actually using git branches for it, the CF app could
automatically close entries when they were committed. But that
requires them to be committed *unmodified*, and I'm not sure that's
reasonable. I also think requiring a git branch for the *simple*
changes is adding more tooling and not less, and thus fails on that
suggestion.

It might be helpful (if the CF app had a trivial API) with a small
tool that could run from a git hook (or manual script or alias) that
would prompt for "which cf entry, if any, did this commit close"?


> 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.

I've suggested before that it would be a good idea to be able to
register a git repo + branch name in the commitfest app, and be able
to track that. If it was smart enough to figure out that for something
like github or bitbucket it could also add a web link (but keep the
git link for whoever wants to pull it remotely) with the full
differences to master, that would make *some* of those issues go away.
(Certainly not all, it's not a magic solution, but I believe it would
be a tool that could help). I've pretty much given up on that
happening though...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/