git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Jakub Narębski" <jnareb@gmail.com>
To: Josh Triplett <josh@joshtriplett.org>,
	Richard Ipsum <richard.ipsum@codethink.co.uk>
Cc: git@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [ANNOUNCE] git-series: track changes to a patch series over time
Date: Wed, 24 Aug 2016 12:56:03 +0200	[thread overview]
Message-ID: <01106859-2e0b-326a-eca2-e8f935a90beb@gmail.com> (raw)
In-Reply-To: <13509A14-16CB-476C-B983-7001F3D0DA61@joshtriplett.org>

W dniu 11.08.2016 o 00:07, Josh Triplett pisze:
> On August 9, 2016 11:37:31 PM HST, Richard Ipsum
> <richard.ipsum@codethink.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

      parent reply	other threads:[~2016-08-24 10:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29  6:40 [ANNOUNCE] git-series: track changes to a patch series over time Josh Triplett
2016-07-29 10:10 ` Richard Ipsum
2016-07-29 11:04   ` Josh Triplett
2016-07-29 12:44     ` Richard Ipsum
2016-07-29 13:00       ` Josh Triplett
2016-07-31 14:35         ` Richard Ipsum
2016-07-29 16:59       ` Stefan Beller
2016-07-31 14:09         ` Richard Ipsum
2016-08-01  5:04   ` Christian Couder
2016-08-01  7:55     ` Eric Wong
2016-08-01  8:59       ` Josh Triplett
2016-08-01  9:53         ` Richard Ipsum
2016-08-01 21:19         ` Eric Wong
2016-08-01 15:14 ` Stephen Warren
2016-08-01 18:37   ` Josh Triplett
2016-08-15 18:17     ` Simon Glass
2016-08-15 20:05       ` Josh Triplett
2016-08-03 19:12 ` Richard Ipsum
2016-08-04 22:40   ` Josh Triplett
2016-08-10  9:37     ` Richard Ipsum
2016-08-10 22:07       ` Josh Triplett
2016-08-11  6:23         ` Eric Wong
2016-08-24 10:56         ` Jakub Narębski [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01106859-2e0b-326a-eca2-e8f935a90beb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.ipsum@codethink.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).