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
[off-list ref] wrote:

quoted

On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote:

[...]

quoted

quoted

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.
 

quoted

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

quoted

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.

quoted

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