Re: [ANNOUNCE] git-series: track changes to a patch series over time

From: Eric Wong <e@80x24.org>
Date: Aug 1, 2016, 07:55 UTC
Message-ID: <20160801075554.GA22222@starla>
In-Reply-To: <CAP8UFD12Jk0s0HPPWS3CqFcB37gzhzZZi-V0PfqrRhZO4zhHOA@mail.gmail.com>

Christian Couder <christian.couder@gmail.com> wrote:

Show 8 quoted lines

> On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum
> <richard.ipsum@codethink.co.uk> wrote:
> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote:
> > [snip]
> >>
> >> 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.

Show 8 quoted lines

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

Rather, better ways to archive/search the emails is desirable. Fortunately, commit titles are rather unique :)

I started archiving the git ML with public-inbox (which uses git):

  https://public-inbox.org/git/20160710004813.GA20210@dcvr.yhbt.net/T/

It can be easy to search by Subject (commit titles):

  https://public-inbox.org/git/?q=s:%22more+archives+of+this+list%22

Search (currently Xapian) will be tuned to parse things like filenames and diffs to allow searching within those. It is already somewhat email-aware, such as deprioritizing quoted text; and having a code repository browser with mail archive integration is in the works.

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.

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

vger.kernel.org can still be a major point of failure, which is why the "archives first" approach of public-inbox favors readers pulling messages over NNTP/HTTP/git (and maybe soon, POP3).