On Mon, Aug 01, 2016 at 07:55:54AM +0000, Eric Wong wrote:

Christian Couder [off-list ref] wrote:

quoted

On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
[off-list ref] wrote:

quoted

On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
[snip]

quoted

I'd welcome any feedback, whether on the interface and workflow, the
internals and collaboration, ideas on presenting diffs of patch series,
or anything else.

quoted

quoted

I'm particularly interested in trying to establish a standard for
storing review data in git. I've got a prototype for doing that[3],
and an example tool that uses it[4]. The tool is still incomplete/buggy though.

There is also git-appraise (https://github.com/google/git-appraise)
written in Go to store code review data in Git.
It looks like it stores its data in git notes and can be integrated
with Rust (https://github.com/Nemo157/git-appraise-rs).

I'm not convinced another format/standard is needed besides the
email workflow we already use for git and kernel development.

Not all projects use a patches-by-email workflow, or want to.  To the
extent that tools and projects use some other workflow, standardizing
the format they use to store patch reviews (including per-line
annotations, approvals, test results, etc) seems preferable to having
each tool use its own custom format.

I also see the reliance on an after-the-fact search engine
(which can be tuned/replaced) as philosophically inline with
what git does, too, such as not having rename tracking and
doing delayed deltafication.

Storing review data in git doesn't mean it needs to end up in the
history of the project itself; it can use after-the-fact annotations on
a commit.

Email also has the advantage of having existing tooling, and
being (at least for now) federated without a single point of
failure.

Storing review data in git makes it easy to push and pull it, which can
provide the basis for a federated system.

- Josh Triplett