Why kernel development still uses email

Re:Why kernel development still uses email by makomk on Sunday October 02, 2016 @05:14AM (#12621588)

Number one on your list is a big issue with using e-mail for kernel development. If you want to submit patches by e-mail, you have to install and configure one of a handful of clients that doesn't mangle the patches first. There's a list in the kernel documentation and they're not terribly user friendly. (In fact, by necessity they have to be, because not wrapping lines automatically is terribly user-unfriendly and required by kernel development. So the only clients that meet the criteria are the ones that don't care about being a pain in the ass to use, and this permeates the entire user experience.) This isn't an issue for the core kernel developers because they already have a suitable e-mail client configured and installed which they're used to using, and because they're generally not submitting patches that way anyway.

[ Parent | on HN ]

Re:Why kernel development still uses email by dredmorbius on Sunday October 02, 2016 @06:26AM (#12621731)

If you're sending email, it's trivial to use, if all else fails, a shell tool or application-based email client. Standard unix mail, mailx, mutt, or various mail utilities within Perl, Python, Ruby, etc., can all be adapted to accept patches and some cover text with ease, largely noninteractively.

If you're actually reading email off LKML, that's another story.

But seriously: mutt, pine, Emacs mail mode, or even graphical clients such as Evolution or Kmail, will work just fine. And can be used in conjunction with nontechnical (there's another phrase I'm avoiding using here) GUI mainstream email clients used for other tasks.

If you can't figure out how to install and use mail / mailx / mutt with git, you probably shouldn't be submitting kernel patches. Which in this case is a useful filter.

[ Parent | on HN ]

Re:Why kernel development still uses email by e12e on Sunday October 02, 2016 @08:55AM (#12622110)

Wait, I thought patches are typically attached, not sent in-line on lkml? Admittedly I've only ever submitted a patch once, in 2002 or something - and at the time I was using pine as an email client.

[ed: never mind, my assumption was wrong:

https://news.ycombinator.com/item?id=12620790 ]

[ Parent | on HN ]

Re:Why kernel development still uses email by bonzini on Sunday October 02, 2016 @09:55AM (#12622326)

You can use any email client if you have access to the SMTP server; you use git send-email to send patches and your usual client for everything else.

[ Parent | on HN ]

Re:Why kernel development still uses email by astrobe_ on Sunday October 02, 2016 @06:11AM (#12621700)

People who are into kernel development are unlikely to be defenceless against garbage email clients. They're actually the type of people who can write a script in an afternoon to solve the issue.

[ Parent | on HN ]

Re:Why kernel development still uses email by u801e on Monday October 03, 2016 @10:23PM (#12632918)

> you have to install and configure one of a handful of clients that doesn't mangle the patches first.

git-am and git-send-email are used by some people. Submitting patches using those tools is just a matter of setting up the necessary parameters (email server and authentication information). But you can use any email client to participate in discussions about a patch series regardless of whether or not it mangles text (since review comments or further discussion obviously do not need to be applied to one's local copy of the code).

[ Parent | on HN ]