Live data from Hacker News

Why kernel development still uses email

lwn.net

61–70 of 152 posts

Re: Why kernel development still uses email

#61
post #59

Earlier quoted context omitted.

> I'll need to find and install one of the x tens of IM clients. Only one? :) It got so bad at my company, that at one time we were having conversations on 3 platforms. And, of course, no one emails anything! Because it's all done on Slack or whatever now. So everyone is 100% out of the loop at all times. I'm up to about 20 Slack channels. I'm constant switching between things to see if I need the information. We hav…

It harkens to a yesteryear of decentralised everything and a spirit that wanted to keep it as such: an island for every man... Now it's more of a huge resort super island filled with lots of other people where everyone perpetually rents everything. Too cynical?

Too real.

Re: Why kernel development still uses email

#62

I think it's worth adding, in the age of git sending patches by email is easier then ever - it definitely shows that git was developed by Linus with the kernel's development in mind. There is literally a `git format-patch` command which spits out a full formatted email (or emails) of your various commits, which can then be sent to a mail client to be edited and sent out. Or even easier, just use git to send the patch…

Outlook loves messing with messages. "Detecting and removing" extra line breaks is one of its features

Outlook it probably the worst email client currently on the market and has been for the all of it's existence.

It is my belief of the issue at lot of people have with email stems from Outlook. One example is the weird instance of top posting has made it hard to read many conversations and fostered a mentality of firing of quick response, reducing Outlook/email to a poor mans IM client.

There's a ton of improvements that could be made to Outlook to make it better.

Re: Why kernel development still uses email

#63
post #46

Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep track of their different build statuses. Also, where I use it we have different levels of requirements for different branches (more people usually need to approve reviews on soon-to-be-released point branches). We use it for a large project in MLOCs but relatively…

In my opinion, yes, Gerrit is awful.

Perhaps my experience is made worse by the fact that our Gerrit servers (perhaps about 5000 users) are so painfully slow that it can take a minute to display a page. Multiply that by the number of files touched in a patch to get a whole review done.

Then add all this non-vanilla Git extensions like "Change-Id" lines in commit messages and Gerrit/Repo's awkward idea of branches spanning multiple repositories.

All this makes it difficult to deal with multiple patches that make a "feature", ie. a feature branch. Something that should be trivial in Git is made really difficult by Gerrit.

Re: Why kernel development still uses email

#64
post #17

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard with many implementations on both the client and server. It is exceptionally easy to manage email. Many servers have great systems for categorizing emails and storing them long-term. Email is fast. Everyone has one. There is this weird myth that Email magically kills productivity while Slack and GitHub don't. I never underst…

> I'll need to find and install one of the x tens of IM clients. Only one? :) It got so bad at my company, that at one time we were having conversations on 3 platforms. And, of course, no one emails anything! Because it's all done on Slack or whatever now. So everyone is 100% out of the loop at all times. I'm up to about 20 Slack channels. I'm constant switching between things to see if I need the information. We hav…

Slack now have IRC gateway support so you can do that now.

Re: Why kernel development still uses email

#65

Earlier quoted context omitted.

FreeBSD maintains a github workflow as well as their more traditional svn workflow to make the project more accessible.

But if their traditional method is SVN, then there is a bigger reason to have some git element available. Linux already uses git, and has less incentive to add in a "git, the hard way" option.

Well, patch emailing can be done from any vcs, as long as there is something to clone from :)

One of the main reasons git is popular is because of github, and consequently there are lots of folks who only know the github workflow. Switching to patch emailing would be almost as new as using a new vcs for many. At least, that's my experience with folks I've mentored.

Re: Why kernel development still uses email

#66
tl;dr: my wish is a code review convention for git-notes and a friendly UI on top.

If only Git would allow storing reviews and issues in the repo proper. Something like Git notes with conventions to refer to files/lines in a file/different revisions etc. Something similar to Fossil.

This would solve half of the problem. The other half would be the UI layer.

Now the reviews live in a database, outside of the repo, and can't be downloaded locally for offline work.

This would allow doing code reviews and managing issues e.g. while commuting in a train. And everything would be pretty fast compared to waiting for a web page to load for every file you want to review and connecting to a server for every comment you write.

Re: Why kernel development still uses email

#67
post #4

When I was at Google, gerrit was indeed used internally. Things may have changed in the last 18months, but moving off the old tool to Gerrit was such a huge project that I'd be surprised if they'd moved on to something else.

+1. AFAIK Gerrit is still being used for kernel-related projects.

Re: Why kernel development still uses email

#68
post #46

Is Gerrit really that terrible? I do agree that clicking through each file is a waste, but I love the ability to work on several different reviews and keep track of their different build statuses. Also, where I use it we have different levels of requirements for different branches (more people usually need to approve reviews on soon-to-be-released point branches). We use it for a large project in MLOCs but relatively…

Perhaps I don't understand the Gerrit workflow, but last time I read about Gerrit it looked like it had a philosophy of "one commit, one review". That sounds like an anethema for the kernel, where they want to review a series of tidied up commits, one per email.

Does the topic branch feature help? I personally always use it.

Re: Why kernel development still uses email

#69
post #66

tl;dr: my wish is a code review convention for git-notes and a friendly UI on top. If only Git would allow storing reviews and issues in the repo proper. Something like Git notes with conventions to refer to files/lines in a file/different revisions etc. Something similar to Fossil. This would solve half of the problem. The other half would be the UI layer. Now the reviews live in a database, outside of the repo, and…

Why does email not solve your problem? It allows offline work, you can store the reviews on your computer, you can even commit it to git if you want.

Also check out emacs' org-mode for an alternative approach.

And last but not least, does it just sound like you value the review higher than the code? Why should it be more than a text file like any other? Meaning is something we add to the text. A tool with a specific goal like git shouldn't enhance a meaning to an object type.

Re: Why kernel development still uses email

#70
post #8

So I get and agree with what he's saying about how GitHub duplicated email, but as a millennial who uses Vim, I find GitHub much more intuitive and useful than sending patches via email. In general, I disagree with the issues he has with GitHub - most of them are wishy washy disagreements that could easily be solved by adding things to GitHub or using a chrome extension. IMO the only real, logical reason they need to…

I don't really feel that you being a millennial or using vim is relevant. I have no idea how you would go about getting github to implement whatever functionality is desired and even so would come with the following disadvantages -- Requiring a chrome extension limiting people to using chrome + a singular website vs any email client under the sun -- wouldn't work offline -- Presumably it would be more challenging for…

> Requiring a chrome extension limiting people to using chrome

And people who use extensions. Beyond ad blocker on some machines I don't use extensions on principle because of security concerns.

Post reply on HN