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

From: Eric Wong <e@80x24.org>
Date: Aug 10, 2016, 01:57 UTC
Message-ID: <20160810015736.GA17898@starla>
In-Reply-To: <20160810005548.gee6ontd33ck5vej@x>

Josh Triplett <josh@joshtriplett.org> wrote:

Show 13 quoted lines

> On Tue, Aug 09, 2016 at 06:28:00PM +0000, Eric Wong wrote:
> > Some of these problems I hope public-inbox (or something like
> > it) can fix and turn the tide towards email, again.
> 
> This really seems like the dichotomy that drives people towards central
> services like GitHub or GitLab.  We need an alternative that doesn't
> involve email, or at the very least, doesn't require people to use email
> directly.  Half of the pain in the process comes from coaxing email
> clients that don't treat mail text as sacrosanct to leave it alone and
> not mangle it.  (Some of that would go away if we accepted attachments
> with inline disposition, but not all of it.  All of it would go away if
> the submission process just involved "git push" to an appropriate
> location.)

I don't mind patches as attachments and did some work a few months ago to ensure they're individually downloadable in the public-inbox WWW interface (along with full mboxrd messages)[1].

Fwiw, attachments are preferred in perl5-porters, and it might be acceptable on LKML, even. Not my call, though.

Having a push/pull-only workflow would still require some sort of messaging system to notify others. Ideally that message would have the output of "git request-pull" to ensure people are on the same page; but I'd prefer patches (either attachments or inline) continue to be sent anyways in case the server is down or the reader is offline or on a machine without git.

[1] see Brian's (who is new, here) initial email for diff-highlight:
    https://public-inbox.org/git/20160728162712.GA29220@tci.corp.yp.com/