Better tools for kernel developers

Posted Feb 7, 2020 22:13 UTC (Fri) by DSMan195276 (guest, #88396)
In reply to: Better tools for kernel developers by milesrout
Parent article: Better tools for kernel developers

I've made a few contributions to the Kernel and other Open Source projects, and while I agree it's not terrible, you can't just hand wave away your first step as "this is no big deal":

> There are loads of mail clients out there, nobody is forcing you to use mutt (which doesn't suck).

The number that you can actually use to send patches and reply to mail on the LKML is a lot smaller than you'd expect/like. And with that, besides outlook I don't know *anybody* who uses a desktop mail client anymore - the only time I ever use one is for sending/receiving patches and mail on the LKML and other mailing lists. And the GMail web interface (by far the most popular to use) in particular does not work for the LKML, because it wraps lines at 80 characters and does other silly things, so you can't send patches using that even if you wanted too. It also doesn't support a threaded view of conversations that you obviously need for most (all) mailing lists, so replying to emails via that (which is "supposed to be easy") is also largely impossible.

With that, the list of desktop mail clients is slim and getting slimmer (because nobody uses them...) and `mutt` is the only one I had much success with for the LKML. There `alpine`, which is just as messy to get working as `mutt` in my experience, and there's also `evolution` which somewhat works but requires some settings to get right. I mean, just look at the kernel documentation for setting up your email client:

https://www.kernel.org/doc/html/v5.5/process/email-client...

The fact that it even needs a page that long with a bunch of weird settings should indicate things are a lot messier than you're suggesting. And the only time anybody is ever going to use any of those programs is when they're sending patches, they're otherwise useless tools for almost everybody.

My last point is the big one - the process is no longer "use your existing email client to do this", instead it has become "install and configure one of these obscure programs to interact with our system".

Better tools for kernel developers

Posted Feb 7, 2020 22:29 UTC (Fri) by andyc (subscriber, #1130) [Link]

> And with that, besides outlook I don't know *anybody* who uses a desktop mail client anymore

Nice to meet you... (Cl;aws Mail with own mail server)

Better tools for kernel developers

Posted Feb 7, 2020 23:13 UTC (Fri) by Jandar (subscriber, #85683) [Link] (1 responses)

I know a few people who use any kind of web-mail but those are vastly outnumbered by people using desktop mail-clients like thunderbird.

I'm struggling to think of any web application which isn't inferior to a local running program.

Better tools for kernel developers

Posted Feb 8, 2020 1:18 UTC (Sat) by rgmoore (✭ supporter ✭, #75) [Link]

I know a few people who use any kind of web-mail but those are vastly outnumbered by people using desktop mail-clients like thunderbird.

I know a lot of people who use web-mail as their interface for their personal mail. It seems to me that it has two big advantages:

It doesn't require they install a new piece of software on their computer.
It requires no configuration.

These are big advantages for people who aren't very computer savvy, not that "aren't very computer savvy" describes many kernel contributors.

Better tools for kernel developers

Posted Feb 10, 2020 8:42 UTC (Mon) by geert (subscriber, #98403) [Link] (6 responses)

I have used the GMail web interface for almost all of my interaction with Linux mailing lists since 2009, except for:
1. Sending patches (git send-email using the SMTP server of my ISP),
2. Replying to patches on mailing lists I'm not subscribed to, and thus downloaded from lore or patchwork (alpine is still in my fingers).

Yes, GMail has lost the ability to not corrupt patches copy-'n-pasted to the web interface many years ago :-(

Better tools for kernel developers

Posted Dec 23, 2020 16:23 UTC (Wed) by tbelaire (subscriber, #141140) [Link] (5 responses)

What exactly does Gmail break? Is it just line wrapping or is it anything else?

I do work on Gmail, if there's a clear test case maybe I could try and fix this. Though I'm a little afraid of touching that part of the code base as there are a lot of tools which parse emails, and I wouldn't know if my change broke something until too late.

I suppose more usefully, how would I test this? I could generate a patch with git, copy it into gmail (after the fix), send it to myself and copy the body from gmail web into a .patch file, which I feed to git?
Or would I need to set up mutt or something in order to get the email in a form git likes? I haven't sent patches by email successfully before.

Can you include the patch file as an attachment instead?

Better tools for kernel developers

Posted Dec 24, 2020 0:34 UTC (Thu) by foom (subscriber, #14868) [Link] (3 responses)

Gmail hard-wraps plaintext mails at 78 columns. It should stop doing so. Fixing this in gmail would also make its plaintext emails more readable on mobile devices.

Other popular mailers have stopped doing hardwrapping years ago, and now simply send long lines as long lines, without inserting any extraneous linebreaks. In order to remain compliant with SMTP standards, which prohibits long lines, you must encode the message as quoted-printable if the lines are too long. But, quoted-printable encoding is reversible and transparent to the content, unlike inserting hard linebreaks.

A previous solution to the mobile problem was to use text/plain;format=flowed, but that format=flowed was a complex spec that had many problems of its own, and never interoperated well. It's fallen out of favor in recent decades (yes, decades!!!), in favor of simply never hard-wrapping text/plain content.

Better tools for kernel developers

Posted Dec 26, 2020 2:25 UTC (Sat) by zlynx (guest, #2285) [Link] (2 responses)

> Gmail hard-wraps plaintext mails at 78 columns. It should stop doing so. Fixing this in gmail would also make its plaintext emails more readable on mobile devices.

It's vague in my memory, but I am almost certain that wrapping around 72 and definitely before 80 is *required* for email user agents.

Yes, yes, it is commonly ignored for pasted or included content, but any email program that you type into is supposed to wrap long line at some point before 80, leaving room for at least three levels of quotes, like "> > > " which is six. So at least 74, more likely 72. 78 is being overly generous really.

This kind of sounds like someone complaining about Google's GMail *following standards*. Weird.

Better tools for kernel developers

Posted Dec 26, 2020 5:02 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

There's no hard requirement that user agents wrap text - it's convention to do so for the purposes of quoting stuff on 80 characters wide terminals, but doing so is inherently lossy when using plain ASCII (there's no way to tell the difference between a 72-character line followed by an 8-character line and an 80-character line that got hard wrapped). RFC5322 does say that agents SHOULD place a 78-character restriction on line length, but the context provided makes it pretty clear that it's talking about written language rather than code.

Better tools for kernel developers

Posted Dec 27, 2020 4:23 UTC (Sun) by foom (subscriber, #14868) [Link]

Sure, that was a common convention in the past, but many other user agents have stopped hard-wrapping years ago, because at this point it does more harm than good.

Better tools for kernel developers

Posted Dec 24, 2020 14:51 UTC (Thu) by geert (subscriber, #98403) [Link]

Using attachments is not an option, as it makes it hard to comment on attached patches.

Test procedure:

1. Generate patch with "git format-patch -1",
2. Revert top change using "git reset --hard HEAD^",
2. Open patch with e.g. gedit,
3. Paste patch into email body using gmail web interface,
4. Send email,
5. Open received email,
6. Select "Download message" from triple-dot menu,
7. Apply patch using "git am" (should apply cleanly),
8. Use "git diff" to check tree contents (should match state with step 1).

The above used to work, until Gmail started replacing TABs in pasted patches by spaces several years ago.
More things may have been broken afterwards (e.g. forced line break).

Thanks a lot!

FastMail

Posted Feb 16, 2020 11:26 UTC (Sun) by CChittleborough (subscriber, #60775) [Link]

(Sorry for posting this so late; I've just got around to reading the comments here.)

FastMail.com is a web mail provider built around the Cyrus IMAP server, a FOSS project to which FastMail make significant contributions (eg., JMAP).

As a FastMail customer*, I currently just use their web interface, but I previously used their IMAP interface with no difficulty.
*Full disclosure: I am a very satisfied FastMail customer.

Unlike gmail, FastMail does not mangle leading whitespace or long lines (at least in the simple test I just performed).

So maybe FastMail would be very useful to kernel developers. Does anyone use it?

Better tools for kernel developers

Posted Feb 21, 2020 21:29 UTC (Fri) by Wol (subscriber, #4433) [Link]

> My last point is the big one - the process is no longer "use your existing email client to do this", instead it has become "install and configure one of these obscure programs to interact with our system".

Thing is, there's a thing called "the principle of least surprise". And MOST GUI systems absolutely *love* to ignore it. If you use an email client that abides by it, you should not have any difficulty communicating with the linux project.

That's why a lot of MS products are so awful - they keep breaking this principle. As soon as someone starts thinking "why the f... is this happening?" there's a problem with the tool. And if the answer isn't blindingly obvious in hindsight (it should be obvious in foresight, too, but that really IS hard) then the tool is broken. Sadly, this is true of a heck of a lot of today's tools.

Cheers,
Wol