Better tools for kernel developers
Better tools for kernel developers
Posted Feb 6, 2020 22:29 UTC (Thu) by milesrout (subscriber, #126894)In reply to: Better tools for kernel developers by Cyberax
Parent article: Better tools for kernel developers
Posted Feb 6, 2020 22:39 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (58 responses)
Sorry, this is not trivial and is extremely convoluted compared to creating PRs on Github (and I've done quite a bit of drive-by contributions using it).
Posted Feb 6, 2020 22:47 UTC (Thu)
by milesrout (subscriber, #126894)
[Link] (50 responses)
The process is thus:
Step 1. Learn how to use git's mail capability, for which there are countless articles, wiki pages, tutorials, man pages, etc.
It's extremely simple and easy.
Posted Feb 6, 2020 23:48 UTC (Thu)
by newren (subscriber, #5160)
[Link] (1 responses)
There's a big difference between "sending email" and "sending email in a way that doesn't corrupt patches". Also, Microsoft tools aren't the only one that struggle there, as evidenced by the MUA-specific hints in the git documentation.
> The process is thus:
Sometimes people know how to use git's mail capability, use it fine for years, and then something outside of git breaks. For one example, see https://lore.kernel.org/git/CAP8UFD1hTc0dXWmiF6aW6=_7DhB8.... I too struggled with that same problem and remember spending *an entire day* attempting to figure out how to send my patches to git (and it wasn't the only time). I may not be the sharpest tool in the drawer, but I've had hundreds of patches accepted into git.git so if I'm struggling and can point to a thread where other git developers couldn't figure it out themselves and were asking the list, perhaps it's not as trivial as you make it seem.
> Step 2. There is no step 2, you have completed the process.
> It's extremely simple and easy.
I have to disagree. I still prefer the email process (see my three links on why I hate GitHub PRs and most gui code review tools in general[1]) and I think your point earlier in the thread that other projects should learn some good things from kernel development is spot on, but I certainly don't believe it's perfect or even above criticism.
Posted Feb 6, 2020 23:51 UTC (Thu)
by newren (subscriber, #5160)
[Link]
Oops, forgot to include the footnote link; here it is:
[1] https://github.com/newren/git-filter-repo/blob/master/Doc...
Posted Feb 7, 2020 0:25 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (34 responses)
And my setup is bog-standard, I have nothing whatsoever unusual. If Linux development can't be used with this setup then perhaps it should re-examine itself?
> And we'll remove the last of them, because 'learn how to reply to emails' is also a pretty basic task you should also be capable of.
> It's extremely simple and easy.
Posted Feb 7, 2020 1:01 UTC (Fri)
by pizza (subscriber, #46)
[Link] (7 responses)
So, why are you bothering with this Linux thing anyway, when Windows is "bog-standard" and works perfectly fine?
(Personally, I consider Outlook and the pathological behaviours it encourages to be not unlike the poorly-thought-out slide decks that led to the Challenger disaster.)
Posted Feb 7, 2020 1:09 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Also, there's very little relation between the Linux kernel and the outdated mail tools used to develop it.
> (Personally, I consider Outlook and the pathological behaviours it encourages to be not unlike the poorly-thought-out slide decks that led to the Challenger disaster.)
Posted Feb 7, 2020 15:25 UTC (Fri)
by ballombe (subscriber, #9523)
[Link] (4 responses)
Posted Feb 16, 2020 4:10 UTC (Sun)
by Conan_Kudo (subscriber, #103240)
[Link] (3 responses)
Posted Feb 17, 2020 11:04 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (2 responses)
Yes, but IIRC the guy asked on the OpenSSL developers' list whether it would be an OK thing to do and never got an answer.
Posted Feb 18, 2020 2:20 UTC (Tue)
by andresfreund (subscriber, #69562)
[Link] (1 responses)
And it was flagged as depending on uninitialized data by valgrind IIRC. Without comments explaining why there's no danger etc.
Posted Dec 24, 2020 4:26 UTC (Thu)
by ncm (guest, #165)
[Link]
Posted Feb 7, 2020 11:09 UTC (Fri)
by excors (subscriber, #95769)
[Link]
Linux is often used for embedded devices (via Android, Yocto, etc), where everything is cross-compiled and there's no need for the development environment to be Linux. E.g. you can build Android on macOS, and I suspect you can build it on Windows with WSL, so you can do serious Linux kernel development work without having a Linux desktop.
Posted Feb 7, 2020 9:21 UTC (Fri)
by dgm (subscriber, #49227)
[Link] (20 responses)
Posted Feb 7, 2020 9:26 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (19 responses)
Posted Feb 7, 2020 9:35 UTC (Fri)
by milesrout (subscriber, #126894)
[Link] (5 responses)
In particular, though, your argument seems to be 'Outlook is fine because it has every feature you could possibly need' while also simultaneously claiming that the Linux kernel development process is broken because Outlook doesn't support it properly. That seems to suggest that Outlook doesn't have every feature you could possibly need...
Posted Feb 7, 2020 9:41 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> In particular, though, your argument seems to be 'Outlook is fine because it has every feature you could possibly need'
Posted Feb 7, 2020 9:47 UTC (Fri)
by milesrout (subscriber, #126894)
[Link] (1 responses)
I have never identified a design decision in Outlook that I like. I hate the default shortcuts, I hate how the buttons are laid out, I hate how the panes are laid out, I hate how the windows are laid out, I hate their horrible excuse for an implementation of standardised email protocols... everything about it is terrible.
> Nope. I'm saying that Outlook has features that I need (and other average corporate email users), not every feature under the sun. And it seems like it's kernel developers that need some strange behaviors from mail.
The oh-so-strange feature of sending plain text email?
Posted Feb 8, 2020 12:46 UTC (Sat)
by gfernandes (subscriber, #119910)
[Link]
... that works perfectly fine in Outlook?
Sorry, but you've still not addressed the very valid question of what exactly is wrong.
Not usable with the Linux kernel workflow could equally be a problem with the workflow and/or the eccentricities of the mail exchange being mandated?
A PR is trivial in comparison to a patch with no context.
Posted Feb 11, 2020 22:51 UTC (Tue)
by poruid (guest, #15924)
[Link] (1 responses)
Besides the usual nonsensical way that options, account setting or any entity are organised in MS Outlook (e.g. navigate from Advanced to Extra to whatever deeper and then end up again in the dialog the navigation started from, ESC deep down a dialog stack just ending the whole stack), its all-functionality-in-one-application is hell bound: load and startup times are terrible, memory usage is huge, etc etc. Having separate tools that do one thing good and work well together - sounds familiar ? - is much better. The balancing of tradeoffs at Microsoft its development process have very little to do with user demands and much more with squeezing out profits and locking customers in.
Posted Feb 11, 2020 23:26 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 7, 2020 12:44 UTC (Fri)
by pizza (subscriber, #46)
[Link]
Both of those make Outlook a complete non-starter before we even get to feature sets.
I'm in this for the Four Freedoms, and I put my money where my mouth is.
Posted Feb 7, 2020 13:47 UTC (Fri)
by tao (subscriber, #17563)
[Link]
Posted Feb 7, 2020 20:44 UTC (Fri)
by neilbrown (subscriber, #359)
[Link] (10 responses)
I've never used Outlook, so this is second hand but it appear to not support any straight forward method to reply separately to various points in an email.
When people using Outlook have found the need to do this when replying to me they sometimes mark their comments in blue. Sometimes put [MYNAME] near them. Sometimes just interleave with my original text so I have to remember what I wrote so I can filter it out.
Now imaging trying to do code review using Outlook - code review often requires multiple separate statements, and often needs each to be clearly tied to a specific line of code.
I'm using gerrit in project at present and once when I was grumbling about it at a conference, someone said they really like it because it allows you to comment on individual lines. I thought "so what, I've been doing that with email for decades". I subsequently discovered they used Outlook. Enough said.
Posted Feb 7, 2020 20:53 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
> Now imaging trying to do code review using Outlook - code review often requires multiple separate statements, and often needs each to be clearly tied to a specific line of code.
Posted Feb 7, 2020 22:16 UTC (Fri)
by neilbrown (subscriber, #359)
[Link] (4 responses)
I didn't know that - thanks. How easy is it to enable? Are there simple instructions I can point someone to? "Please do *this* whenever you reply to me".. (It would need to work for the web-base outlook as well as the desktop app .... oh, and the phone app and ....)
> Most people are just not exposed to them.
Maybe that simple fact is a big flaw in Outlock. There is little point having functionality that people cannot find and don't even know to look for. I know UI design is hard, but email is so ubiquitous that it really needs the work to be put in.
Thanks.
Posted Feb 7, 2020 22:53 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
I was able to find these instructions on Microsoft's website, though these are how to set the default rather than how to do it for an individual message.
Older, plain text email clients defaulted to prefixing every line with a quote character because that was the only practical way of quoting a message. When newer clients started to support fancier formatting, that approach didn't work the same, so they used HTML-type quoting. Unfortunately, they don't seem to have come up with an easy way to intersperse quotes and replies, so people defaulted to top posting. That said, even with old-fashioned plain text quoting, there were plenty of people who top posted because it was faster than quote/reply formatting.
Posted Feb 8, 2020 0:19 UTC (Sat)
by neilbrown (subscriber, #359)
[Link] (1 responses)
Thanks for the link. I was afraid it might only be settable globally. This related directly to my point below...
> That said, even with old-fashioned plain text quoting, there were plenty of people who top posted because it was faster than quote/reply formatting.
That's true and it doesn't bother me at all - providing they manage to communicate clearly.
Having quote-with-prefix/quote-without-prefix/don't-quote as a global setting is a bit like having reply-to-sender/reply-to-all/forward be a global setting. (or html/plain-text being a global setting!!!)
Posted Mar 3, 2020 17:09 UTC (Tue)
by nye (subscriber, #51576)
[Link]
Also, when replying to a plain text email, it defaults to plain text so you don't need to change anything.
I don't really want to defend Outlook too much since I kind of hate it, mostly for reasons not covered in this thread, but in this particular way I think its reputation is a bit unfair.
Posted Feb 8, 2020 1:20 UTC (Sat)
by pizza (subscriber, #46)
[Link]
The web version of outlook does not support sane quoting. I believe the phone apps are similarly feature-limited.
Posted Feb 13, 2020 2:31 UTC (Thu)
by chutzpah (subscriber, #39595)
[Link] (3 responses)
> Outlook defaults to top-posting, but it supports traditional point-by-point replies as well. It also has tools to quote and unquote blocks of text. Most people are just not exposed to them.
Posted Feb 13, 2020 2:35 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Feb 13, 2020 2:46 UTC (Thu)
by chutzpah (subscriber, #39595)
[Link] (1 responses)
Posted Feb 13, 2020 3:10 UTC (Thu)
by pizza (subscriber, #46)
[Link]
Posted Feb 7, 2020 16:07 UTC (Fri)
by MaximeChambonnet (guest, #135950)
[Link] (4 responses)
Posted Feb 7, 2020 17:56 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 8, 2020 12:41 UTC (Sat)
by jezuch (subscriber, #52988)
[Link] (2 responses)
I work at a large investment bank, which is a heavily regulated industry and the Operations are very paranoid that you could accidentally "wall-cross" some sensitive material information (this is within the company, not even leaking it outside!) which means that the working environment is tightly controlled and this means Windows and Outlook. (Which nowadays is not the steaming pile of dung I expected it to be.) I don't love it, but don't you dare tell me that some thing is wrong with *me*.
P.S. We do quite a bit of contributions to Free Software. Some was created within the company and shared with the world.
Posted Feb 11, 2020 23:03 UTC (Tue)
by poruid (guest, #15924)
[Link] (1 responses)
Posted Feb 12, 2020 18:28 UTC (Wed)
by jezuch (subscriber, #52988)
[Link]
(FWIW it never happens here. We have a separate snipping tool which recognizes that corporate users absolutely *love* screenshotting. Not that clueless cropping was ever a problem.)
Posted Feb 7, 2020 22:13 UTC (Fri)
by DSMan195276 (guest, #88396)
[Link] (12 responses)
> 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".
Posted Feb 7, 2020 22:29 UTC (Fri)
by andyc (subscriber, #1130)
[Link]
Nice to meet you... (Cl;aws Mail with own mail server)
Posted Feb 7, 2020 23:13 UTC (Fri)
by Jandar (subscriber, #85683)
[Link] (1 responses)
I'm struggling to think of any web application which isn't inferior to a local running program.
Posted Feb 8, 2020 1:18 UTC (Sat)
by rgmoore (✭ supporter ✭, #75)
[Link]
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:
These are big advantages for people who aren't very computer savvy, not that "aren't very computer savvy" describes many kernel contributors.
Posted Feb 10, 2020 8:42 UTC (Mon)
by geert (subscriber, #98403)
[Link] (6 responses)
Yes, GMail has lost the ability to not corrupt patches copy-'n-pasted to the web interface many years ago :-(
Posted Dec 23, 2020 16:23 UTC (Wed)
by tbelaire (subscriber, #141140)
[Link] (5 responses)
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?
Can you include the patch file as an attachment instead?
Posted Dec 24, 2020 0:34 UTC (Thu)
by foom (subscriber, #14868)
[Link] (3 responses)
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.
Posted Dec 26, 2020 2:25 UTC (Sat)
by zlynx (guest, #2285)
[Link] (2 responses)
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.
Posted Dec 26, 2020 5:02 UTC (Sat)
by mjg59 (subscriber, #23239)
[Link]
Posted Dec 27, 2020 4:23 UTC (Sun)
by foom (subscriber, #14868)
[Link]
Posted Dec 24, 2020 14:51 UTC (Thu)
by geert (subscriber, #98403)
[Link]
Test procedure:
1. Generate patch with "git format-patch -1",
The above used to work, until Gmail started replacing TABs in pasted patches by spaces several years ago.
Thanks a lot!
Posted Feb 16, 2020 11:26 UTC (Sun)
by CChittleborough (subscriber, #60775)
[Link]
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.
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?
Posted Feb 21, 2020 21:29 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
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,
Posted Feb 6, 2020 22:58 UTC (Thu)
by mricon (subscriber, #59252)
[Link] (5 responses)
We hope to adapt Git's GitGitGadget [1] to make it possible to submit Github PRs against the kernel tree. This should help with this particular problem without introducing any hard dependencies. This is slightly more difficult than for Git, since there isn't a single mailing list where all patches are sent, but hopefully this obstacle is not insurmountable.
Similarly, we hope to add an alternative frontend to GitGitGadget that wouldn't be tied to Github and can be used with any git hosting service -- such that anyone who is able to host a git tree somewhere on the net can provide an URL, a branch, and a cover letter to have the service automatically submit a patch series to the proper location for review.
Posted Feb 7, 2020 0:19 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 8, 2020 23:37 UTC (Sat)
by Conan_Kudo (subscriber, #103240)
[Link] (3 responses)
This is literally one of the things that Pagure tries to offer. It doesn't exactly fit the Linux kernel's requirements right now, since it doesn't know how to process But being most of the way there to supporting that, while being completely Free Software (GPLv2+) and supporting an open data model (all project data in Pagure is stored as git repositories and can be manipulated with Git) makes it a worthy option to consider and contribute to make it work for the kernel, right?
Posted Feb 12, 2020 14:25 UTC (Wed)
by spwhitton (subscriber, #71678)
[Link] (2 responses)
Posted Feb 12, 2020 14:39 UTC (Wed)
by Conan_Kudo (subscriber, #103240)
[Link] (1 responses)
The problem with Sourcehut is that it provides no alternative workflow for submitting changes. It re-enforces the email-based workflow that myself and many others here have said is not workable. Sourcehut itself does improve things from the "dumb" email model (such as basically integrating Patchwork's functionality), but itself does not provide any reasonable workflow improvements.
Posted Feb 12, 2020 21:29 UTC (Wed)
by milesrout (subscriber, #126894)
[Link]
However if you put even the most basic research into sourcehut you'd know that the major goal of the website is to build online web-based contribution tools that use the "unworkable" email workflow underneath.
Posted Feb 8, 2020 8:59 UTC (Sat)
by ntj (guest, #130246)
[Link]
Officially, Exchange is not a protocol. It is not regular either. It uses MAPI, a proprietary protocol, that Microsoft tries to force onto their users as they do with their other garbage including their advertisements. That protocol does not even have an RFC.
To be honest, they officially state they allow you to also use standard protocols like IMAP and POP3, but in many cases you need to wire in your mailbox as an Exchange mailbox, for example on smartphones. (Fortunately you can do this with Gmail, so you are able to use 2 proprietary technologies at once.)
This misinformation and behavior is no surprise from Microsoft however.
Posted Feb 6, 2020 22:43 UTC (Thu)
by airlied (subscriber, #9104)
[Link] (34 responses)
This is a nice throwaway, but try doing it without having a full email server you've run yourself for 20 years, or without access to port 25 due to ISP, or company firewalls.
Setting up git-send-email isn't trivial, compared to using gitlab or github. (gitlab isn't microsoft and used by a lot of things).
Posted Feb 6, 2020 22:49 UTC (Thu)
by milesrout (subscriber, #126894)
[Link] (33 responses)
Posted Feb 6, 2020 23:15 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (5 responses)
Posted Feb 7, 2020 11:42 UTC (Fri)
by meyert (subscriber, #32097)
[Link] (4 responses)
Posted Feb 7, 2020 12:01 UTC (Fri)
by Karellen (subscriber, #67644)
[Link] (3 responses)
Port 25 can also be used, as it was used for years, and can still be used, by all email servers that I am aware of, as the client-to-server email submission port.
Port 587 is completely redundant. It even uses the exact same protocol as that which runs on port 25. You can just set up your firewall rules to translate traffic on port 587 to port 25, and email submission will still work without any other changes. Just use port 25.
Posted Feb 7, 2020 18:37 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (1 responses)
The advantage of using port 587 for client submission is that as a mail server operator you get to apply a different set of policies to connections on that port. For example, submitting e-mail on port 587 often requires the STARTTLS and SMTP-AUTH features (among others), which you can't insist on for server-to-server e-mail delivery on port 25.
In point of fact, various ISPs block clients from accessing TCP port 25 anywhere on the Internet, and force them to submit e-mail on the ISP's own mail servers on port 587 with encryption and authentication (and possibly rate-limited), as a spam-reduction measure.
Posted Feb 7, 2020 19:23 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
I think this gets to the core problem with email as a tool: it no longer works the way people expect it to. Spam and the responses to spam have fundamentally broken email. It is no longer easy to set up a server that reliably communicates with the rest of the world. Demanding that developers use a particular email setup in order to work on the kernel is thus a serious barrier to entry.
Posted Feb 11, 2020 10:44 UTC (Tue)
by nim-nim (subscriber, #34454)
[Link]
Posted Feb 6, 2020 23:15 UTC (Thu)
by dannyobrien (subscriber, #25583)
[Link] (9 responses)
For instance, as far as I can see, people here are describing challenges that revolve around sending and receiving email in the specific way that git expects, rather than expressing an inability to send or reply to email in general. Most people have email set-ups that don't work the way that git assumes (including you, I think! You do have a gmail account, yes?), and struggle to find out strategies that can enable them to better work with it.
Posted Feb 7, 2020 1:52 UTC (Fri)
by lsl (subscriber, #86508)
[Link] (8 responses)
Posted Feb 7, 2020 2:04 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Posted Feb 7, 2020 15:56 UTC (Fri)
by jgg (subscriber, #55211)
[Link] (1 responses)
https://github.com/jgunthorpe/cloud_mdir_sync
I have mail inflow working using OAUTH and a REST transport from my Office365 and GMail accounts.
While it seems trivial to say 'oh just use OAUTH' it actually turned out to be quite difficult to wrangle all the peices properly.
I haven't put the last parts in to send email yet, but internally the tool does have the bearer token to authorize SMTP. It needs plumbing into the MTA. Maybe next month. Still waiting for Office365 to actually have a way to send raw email with OAUTH, as MS promised to finally do 4 months ago. Maddening.
But yes, setting this all up is expert level stuff, not something you could expect someone who wants to just use git send-email to sort out. I'm mildly hopeful that someone will build a git plugin that can send email through gmail/o365 fully natively with 0 configuration.. At least for gmail sending email via REST is fairly straightfoward once you get the OAUTH token.
Posted Feb 7, 2020 16:23 UTC (Fri)
by pizza (subscriber, #46)
[Link]
...but it only takes an expert like you to figure it out once, and then it's a lot simpler for other folks to replicate it.
> I'm mildly hopeful that someone will build a git plugin that can send email through gmail/o365 fully natively with 0 configuration.
That might be a natural progression of the work you're doing right now, and I suspect it would be very well received..
Posted Feb 7, 2020 4:04 UTC (Fri)
by Conan_Kudo (subscriber, #103240)
[Link] (4 responses)
Posted Feb 7, 2020 4:51 UTC (Fri)
by pizza (subscriber, #46)
[Link] (3 responses)
(I'm actually serious here; this sort of thing is the tip of several pathological icebergs...)
Posted Feb 8, 2020 23:25 UTC (Sat)
by Conan_Kudo (subscriber, #103240)
[Link] (2 responses)
This is an unreasonable response. I can count on one hand the number of projects that There are a number of other concerns that prevent enabling weak app tokens. Most of them are around compliance and preventing account hijacking. Accounts of engineers are often way more privileged than non-engineers. At As an aside, executive assistants (who you call "secretaries") tend to handle pretty sensitive stuff, and they're usually quite smart. They handle a different problem domain than engineers do, and it's a hard one. I miss being able to ask one to help me with doing travel arrangements and payment work. Doing it myself is a lot of complicated work...
Posted Feb 9, 2020 3:59 UTC (Sun)
by pizza (subscriber, #46)
[Link] (1 responses)
Well, of course "secretaries" handle a (very) different problem domain than engineers. (And one of their more challenging responsibilities is insulating executives from the effects of their own policies)
...Meanwhile, that is precisely why each group should have tools catering to their particular needs.
Posted Feb 21, 2020 21:36 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Feb 6, 2020 23:24 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (13 responses)
Posted Feb 7, 2020 11:00 UTC (Fri)
by marcthe12 (subscriber, #135461)
[Link] (12 responses)
Posted Feb 7, 2020 12:58 UTC (Fri)
by pizza (subscriber, #46)
[Link] (11 responses)
The entire Linux kernel mentality is centered around Fixing Things the Right Way(tm), ie identifying the root cause of problems rather than adding endless layers of workarounds, and that extends to its tooling. If the tools are shitty, then make better ones. Telling them that they need to throw out the tooling they built to be maximally productive because other folks insist on using shitty tooling is not an argument that will gain traction.
Posted Feb 7, 2020 17:53 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Feb 7, 2020 20:28 UTC (Fri)
by roc (subscriber, #30627)
[Link] (3 responses)
When you set up an email system you can't know whether, possibly years in the future, your engineers might need to contribute to the kernel.
Posted Feb 7, 2020 20:56 UTC (Fri)
by pizza (subscriber, #46)
[Link] (2 responses)
You're right, at any given point in time, you can't absolutely know what your users will need at some point in the future, which is why there must be a process for new needs/requirements to be captured, evaluated, and supported. After all, IT is a strategic asset that empowers your colleagues to leverage agile design methodologies to deliver maximum value through effective business analysis to diverse stakeholders while upholding the highest standards of quality and integrity.
Meanwhile, back in the real world, every engineering group I've ever worked for/with has had to set up some sort of shadow IT infrastructure in order to do their jobs.
Posted Feb 7, 2020 21:56 UTC (Fri)
by geert (subscriber, #98403)
[Link] (1 responses)
Posted Feb 7, 2020 22:43 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
Business people are perfectly capable of making terrible decisions about infrastructural matters in all sorts of domains; the Chemical Safety and Hazard Investigation Board would have a lot less to post on their Youtube channel if this wasn't the case.
Posted Feb 8, 2020 13:17 UTC (Sat)
by gfernandes (subscriber, #119910)
[Link] (5 responses)
...by using the **wrong** tool (aka email)?
Email may have been the **only** way to get things done in the 70's. But that's not too say it was the **right** tool then. Most certainly, it is **not** the right tool **now**.
Posted Feb 9, 2020 0:22 UTC (Sun)
by andyc (subscriber, #1130)
[Link]
> Email may have been the **only** way to get things done in the 70's. But that's not too say it was the **right** tool then.
Opinions vary...
Posted Feb 9, 2020 4:05 UTC (Sun)
by pizza (subscriber, #46)
[Link] (3 responses)
Everything else has dissolved into balkanized silos whose primary goal is to monetize the user.
Posted Feb 12, 2020 17:37 UTC (Wed)
by flussence (guest, #85566)
[Link] (2 responses)
Posted Feb 12, 2020 17:56 UTC (Wed)
by pizza (subscriber, #46)
[Link]
...And if you think getting a usable semi-custom email workflow is too difficult... XMPP is an order of magnitude worse, with significantly worse tooling.
(I still have an XMPP server going for my domains. In the past few years, I've received a total of *zero* non-spam messages..)
Posted Feb 12, 2020 18:06 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link]
XMPP has failed to get any traction because none of the implementations could be expected to be reasonably compatible with each other. That was the practical consequence of being extensible and having different features bolted on. Matrix has higher momentum now
Posted Feb 8, 2020 13:09 UTC (Sat)
by gfernandes (subscriber, #119910)
[Link] (2 responses)
Email is so fantastically unfit for purpose, it's not even worth talking about.
WhatsApp and Signal have long replaced email for person-to-person communication for me. It's encrypted by default, and doesn't require me pulling out my hair out gauging out the eyes of whoever I want to communicate with, to setup encrypted communications.
Try doing that with email without getting granny to jump off the cliff.
Posted Feb 21, 2020 21:39 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
I avoid WhatsApp, and what on earth is Signal?????
Cheers,
Posted Feb 22, 2020 19:09 UTC (Sat)
by jem (subscriber, #24231)
[Link]
Posted Feb 6, 2020 22:52 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
I understand why things are the way they are, but incremental improvement is possible. I've discussed this before[1] on here[2].
[1]https://lwn.net/Articles/803696/
Posted Feb 7, 2020 0:03 UTC (Fri)
by mirabilos (subscriber, #84359)
[Link] (4 responses)
I cannot easily send from git (need to hand-edit the output then feed it into /usr/sbin/sendmail on another machine), and people often don’t accept git format-patch output as attachments.
Back before git, or in the BSDs, where you’d just post inline or attached unidiffs, things were/are easier.
Posted Feb 7, 2020 9:34 UTC (Fri)
by geert (subscriber, #98403)
[Link] (3 responses)
Posted Feb 7, 2020 17:25 UTC (Fri)
by mirabilos (subscriber, #84359)
[Link] (2 responses)
2. Perhaps, yes, but people seem to complain about that as well…
Posted Feb 7, 2020 21:51 UTC (Fri)
by geert (subscriber, #98403)
[Link] (1 responses)
Posted Feb 7, 2020 22:07 UTC (Fri)
by mirabilos (subscriber, #84359)
[Link]
Better tools for kernel developers
The last time I had to:
1) Get special permission from IT to use IMAP for mail instead of regular Exchange protocol.
2) Install imapproxy.
3) Install mutt.
4) Set up this whole shebang (which was NOT trivial at all).
5) Finally be able to use git's mail capability (after misusing it once and spamming the LKML with an incomplete patch series).
6) Learn how to use mutt to reply to emails with code reviews (newsflash: mutt sucks).
Better tools for kernel developers
Step 2. There is no step 2, you have completed the process.
Better tools for kernel developers
> of those, because they're entirely a you problem of you not already having the ability to *send email*, a pretty basic task in today's world. And
> we'll remove the last of them, because 'learn how to reply to emails' is also a pretty basic task you should also be capable of. There are loads of
> mail clients out there, nobody is forcing you to use mutt (which doesn't suck).
> Step 1. Learn how to use git's mail capability, for which there are countless articles, wiki pages, tutorials, man pages, etc.
Better tools for kernel developers
Better tools for kernel developers
Outlook works perfectly fine for me. It does all I need from it: e-mail, contact management and discovery, shared calendars and meetings and so on. I have no problems with it, it just works.
The style of email communication used in LKML is not easy to replicate in Outlook or other mailers.
Compared to creating a PR on a git forge? No, it's not.
Better tools for kernel developers
Better tools for kernel developers
Mostly because Linux is standard on the servers. And I'm using Outlook on Mac OS X, btw.
Or perhaps the Debian Disaster with removing out the entropy source because there was no code context visible (unlike in PRs in git forges)?
Better tools for kernel developers
Well, Debian did that change, it was never present in upstream OpenSSL.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Same here. My Instagram app does everything I want from a communication tool. Why those old Linux farts refuse to work with it just escapes me.
/sarcasm
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Nope. I'm saying that Outlook has features that I need (and other average corporate email users), not every feature under the sun. And it seems like it's kernel developers that need some strange behaviors from mail.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
In short, it hard to have a detailed multi-thread conversation with Outlook.
Better tools for kernel developers
Outlook defaults to top-posting, but it supports traditional point-by-point replies as well. It also has tools to quote and unquote blocks of text. Most people are just not exposed to them.
Indeed, Outlook is not the best tool for it. Additionally, Outlook defaults to a proportional font which is nicer to read than monospace fonts. But it makes it a poor tool to edit or read code.
Better tools for kernel developers
Better tools for kernel developers
How easy is it to enable? Are there simple instructions I can point someone to? "Please do *this* whenever you reply to me"
Maybe that simple fact is a big flaw in Outlock. There is little point having functionality that people cannot find and don't even know to look for.
Better tools for kernel developers
I really don't care about the format, but I would like people to think about the message that they want to send, and then to create the message accordingly.
This means they need the tools available to create a useful message. Sometimes top-posting is a perfectly good way to send a message, sometimes interleaving is best. In the cases that I can think of that particularly bothered me, my correspondent clearly *was* trying to communicate usefully, but were impeded by their tool.
Having the tools available needs them available on a message-by-message basis, not as a global setting.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
I have yet to discover any way to configure it to work this way, at least with the Outlool 365 web client. If you know how to get this functionality, please share.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
If so, on reception, ever saved the image from the mail and found that it shows the whole screenshot? Not good, not in a tightly controlled environment, not good anywhere.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
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.
Better tools for kernel developers
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).
Better tools for kernel developers
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.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
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).
More things may have been broken afterwards (e.g. forced line break).
FastMail
*Full disclosure: I am a very satisfied FastMail customer.
Better tools for kernel developers
Wol
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Similarly, we hope to add an alternative frontend to GitGitGadget that wouldn't be tied to Github and can be used with any git hosting service -- such that anyone who is able to host a git tree somewhere on the net can provide an URL, a branch, and a cover letter to have the service automatically submit a patch series to the proper location for review.
MAINTAINERS and send the message to the correct subsystem mailing lists based on what the diff includes. Nor does it have a mode for sending it as a traditional patch series with a cover letter + diffstat based on the PR description. But Pagure could be easily extended to provide that functionality.Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
In point of fact, various ISPs block clients from accessing TCP port 25 anywhere on the Internet, and force them to submit e-mail on the ISP's own mail servers on port 587 with encryption and authentication (and possibly rate-limited), as a spam-reduction measure.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
And if your Gsuite admin doesn't allow creating app tokens (mainly to force all authentication through 2FA through custom auth), what do you do then?
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
$DAYJOB relies on that still use email-based workflows for submitting fixes. (Hint: it's only three, and one we don't usually contribute to!) That's out of literally hundreds of projects and the three Linux distributions we contribute to.$DAYJOB, compliance requirements have forced us to mandate it for everyone since we try to maintain a relatively open environment for employees in the company.Better tools for kernel developers
Better tools for kernel developers
Wol
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Is it super-productive, though?
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Imagine all transports had to be performed using limousines instead of trucks, as the former "just work fine" for the business people.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
> Most certainly, it is **not** the right tool **now**.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers
Wol
You know, nowadays you can find answer to questions like this faster by looking them up in Wikipedia...
Better tools for kernel developers
Better tools for kernel developers
[2]https://lwn.net/Articles/807136/
Better tools for kernel developers
Better tools for kernel developers
2. Patches created by git-format-patch are very similar to unidiffs, so you can just post them inline like before.
Better tools for kernel developers
Better tools for kernel developers
Better tools for kernel developers