Re: RFE: use patchwork to submit a patch

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Drew,

On Tue, Oct 15, 2019 at 12:34:57PM -0400, Drew DeVault wrote:
> On Tue Oct 15, 2019 at 7:32 PM Laurent Pinchart wrote:
> > I certainly wouldn't recommend a solution based on a proprietary
> > closed-source stack :-) But as we're talking about performing new
> > development for patchwork, I wanted to point out that we could also
> > consider a different technical approach that would involve new
> > development for a different open-source project. For instance, is the
> > above idea something that could be developed on top of gitolite ? Or
> > possibly even as a tiny standalone git server ?
> 
> Some of the work I'm doing with code review on sourcehut can be
> generalized, to support writing up arbitrary mailing lists with
> arbitrary review tools with a bidirectional workflow. I intend to make a
> reality of this for at least lists.sr.ht <-> gitlab and lists.sr.ht <->
> github, so that patchsets and the resulting discussion gets turned into
> git{hub,lab} code reviews, and vise versa. I think it's possible to make
> a system which presents both sides with an experience that is idiomatic
> for each context, so that you can't really tell whose using which tool
> because they're both speaking each other's conventional language.

First of all, please let me thank you for all the effort you're putting
into this.

I'm not very confident that perfect transparent e-mail bridges could be
developed, and the culprit here it e-mail. From forge to e-mail there's
no real issue, we have structure data, and we write it out in text form.
The other way around, though, involves recovering structure from text.
If the MTAs, MDAs, MUAs and, quite importanttly, users, behave
correctly, that's doable. We can handle some of the "features" of common
M*A, but if someone decides to throw the formatting through the window
completely, we'll be screwed.

An idea I was toying with in the past was to create a structured format
for review, that would match what we use now in e-mail very closely, but
with a clearly defined syntax and grammar. The format would appear as
just plain e-mails to users, and a MUA that behaves reasonably would
likely produce valid structured data as e-mail replies. Over time we
could develop clients or teach some MUAs about the structured format,
removing the risk that they, or the end users, would mess up a reply.
The migration would be mostly transparent as it wouldn't really impact
existing users of e-mail, and could thus be rolled out over a long
period of time.

-- 
Regards,

Laurent Pinchart