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

41–50 of 152 posts

Re: Why kernel development still uses email

#41

Post by dfinninger »

deckard1 wrote: post #26
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…

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

Man, your Github notifications are mixed into Chat?

We have a #{{projcet}}-dev channel for talk and #{{project}}-admin for JIRA/Github/etc. Also, in Slack you can have it auto-close all expansions. You choose the Gifs you wanna see.

Re: Why kernel development still uses email

#42

Post by stephenr »

icc97 wrote: post #40

> "On the other hand, GitHub does not scale to larger projects. He pointed at the Kubernetes project" It seems according to this, that Github is fine for a project until it scales to such a size as you need an alternative. So even this is agreeing that small projects should start with Github. It would be useful to know the lower bound of users/developers at which point you need to switch to a more flexible system lik…

s/should/could/

Re: Why kernel development still uses email

#43

Post by gaius »

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…

Email is an amazing tool. I don't understand the rush to get rid of it. It is a free standard

Answered your own question - no way to make money off it for "disruptors".

Re: Why kernel development still uses email

#44

Post by sambe »

Email is great and I can see why they continue to use it, but there is a danger of being blinkered. Saying that GitHub reinvented email because they have comment threads is... almost trolling. Especially when also saying email integrates well with patchwork (presumably written due to the inability of email to handle issue/PR tracking).

Both have strengths and weaknesses.

Re: Why kernel development still uses email

#45

Post by digi_owl »

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

I really do wonder what it is with Sievers. The handing of udev went into a nosedive after GregKH handed him the maintainership. Yet GregKH seems to trust him completely and Torvalds for some reason trust GregKH.

It really makes me worry about the future of the kernel once Torvalds decides that he has had enough.

Re: Why kernel development still uses email

#46

Post by csl »

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 few developers (less than a hundred). I can't see it would work for 4000 devs at all, though.

Re: Why kernel development still uses email

#47

Post by justincormack »

Manishearth wrote: post #21
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 will note that contributing to GitHub is pretty much just as complicated, and requires just as many steps and git commands. The difference is that folks are used to contributing to GitHub. And that's an important difference. I feel that projects should allow newcomers to contribute through multiple channels. For tiny patches from newcomers, it doesn't really hurt to let them make patches on github, go through revie…

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

Re: Why kernel development still uses email

#48

Post by Manishearth »

rpedela wrote: post #35

For Github organizations, can't you forward notifications to a mailing list? Then everyone on the mailing list can see everyone's comments and respond through email but you still get to keep Github and all of its advantages.

Or people can just subscribe to a repo. Github provides pretty decent tools for filtering these via mail filters, too (sadly the on-site github notifications aren't as fine grained). GKHs assertion that you can't follow threads via email is false.

Re: Why kernel development still uses email

#49

Post by Too »

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…

Could you elaborate why you think gerrit wouldn't work for 4000 devs?

At that scale the project would be divided into smaller responsibility areas essentially operating on their own anyway.

Re: Why kernel development still uses email

#50

Post by Aldo_MX »

Klathmon wrote: post #9
na85 wrote: post #5

I find the idea that a technology should be replaced simply because it is old to be very irksome. Those developers out there blindly contributing to the trend of replacing "tried and true" with "new and shiny" really need to take a step back and gain some perspective. Email works great for the vast, vast majority of users.

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

Why is people always concerned about lowering the barrier to entry just because they felt dismotivated by it?

Reviewer's time is a commodity, especially in a project like the kernel, accepting new patches is not a process that scales well when you receive thousands of potentially low-quality patches.

It's a tradeoff, you get less patches but the reviewers can actually focus their efforts in accepting them.

Post reply on HN