Someone said to me today that most people "prefer" the GitHub/GitLab/etc pull request workflow over email. I don't think that's true. I think it's more that most people have only ever *tried* the GitHub/GitLab workflow, and have no exposure to email-driven development.
@sir A lot of people have kind of forgotten how to do email. Email clients are almost a thing of the past.
@igeljaeger Hello cartoon Japanese girl from Pleroma! Are you kind? Are you nice? A lot of cartoon Japanese girls from Pleroma are not.
@igeljaeger Your instance's theme is full of them. This is not usually a good sign. Are you an exception? Are you kind? Are you nice?
@igeljaeger Okay, I hope we're all nice to each other, then.
@emersion has a library for reading maildirs:
aerc is designed to interact with mail backends using a worker thread and message passing. The IMAP worker is here, for reference:
The UI will send actions and the worker will send messages. Each type of message is defined here:
It should be fairly straightforward to add maildir support. You just listen on a channel for these actions and respond with the appropriate messages. Bonus points if you set up inotify to watch the maildir for incoming emails.
@sir woot! Is it time to finish up my nascent freebsd port of it already?
@sir I like email based workflows. Whether sending patches through the mail or simply sending someone an email saying "Here is my repo, this is my branch. Please merge it in." and then they can pull and examine the changes and comment on them.
(I'm turned off a bit by some conventions about /the kernel in particular/ since to my way of thinking their emphasis on SHORT patches in the patch series don't cut the changeset at logical points.)
@sir Boy you’ve opened a can of sadness there. Those Silicon Valley shitheads are way too successful in centralizing decentralized services and using marketing tactics to make the alternatives appear worse even though they aren’t.
@lachs0r you should write about your thoughts
@sir for $work I'm now using email workflow quite extensively and tbh, it's really really less efficiant and accessible than the "pull request" oriented workflow.
I'm pretty much convinced that people that prefers it are stucked in their old habits. And as expected $work projects don't received a lot of contribution because on how unintuitive it is to contribute like that.
@bram it's definitely not less efficient, unless your setup is obtuse. Not having to context switch to a web browser, set up a fork, etc, is a lot of overhead saved
@sir it's totally less efficient (and I'm using mutt, I know emails ™):viewing diff is less powerful, less efficiant, you can easily explore the code, you need to context switch it's really have to have builtin good efficiant global view, this horribly sucks for new contributors that want to get an idea on the current state you need to build you own tracking of what is happening, people can't have access to that because ml logs sucks having to subscribe to a ml to send a patch sucks
You also have full cli integrated tools for PR workflow if you don't want to use a browser and can do full threads management using emails.
Mail oriented is just inferior on all points at the exception of "firing patchs from cli without caring about anything else" lazy attitude. It's just bad, unaccessible and we should stop it.
@sir ah and I'm not talking about all the emails related problems I've had like being greylisting, having (and it's the case right now) the mailing list software down (second time), have emails that never went in, being moderated because my patch was too big etc...
Also you can't edit an email if you've made a small mistake and need to spam again everyone else.
And handling a lot of emails it not a common skill, this make this workflow excluing.
@bram of your cricisms, the following are improved by aerc or sourcehut, or planned to be and should be ready by the end of the year:
- better context in diffs from your mail client and on list archives
- you already don't have to sub to almost any ml to send a patch
- lists.sr.ht separates patches in the archive from conversations
- push-button CI/CD integration with mailing lists
Also, we can (and I will) make a web based interface which is similar to the GitHub et al workflows, but backed by emails underneath so that people who like email can work with people who don't and no one feels left out.
- mail based workflow was efficient before forge like Github
- today GitHub, Gitlab and so on are more efficient because of the incredibly good integration
- tomorrow mail based could be as efficient as GitHub for the masses, and more efficient for email power-users thanks to SourceHut.
Is that your view of things?
@sir the github style and the email style workflows both have their up and downsides, mainly that it's way easier to track state of an PR in the github style workflow.
In the e-mail workflow it's a lot easier to do multiple things at once in the repository, which sounded weird to me at first but turned out to be true.
That do you think about the phabricator workflow?
@carl I've only used it a little, not enough to have a trustworthy opinion on it
@sir Ok, because it's interesting how similar the phab and email workflow are. In the phab workflow, you send your patch to the server using arc, but you can also upload diff directly with the web interface. And during the review, you can update the diff, by uploading a new diff.
@sir I'll give it a try over the week. Last time I did this with sway, I ended up using it as my daily driver.
Although I'm not a hardcore committer, the support for multiple accounts, async IMAP and "efficient network usage" are, for me, gold standards of console MUAs.
Out of curiosity, what made you go for a completely new implementation, instead of just having a legacy MUA such as mutt do this for you?
@sir Just for the record: I prefer the E-Mail workflow.
This way I can decide when I work on something, because I do not need internet connection when replying to patches or creating them. Also I configure the interface to the patches the way I like it and do not have to deal with a website or even a mouse.
cmpwn.com is a private Mastodon instance for friends of SirCmpwn.