Thread (23 messages) flat view 23 messages, 8 authors, 2016-08-24

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

From: Richard Ipsum <hidden>
Date: 2016-08-01 09:54:21
Also in: lkml

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]
quoted
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.
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help