Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

From: Richard Ipsum <richard.ipsum@codethink.co.uk>
Date: Aug 9, 2016, 09:17 UTC
Message-ID: <20160809091722.GA1983@salo>
In-Reply-To: <CACsJy8DeSv_ALHR+HrViEptgYCYhXu2ZczMmhzZfHGAwZumnzg@mail.gmail.com>

On Tue, Aug 09, 2016 at 06:22:21AM +0200, Duy Nguyen wrote:

Show 13 quoted lines

> On Tue, Aug 9, 2016 at 12:20 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> > On 08/04/2016 05:58 PM, Johannes Schindelin wrote:
> >> [...]
> >> Even requiring every contributor to register with GitHub would be too much
> >> of a limitation, I would wager.
> >> [...]
> >
> > Is it *really* so insane to consider moving collaboration on the Git
> > project to GitHub or some other similar platform?
> 
> In the very unlikely event that github is shut down, how do we get all
> review comments out of it, assuming that we will use pull requests for
> review?

For what it's worth this is exactly why I think it would be worthwhile for git to establish a common review format, services like Github/Gitlab could then start storing reviews and comments in the git repo rather than in a separate sql database.

Gerrit is already doing this with notedb, which literally gives you a git log of a review. Admittedly with Gerrit the change metadata sits in a separate git repo, still, this is much better than the current situation with Github and Gitlab in my opinion.

I apologise once again if my comments here are somewhat unrelated, but I feel there is at least some overlap, since the existence of a common review format for git could potentially make Github/Gitlab a more attractive option, if Github/Gitlab chose to adopt such a format.

Really I think that reviews shouldn't be stored on mailing lists, and they shouldn't be stored in sql databases, they should be stored in git.