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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 1 Aug 2016 10:53:51 +0100
From:	Richard Ipsum <richard.ipsum@...ethink.co.uk>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Eric Wong <e@...24.org>,
	Christian Couder <christian.couder@...il.com>,
	git@...r.kernel.org, linux-kernel@...r.kernel.org,
	dborowitz@...gle.com, Omar Jarjur <ojarjur@...gle.com>,
	Harry Lawrence <hazbo@....com>
Subject: Re: [ANNOUNCE] git-series: track changes to a patch series over time

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

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