Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why kernel development still uses email

lwn.net

Post reply on HN
Print view View original

101–110 of 152 posts

Re: Why kernel development still uses email

#101

Post by woah »

TeMPOraL wrote: post #94
douche wrote: post #72

Earlier quoted context omitted.

I can't abide ad-hoc phone calls, unless somebody is bleeding out or the server rack is bursting into flames. If I'm trying to work on something, hitting me in the back of the head with a claw-hammer would be scarcely more disruptive than an unsolicited phone call.

I can't abide ad-hoc synchronous communication , not just phone calls. It's the reason I'm almost constantly wearing headphones, whether I'm listening to something or not. I sometimes hear that a cow-orker is talking to me, but I ignore it on purpose, pretending not to notice. Then they usually figure out they need to attract my attention somehow, so they come over / wave their hands / throw an object at me. I respon…

Sounds like you're a real easy guy to work with.

Re: Why kernel development still uses email

#102

Post by qb45 »

userbinator wrote: post #18
Klathmon wrote: post #9

Earlier quoted context omitted.

While I agree, the opposite is also an issue. Developers which either look down upon anything new as "pointless" or in some cases actively try to stop improvements. Looking at the kernel dev system, it works great, but it has its share of problems. I've never even thought about contributing to the kernel because of the work involved to just submit a patch, that process can be improved. Making it easier for newcomers,…

I think it's a deliberate barrier to entry: they're basically saying "if you can't be bothered to learn how to do it, we don't want your contributions." Linus occasionally rants about some of the crap that gets in, and I have a feeling he certainly doesn't want more, which would happen if the barrier was lowered. Here's a somewhat recent example: http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html

Probably you are right, though in the case you linked the barrier was clearly insufficient. And OTOH, I have seen many cases where actually sane one-time contributors had to spend unreasonable time changing trivial patches to match the guidelines.

  [RFC PATCH] cmdline: Hide "debug" from /proc/cmdline

  It has come to our attention that a system running a specific user
  space init program will not boot if you add "debug" to the kernel
  command line.
Lol. I sometimes get disgusted by the kind of crap people merge, but it's nice that at least this one got the ridicule it deserved.

Re: Why kernel development still uses email

#103

Post by noufalibrahim »

nxc18 wrote: 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…

Another interesting thing is that email gets through most firewalls into most networks which makes it very easy to send data through.

Re: Why kernel development still uses email

#104

Post by uola »

usgroup wrote: post #59
deckard1 wrote: post #26

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 cynical?

No, too romantic. E-mail was never good enough to be decentralized, much less at the "every man" level.

Re: Why kernel development still uses email

#105

Post by shoover »

woah wrote: post #100
deckard1 wrote: post #26

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…

GitHub is really useful for issue tracking on open source projects. It's annoying to have to hunt through whatever 90's era mailing list archive website to see if someone else has had the same issue on projects that don't use it.

Good point. Email is great when you are part of the conversation and it's in your history. Maybe not so much for digging around later on otherwise.

Re: Why kernel development still uses email

#106

Post by gurkendoktor »

Confusion wrote: post #84
csl wrote: 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…

Our team of 10 thinks Gerrit is great. I don't know how these other people are using Gerrit, but I don't recognize their description at all. Gerrit is very convenient if you take code reviews seriously. I do agree that clicking through each file is a waste Well, firstly it is simply not true that you need to do that (you can accept/reject a review without having viewed any file at all), but secondly I'm totally fine…

> Article says: > Gerrit, he said, makes patch submission quite hard > But without any explanation for why.

You need to add hooks to inject a Change-Id into every commit, and be careful that they're still "fresh" (e.g. you cannot reuse one from an abandoned branch if you want to re-submit it).

And you must push a diff to the server so it can be submitted to Gerrit. If your feature branch is up-to-date (you just force-pushed it), you cannot submit the same commit to Gerrit.

And it gets worse when you have developers who rely on an IDE to get work done – the IntelliJ plugin for Gerrit is pretty buggy (I think it's okay for submitting now, but reviewing was still frustrating last month).

Re: Why kernel development still uses email

#107

Post by parennoob »

rtpg wrote: post #97
michaelt wrote: post #92

Earlier quoted context omitted.

Unfortunately, slack doesn't allow you to block users - not even bots or webhooks. And even if you have expansions turned off, they're still there in collapsed form. So if you're not an administrator, and some genius has set up a bot that posts a cute puppy every time a message includes /pup, and it triggers practically every line in a discussion about puppet, slack doesn't give you the option to do anything. Well, a…

I don't get how your pup situation doesn't get solved with a conversation with a co-worker.

I do. Do you want to really be "that guy" who hates puppies (and is ribbed about it all the time)? Software development teams often have all the maturity of a clique of middle schoolers; and exclusion can be just as harsh.

Re: Why kernel development still uses email

#108

Post by erikb »

exDM69 wrote: post #71
erikb wrote: post #69

Earlier quoted context omitted.

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…

The review comments still live outside of the repo, in an unformatted ad-hoc format that's not easy to write a nice UI for. Ideally, I should be able to add review comments in a graphical diff viewer or web front-end and every dev should be able to choose the tools they prefer. Email workflow would solve the connectivity issues, but the reviews, issues etc are not stored for posterity along with the code. Reviews don…

Fossil looks quite interesting. Thanks for the reference. https://www.fossil-scm.org/index.html/doc/trunk/www/concepts...

Re: Why kernel development still uses email

#109

Post by _asummers »

rtpg wrote: post #97
michaelt wrote: post #92

Earlier quoted context omitted.

Unfortunately, slack doesn't allow you to block users - not even bots or webhooks. And even if you have expansions turned off, they're still there in collapsed form. So if you're not an administrator, and some genius has set up a bot that posts a cute puppy every time a message includes /pup, and it triggers practically every line in a discussion about puppet, slack doesn't give you the option to do anything. Well, a…

I don't get how your pup situation doesn't get solved with a conversation with a co-worker.

"Your bot is broken, fix it so we can talk about our tools."

Re: Why kernel development still uses email

#110

Post by bonzini »

makomk wrote: post #60
dredmorbius wrote: post #24

Earlier quoted context omitted.

Email is tremendously useful, and whatever replaces it should borrow from those useful bits. It also has numerous problems. Some are listed in the article: 1. Clients (and some servers) mangle email. You can't be assured that what you send is what someone else will receive. I blame the clients and servers here, but ... 2. Privacy. This has become among the biggest downsides. Whether it's data-in-flight or data-at-res…

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 r…

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.
Post reply on HN