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

From: Richard Ipsum <richard.ipsum@codethink.co.uk>
Date: Aug 1, 2016, 09:53 UTC
Message-ID: <20160801095351.GA27496@salo>
In-Reply-To: <20160801085928.lw3ltdksyrjujutu@x>

On Mon, Aug 01, 2016 at 01:59:29AM -0700, Josh Triplett wrote:

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

[snip]

Show 9 quoted lines

> > 
> > 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 concur, for better or for worse many projects have abandoned mailing lists in favour of github, gerrit, gitlab and the like. The problem being, with the exception of gerrit, most of these tools store review data in sql databases, which is bad for obvious reasons.

Show 9 quoted lines

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

Exactly.