Re: RFE: use patchwork to submit a patch

["Drew DeVault" <sir@cmpwn.com>]

On Tue Oct 15, 2019 at 7:44 PM Laurent Pinchart wrote:
> 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.

Well, no, it can never be perfect. But I'm not trying to accomodate for,
as an example, someone who's deliberately trying to confusing the
system. It will probably always be based on heuristics in some degrees.

However, I think that social conformance is a force to be reckoned with.
Most people don't have to be taught how code review works on mailing
lists, they just watch others do it and naturally fall in line. Without
any formal structure at all, we've already more or less settled on a
shared set of patterns for email-driven code review. However, I think
that the following:

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

Is very reasonable. If we can come up with a standard which feels like
what we're already doing, but is written down, then tools have something
to conform to and users have some expectations for how to behave to make
their tools happy.

I would be up for putting up some kind of simple spec for bikeshedding
purposes, and teaching it to the thread parser that was built for
lists.sr.ht:

https://git.sr.ht/~emersion/python-emailthreads