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

51–60 of 152 posts

Re: Why kernel development still uses email

#51

Post by cel1ne »

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…

> There is this weird myth that Email magically kills productivity while Slack and GitHub don't.

Yes. I really can't abide chat for work. If I have time and need synchronous communication, I make a phone call.

Email forces me to think my communication through, and I can explicitly CC/BCC other people if I feel that they need to read my letter.

PS: I find it telling that the product is actually called "Slack". ;)

Re: Why kernel development still uses email

#52

Post by adrianratnapala »

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…

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.

Re: Why kernel development still uses email

#53

Post by adrianratnapala »

justincormack wrote: post #47
Manishearth wrote: post #21

Earlier quoted context omitted.

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.

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.

Re: Why kernel development still uses email

#54

Post by kiallmacinnes »

adrianratnapala wrote: post #52
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…

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.

Gerrit does have "one commit, one review", but - that's not a bad thing. If a change is well written and structured, merging the first in the chain without the second+ is both harmless and is progress towards the end goal.

There's also patch chains in Gerrit, so you can see the X commits that make up the full change, and the second+ cannot be merged before the first.

Re: Why kernel development still uses email

#55

Post by raverbashing »

DSMan195276 wrote: post #7

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…

Also, some kernel developers don't want to open a graphic terminal while they're doing their job

Re: Why kernel development still uses email

#56

Post by csl »

Too wrote: post #49
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.

Right, you could do that and probably do it well.

I was mostly thinking about the simple matter of scaling the resources and maintenance crew to tackle 4000 devs. But my biggest concern about it is that it introduces centralization into the workflow. I do truly love Gerrit, but I get a bit worried about keeping a lot of important stuff in a centralized and not so transparent database.

Re: Why kernel development still uses email

#57

Post by Daviey »

The article totally missed the mark on Gerrit. I think the heavy user is now OpenStack and not Android...

The article claims that Gerrit is just a small part, but if used fully it really isn't. It can be used to track the entire patch lifecycle. Which LKML doens't do via email.. because it isn't very good at it... it uses 'patchwork'.

OpenStack uses Gerrit to manage 537 git repositories. In the last year, 86,027 changesets were merged in the last year out of 111,292 commits. [0]

The real values are the smart searching capability (with email subscription to that search),integration with CI, inline code reviews.. simple rebasing, acls and easy digestion who reviewed.

Once setup, the workflow is super simple:

  $ git commit
  $ git review
  $ # celebrate success
Further, why all the hate on project managers?

[0] http://activity.openstack.org/dash/browser/

Re: Why kernel development still uses email

#59

Post by usgroup »

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…

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?

Re: Why kernel development still uses email

#60

Post by makomk »

dredmorbius wrote: post #24
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 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 required by kernel development. So the only clients that meet the criteria are the ones that don't care about being a pain in the ass to use, and this permeates the entire user experience.) This isn't an issue for the core kernel developers because they already have a suitable e-mail client configured and installed which they're used to using, and because they're generally not submitting patches that way anyway.
Post reply on HN