A farewell to email
A farewell to email
Posted Oct 18, 2018 17:46 UTC (Thu) by marcH (subscriber, #57642)In reply to: A farewell to email by marcH
Parent article: A farewell to email
Why I care is *control*. Whereas open-source is all about end users being in control, email is the exact opposite. Whether it's spam or lkml, most receivers are helpless and senders are in control. While there are of course massively more powerful mind-control tools than email like for instance fake book, every email is a tiny, disorganized attempt at controlling what's on the receiver's mind. Can't suppress images of a crowd of preschoolers raising their hands and screaming "me! me!". Email was great in the gentlemen's clubs where it and the Internet were invented and I heard that a few gentlemen's clubs are still holding on to it, however it never really scaled beyond those.
Thank you email, you had a good ride with spam and mailing-lists but sorry, we have to demote you to private conversations and optional notifications cause bigger things went out of control and you couldn't scale. We gave your old job to this new database guy instead.
Posted Oct 19, 2018 20:24 UTC (Fri)
by jani (subscriber, #74547)
[Link] (6 responses)
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.
Posted Oct 20, 2018 6:02 UTC (Sat)
by marcH (subscriber, #57642)
[Link] (5 responses)
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:
Posted Oct 20, 2018 6:20 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
Rule of Representation: Fold [code review!] knowledge into data, so program logic can be stupid and robust.
Posted Oct 20, 2018 8:16 UTC (Sat)
by jani (subscriber, #74547)
[Link] (1 responses)
Posted Oct 20, 2018 14:56 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
NNTP would be a good (re)starting point. groups.google.com has one cool feature: per-thread fine-grained email notification.
Posted Oct 26, 2018 17:34 UTC (Fri)
by zblaxell (subscriber, #26385)
[Link] (1 responses)
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).
Posted Oct 27, 2018 1:50 UTC (Sat)
by marcH (subscriber, #57642)
[Link]
> 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.
Posted Oct 26, 2018 17:42 UTC (Fri)
by zblaxell (subscriber, #26385)
[Link]
This difference in perspective is interesting.
Of all the communications platforms I use, email is the only one I would say I, as an end user, fully control. Even then, my control is limited because I can't override someone else's decision to _not_ send me stuff when I want them to.
> most receivers are helpless...Can't suppress images of a crowd of preschoolers raising their hands and screaming "me! me!".
...aaand here we are back at the "enforcement as a feature" idea I mentioned earlier.
A farewell to email
A farewell to email
A. CVS sucks, tarballs forever! versus:
B. CVS sucks, tarballs until we find something that doesn't suck.
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email
A farewell to email