A farewell to email

Posted Oct 19, 2018 20:24 UTC (Fri) by jani (subscriber, #74547)
In reply to: A farewell to email by marcH
Parent article: A farewell to email

Interesting. Why I care is control too, but it's the end user control of the user experience I care about. I am not sure how giving up control of the user interface helps the receiver regain control. In centralized web based services, the receiver gets just as much control as the service provider has deemed appropriate, using an interface the service provider has deemed appropriate.

Surely an alternative to email that would address your problems as well as mine could be developed, but it's not here. It seems to me all of the popular alternatives are centralized with a control point.

A farewell to email

Posted Oct 20, 2018 6:02 UTC (Sat) by marcH (subscriber, #57642) [Link] (5 responses)

Please everyone put web services and user experiences aside for a moment, that's really not the main point. The core of any gerrit/gitlab/patchwork/etc. instance is basically a git repo with a _database_ of code reviews on top and databases have always spoilt their users with a huge variety of interfaces.

Most communities use a single database instance per git project for convenience/laziness but if you're paranoid about centralization then you can have multiple decentralized instances, either mirroring each other or with pull requests between them - just like plain git. All database instances send email to a single mailing-list for backward-compatibility with old maintainers. Other users can choose to receive all those emails, none or anything in between and that is how they're back in control of their inbox. Drive-by submissions become easy.

While most of the above is real today, I understand today's tools like gerrit or gitlab are far from perfect and not checking the boxes of the demanding and sometimes peculiar Linux kernel community. However long before bikeshedding how bad are gerrit's command line interface, emails or other fixable implementation detail, the very first, baby step would be to consider that the *database first, email second" design choice followed by most of the software world is maybe not totally stupid. I bet many patchwork users already agree.

This is like the attitude difference between:
A. CVS sucks, tarballs forever! versus:
B. CVS sucks, tarballs until we find something that doesn't suck.

A farewell to email

Posted Oct 20, 2018 6:20 UTC (Sat) by marcH (subscriber, #57642) [Link]

http://www.catb.org/esr/writings/taoup/html/ch01s06.html#...

Rule of Representation: Fold [code review!] knowledge into data, so program logic can be stupid and robust.

A farewell to email

Posted Oct 20, 2018 8:16 UTC (Sat) by jani (subscriber, #74547) [Link] (1 responses)

I wasn't talking about software development or code review, I was talking about communication in general...

A farewell to email

Posted Oct 20, 2018 14:56 UTC (Sat) by marcH (subscriber, #57642) [Link]

Code review is where the worst filtering problem is but you can apply the same and widespread "[distributed] discussion database first, optional email second" fix to any mailing list problem. You can also leave the moderated, low-traffic and "gentlemen's club" lists as they are cause they're not where the problem shows.

NNTP would be a good (re)starting point. groups.google.com has one cool feature: per-thread fine-grained email notification.

A farewell to email

Posted Oct 26, 2018 17:34 UTC (Fri) by zblaxell (subscriber, #26385) [Link] (1 responses)

> *database first, email second"

Ideally, database first, email for replication (i.e. you'd have a multipart message with text, html, and/or "blob of semi-readable bytes that the application can import to replicate the change in state of the master database").

We're running out of platforms where email MUAs can automatically feed data to an application, and maybe we never had a widely deployed, working, and secure transport for that data. On the other hand, polling works almost as well, so maybe we won't miss that feature when it's completely gone.

Pulling the data into a local git instance solves many of the problems, but only if the database schema never changes; otherwise, you have half your project's history in one replicated silo and the other half in an incompatible replicated silo that eventually only runs inside a VM running an OS nobody supports any more.

For things like code review records, it's important to capture the presentation of the data at the time the data was created, because it's a big deal if a later version of the database has a bug interpreting or converting old data (e.g. it attributes review comments to the wrong developer). This kind of thing is important in environments where a saved copy of a patch review email can change the outcome of a lawsuit.

The ossification of email standards has ensured that's not a problem for mailing lists (though a really deep archive search has to understand things like uuencoding).

A farewell to email

Posted Oct 27, 2018 1:50 UTC (Sat) by marcH (subscriber, #57642) [Link]

To be clear I never meant "email for database replication" (that would be... patchwork v2?). The longer version: "Replicated/cached database first, optional and personalized email notifications second"

> Pulling the data into a local git instance solves many of the problems, but only if the database schema never changes; otherwise, you have half your project's history in one replicated silo and the other half in an incompatible replicated silo that eventually only runs inside a VM running an OS nobody supports any more.

Code reviews and other "human" conversations have a high read/write ratio and low volume compared to other database workloads. If nothing fancier comes for free then a simple scheme with 1 master + N throw-away, read-only slaves scheme is good enough.