Follow

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?

@JordiGH Oh you mean the background? The one on the left is actually the mascot of pleroma! I gave her a cute cowboy hat because I like american culture and added the one on the right to make it more aesthetically pleasing. And yes I am nice... if youre nice to me

@igeljaeger Okay, I hope we're all nice to each other, then.

@sir I prefer the github style development


because email clients suck ass
@sir @ivesen how configurable is aerc? i couldnt see much about it on the website.

i find some vim keybinds pretty obtuse because i dont use a qwerty keyboard.

i would try it to find out, but dont have go compiler set up at the moment *mumble excuses mumble gentoo*

@twee @ivesen it's pretty configurable, you can also start scratch with new keybindings if you prefer

@sir @ivesen sounds good. ill give it a try at some point.

is it imap only ? i dont have a consistent internet connection so download my mail whenever i connect (isync), interact in my own time and then do the uploads also when i connect.

aerc looks nice, and i dont like mutt, but is this kind of workflow possible?

@twee @ivesen it's IMAP only but I want to add Maildir support in the future. It wouldn't be hard if you want to work on this, lmk if you want the technical background

@sir @ivesen very little experience with go. let me get a bit more comfortable and then ill get back to you

@twee @ivesen the most efficient way to learn is by doing

@sir @ivesen aight then, hit me with that technical shit

@twee @ivesen here's the ticket:

todo.sr.ht/~sircmpwn/aerc2/16

@emersion has a library for reading maildirs:

github.com/emersion/go-maildir

aerc is designed to interact with mail backends using a worker thread and message passing. The IMAP worker is here, for reference:

git.sr.ht/~sircmpwn/aerc/tree/

The UI will send actions and the worker will send messages. Each type of message is defined here:

git.sr.ht/~sircmpwn/aerc/tree/

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.

@twee @ivesen can you join on irc.freenode.net? That's where technical chat happens. Someone else is interested in Maildir support, perhaps you two can work together

@sir woot! Is it time to finish up my nascent freebsd port of it already?

@sir Well, PRs can still be done and they are quite useful if there is a lot of patches or it's a on-going one that you can cherry-pick from.

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

@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

@sir

ml gets poluted by other discussions I don't care about, it's a "all or nothing" applying patch from emails is way less efficiant integrating CI/CD is much more work and annoying outside visibility with ml archives is totally inefficiant issues tracking, roadmap management and just project management is very badly integrated if any you can't edit email and clean presentation and adapt to have a summary of what is going one like on web interface

@sir

the UX is a disaster has of today standard and this drives away the majority of contributors, it's just not intuitive and accessible at all

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.

@sir @bram trying to sum up:

- 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 TIL you can download Gitlab commits as email patches 😄

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

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

Sign in to participate in the conversation
Mastodon

cmpwn.com is a private Mastodon instance for friends of SirCmpwn.