> > > until needed (rarely). the email based model is just a flat list of > > > messages that includes all the past mistakes, and the by now > > > irrelevant versions. > > > > What the? If anything, emails are like a tree and discussions in most > > forges are a single long list that's rarely well organized. Virtually > > > not sure how most people consume their emails nowadays, but for me > it's one flat list per thread, in a browser (i.e. it's not a tree).
The point is that the emails contain the information on how to construct a tree out of them. It's just that most web clients (which most people are unfortunately using nowadays) are so bad that they render the tree as a flat list. > i used to use emacs for emails for a while, but i stopped. the > learning curve was too steep, and documentation was sparse, for little > perceived benefit. at one point i noticed that it was saving > unencrypted drafts of encrypted threads into my online mail account, > and i decided to abandon it. > > now i rely on webmail with Edit in Emacs browser extension. it's good > enough for everything i do, except maybe for contributing to Guix. Maybe having a proper tree representation of your emails is a sufficient benefit to change your email client or maybe you don't care about it that much. Anyway the email-based format gives the *option* to see the discussion as a tree, while a forge either shows messages as a tree or it doesn't. There is nothing that can be done to make it show them differently. By the way, I don't know what webmail you are using but I would be very sceptical of it keeping your drafts any more secure. It probably either stores the encryption keys on the server, sends data from the message editor to the server for some computation or relies on random javascript that could read your mails and send them directly to anyone who wants to snoop on you. > and all i'm trying to achieve here is to move the discussion away from > email-is-superior-period, to look at what requiremenets we have and > what tools satisfy them, if any. I think that is a good discussion to have, but I think it would be better to describe some of the requirements you think we should consider instead of just saying email isn't superior. It might not be, but it might also be. We should consider what we need and evaluate the available tools based on that, and if the result is that email is the best then it is. > > at the ChatGPT-related stuff that has been submitted). There sadly is > > no pleasing everyone here and unless these tools are incredibly simple > > to maintain, the utilitarian approach of least misery leads you to > > plain email. > > but is a least-misery model appropriate here? how do you even account > for the contributions that could have happened in a different > environment, but did not happen? > > similarly, e.g. demanding a dated ChangeLog format for commit messages > has a filtering effect on who will contribute, and then who will stick > around. most engineers have a hard time jumping through hoops that > they find pointless (git automatically encodes that information), and > i'd suggest considering what the effect are of such rules on Guix as > an emergent order. I agree on the ChangeLogs being a weird thing to require in commit messages. I think of commit messages as the place where you record the reasons behind the change in the commit. The ChangeLog seems to just record the changes which the diff of the commit already automatically records more accurately. If someone has use cases for the ChangeLog commits, I'd like to hear them. Maybe there is something that can't be achieved with git history without ChangeLogs, but I can't think of anything. Someone mentioned grepping the git log with them, but I think the same thing can be done with git log and git blame regardless of the commit message format.
signature.asc
Description: PGP signature
