Message-ID: <01106859-2e0b-326a-eca2-e8f935a90beb@gmail.com>
Date:   Wed, 24 Aug 2016 12:56:03 +0200
From:   Jakub Narębski <jnareb@...il.com>
To:     Josh Triplett <josh@...htriplett.org>,
        Richard Ipsum <richard.ipsum@...ethink.co.uk>
Cc:     git@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] git-series: track changes to a patch series over time

W dniu 11.08.2016 o 00:07, Josh Triplett pisze:
> On August 9, 2016 11:37:31 PM HST, Richard Ipsum
> <richard.ipsum@...ethink.co.uk> wrote:
>> On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:
[...]

>>> If you use a format-patch diff that includes the headers and
>>> commit message, you could also support commenting on those in the
>>> same way. Does the notedb format support commenting on those?
>> 
>> Comments in notedb are just a git note keyed on the sha of the 
>> commit being commented on, I'm not certain what advantage a 
>> format-patch diff provides in this case?
> 
> I meant for opening in an editor to write email-reply-style comments.
> The review tool and review storage format should allow commenting on
> commit messages, not just diffs.

There is also cover letter and interdiff, and one would want to
be able to comment also on those.

So how notedb solve problem of in-diff comments, in-commit comments,
post-commit comments, whole series cover letter and cover-letter
comments, interdiff and interdiff message / comments?


Nb. GitHub Pull Requests include only some of those, compared to
the mailing list / Usenet news interface.
 
>> I've been closely following the 'patch submission process' thread, 
>> and given the discussion there I'm having doubts over the value of
>> comments in git-candidate vs the mailing list. It seems to me that 
>> git-candidate has many of the disadvantages of Github/Gitlab when
>> it comes to comments, for example, there is no threading.
> 
> That's not inherent, though. You could allow commenting on a comment
> easily enough. (Of course, at some point you've recreated email-style
> in-reply-to headers...)

I wonder if we could use 'parent' header of a commit message for this,
or equivalent...
 
>> Also the system would be less open than the mailing list, since, as
>> it stands currently you would require push access to the
>> repository to comment on anything.
> 
> You'd need a federation mechanism.

...which is as easy to set up and use as mailing list, for sending
patches, applying patches, and patch review.  And/or provide 
bi-directional interface to the mailing list (I think Debian 
infrastructure tries to be (inter)operable by email).

There are various federated technologies (like pump.io), the
problem might be their popularity.

>> It may be worth reflecting that one reason some organizations have
>> switched away from mailing list reviews to Github/Gitlab is that 
>> they provide patch tracking, where the mailing list provides none, 
>> so patches there can be 'lost'. So instead of trying to
>> reimplement an entire Gerrit/Github/Gitlab UI on the commandline, I
>> wonder whether it would be sufficient to add the minimum
>> functionality necessary to provide git with native patch tracking,
>> and leave comments for the mailing list. Of course this is exactly
>> what git-series seems to do, so in some sense I may be advocating
>> dropping my own work in favour of improving git-series.
> 
> I think the two serve different (though related) functions. I'd love
> to be able to use a text editor and command-line tool to produce and
> submit comments to systems like Gerrit or GitHub.

I think there are command-line tools that allow to submit comments
to GitHub.

-- 
Jakub Narębski

Powered by blists - more mailing lists