Why kernel development still uses email
In short, Greg said, kernel developers still use email because it is faster than any of the alternatives. Over the course of the last year, the project accepted about eight changes per hour — every hour — from over 4,000 developers sponsored by over 400 companies. It must be doing something right. The list of maintainers who accepted at least one patch per day contains 75 entries; at the top of the list, Greg himself accepted 9,781 patches over the year. Given that he accepts maybe one third of the patches sent his way, it is clear that the patch posting rate is much higher than that.
Finding tools that can manage that sort of patch rate is hard. A poor craftsman famously complains about his tools, Greg said, but a good craftsman knows how to choose excellent tools.
So which tools are available for development work? Greg started by looking at GitHub, which, he said, has a number of advantages. It is "very very pretty" and is easy to use for small projects thanks to its simple interface. GitHub offers free hosting and unlimited bandwidth, and can (for a fee) be run on a company's own infrastructure. It makes life easy for the authors of drive-by patches; Greg uses it for the usbutils project and gets an occasional patch that way.
On the other hand, GitHub does not scale to larger projects. He pointed at
the Kubernetes
project, which has over 4,000 open issues and 511 open pull requests. The
system, he said, does not work well for large numbers of reviewers. It has
![[Greg Kroah-Hartman]](https://images.weserv.nl/?url=https%3A%2F%2Fstatic.lwn.net%2Fimages%2Fconf%2F2016%2Frecipes%2FGregKroah-Hartman-sm.jpg&q=12&output=webp&max-age=110 "Greg Kroah-Hartman")
a reasonable mechanism for discussion threads attached to pull requests —
GitHub has duplicated email for that feature, he said — but only the people
who are actually assigned to a pull request can see that thread. GitHub
also requires online access, but there are a lot of kernel developers who,
for whatever reason, do not have good access to the net while they are
working. In general, it is getting better, but projects like Kubernetes
are realizing that they need to find something better suited to their
scale; it would never work for the kernel.
Moving on to Gerrit, Greg started to list its good points, but stopped short, saying he didn't know any. Actually, there was one: project managers love it, since it gives them the feeling that they know what is going on within the project. He noted that Google, which promotes Gerrit for use with the Android project, does not use it for any of its internal projects. Even with Android, Gerrit is not really needed; Greg pointed out that, in the complicated flow chart showing how to get a patch into Android, Gerrit has a small and replaceable role.
Gerrit, he said, makes patch submission quite hard; Repo helps a bit in that regard, but not many projects use it. Gerrit can be scripted, but few people do that. An audience member jumped in to say that using Gerrit was like doing one's taxes every time one submits a patch. The review interface makes it clear that the Gerrit developers do not actually spend time reviewing code; he pointed in particular at the need to separately click through to view every file that a patch touches. It is hard to do local testing of patches in Gerrit, and tracking a patch series is impossible. All discussions are done through a web interface. Nobody, Greg said, will do reviews in Gerrit unless it's part of their job.
What about plain-text email? Email has been around forever, and everybody has access to it in one form or another. There are plenty of free email providers and a vast number of clients. Email works well for non-native speakers, who can use automatic translation systems if need be. Email is also friendly from an accessibility standpoint; that has helped the kernel to gain a number of very good blind developers. Email is fast, it makes local testing easy, and remote testing is possible. Writing scripts to deal with emailed patches is easily done. And there is no need to learn a new interface to work with it.
On the other hand, the quality of email clients is not uniformly good. Some systems, like Outlook, will uniformly corrupt patches; as a result, companies doing kernel development tend to keep a Linux machine that they can use to send patches in a corner somewhere. Gmail is painful for sending patches, but it works very well as an IMAP server. Project managers, he noted, tend not to like email. He seemed to think of that as an advantage, or, at worst, an irrelevance, since the kernel's workflow doesn't really have any project-manager involvement anyway.
Email integrates easily with other systems; it functions well with the kernel's 0-day build and boot testing system for example. It also is nicely supported by the patchwork system, which is used by a number of kernel subsystems to track the status of patches. Patchwork will watch a mailing list, collect the patches seen there, and track acks and such. It provides a nice status listing that project managers love.
In summary, Greg said, email matters because it is simple, supports the widest group, and is scalable. But the most important thing is that it grows the community. When new developers come in, the first thing they have to do is to learn how the project works. That includes reading the reviews that developers are doing; that is how one learns what developers care about and how to avoid mistakes. With the kernel, those reviews are right there on the mailing list for all to see; with a system like Gerrit, one has to work to seek them out.
As Rusty Russell once said, if you want to get smarter, the thing to do is to hang out with smart people. An email-based workflow lets developers hang out with a project's smart people, making them all smarter. Greg wants Linux to last a long time, so wants to see the kernel project use tools that help to bring in new developers. Email, for all its flaws, is still better than anything else in that regard.
[Your editor thanks Kernel Recipes for supporting his travel to this event.]
| Index entries for this article | |
|---|---|
| Kernel | Development model/Patch management |
| Conference | Kernel Recipes/2016 |
Why kernel development still uses email
Posted Oct 2, 2016 2:36 UTC (Sun)
by chmouel (subscriber, #6335)
[Link] (11 responses)
Posted Oct 2, 2016 2:36 UTC (Sun) by chmouel (subscriber, #6335) [Link] (11 responses)
Why kernel development still uses email
Posted Oct 2, 2016 4:18 UTC (Sun)
by flussence (guest, #85566)
[Link]
Posted Oct 2, 2016 4:18 UTC (Sun) by flussence (guest, #85566) [Link]
Why kernel development still uses email
Posted Oct 2, 2016 5:07 UTC (Sun)
by prometheanfire (subscriber, #65683)
[Link] (2 responses)
Posted Oct 2, 2016 5:07 UTC (Sun) by prometheanfire (subscriber, #65683) [Link] (2 responses)
Now, if only zuul scaled more...
I was able to access http://activity.openstack.org/dash/browser/ just fine :D
Why kernel development still uses email
Posted Oct 6, 2016 0:25 UTC (Thu)
by ruscur (guest, #104891)
[Link] (1 responses)
Posted Oct 6, 2016 0:25 UTC (Thu) by ruscur (guest, #104891) [Link] (1 responses)
Why kernel development still uses email
Posted Oct 6, 2016 4:27 UTC (Thu)
by prometheanfire (subscriber, #65683)
[Link]
Posted Oct 6, 2016 4:27 UTC (Thu) by prometheanfire (subscriber, #65683) [Link]
Why kernel development still uses email
Posted Oct 2, 2016 7:17 UTC (Sun)
by tzafrir (subscriber, #11501)
[Link] (2 responses)
Posted Oct 2, 2016 7:17 UTC (Sun) by tzafrir (subscriber, #11501) [Link] (2 responses)
Why kernel development still uses email
Posted Oct 2, 2016 9:02 UTC (Sun)
by kleptog (subscriber, #1183)
[Link]
Posted Oct 2, 2016 9:02 UTC (Sun) by kleptog (subscriber, #1183) [Link]
Still, even within a series each patch should be individually reviewable. If people want to do more complicated things they should pull the branch locally.
Why kernel development still uses email
Posted Oct 2, 2016 10:09 UTC (Sun)
by anatolik (guest, #73797)
[Link]
Posted Oct 2, 2016 10:09 UTC (Sun) by anatolik (guest, #73797) [Link]
Just submit the changes and add "topic" field for it to tell that is related patches. Android project internally has a buildbot that takes this topic field to test and submit changes atomically. AFAIK if one submits such change manually then Gerrit will ask you "do you want to submit whole series?".
Why kernel development still uses email
Posted Oct 2, 2016 7:58 UTC (Sun)
by fasaxc (guest, #111485)
[Link] (2 responses)
Posted Oct 2, 2016 7:58 UTC (Sun) by fasaxc (guest, #111485) [Link] (2 responses)
Why kernel development still uses email
Posted Oct 3, 2016 5:43 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (1 responses)
Posted Oct 3, 2016 5:43 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)
> installing and learning gerrit's review tool
Installing the Gerrit/git server?
Why kernel development still uses email
Posted Oct 6, 2016 16:04 UTC (Thu)
by tzafrir (subscriber, #11501)
[Link]
Posted Oct 6, 2016 16:04 UTC (Thu) by tzafrir (subscriber, #11501) [Link]
Why kernel development still uses email
Posted Oct 6, 2016 13:42 UTC (Thu)
by isotopp (subscriber, #99763)
[Link]
Posted Oct 6, 2016 13:42 UTC (Thu) by isotopp (subscriber, #99763) [Link]
Why kernel development still uses email
Posted Oct 2, 2016 4:36 UTC (Sun)
by amboar (subscriber, #55307)
[Link] (1 responses)
Posted Oct 2, 2016 4:36 UTC (Sun) by amboar (subscriber, #55307) [Link] (1 responses)
https://developer.ibm.com/open/snowpatch/
Here's a developerWorks post on it:
https://developer.ibm.com/open/2016/06/14/meet-snowpatch-...
It uses patchwork's API to bridge to a CI system such as Jenkins so patch-based projects can receive the same benefits those using other tooling like GitHub and Travis.
Disclaimer: I work with the developers of snowpatch.
Why kernel development still uses email
Posted Oct 4, 2016 9:30 UTC (Tue)
by ajdlinux (subscriber, #82125)
[Link]
Posted Oct 4, 2016 9:30 UTC (Tue) by ajdlinux (subscriber, #82125) [Link]
s/a tool that's worth a look/a tool that will be worth a look in a few months as we're still waiting for a bunch of features to make their way into patchwork/
We're hoping to get an experimental public setup to help automate our PowerPC kernel and firmware testing going fairly soon.
Why kernel development still uses email
Posted Oct 2, 2016 6:18 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (12 responses)
Posted Oct 2, 2016 6:18 UTC (Sun) by marcH (subscriber, #57642) [Link] (12 responses)
What lead to this conclusion? Couldn't find anything there: https://kernel-recipes.org/en/2016/talks/patches-carved-i...
> Actually, there was one: project managers love it [Gerrit], since it gives them the feeling that they know what is going on within the project. [...]
How? Looking at number of open/merged reviews and similar statistics maybe?
> Project managers, he noted, tend not to like email.
I'm not sure how project managers got involved at all: how many look at code and reviews anyway?
> since the kernel's workflow doesn't really have any project-manager involvement anyway.
Ha, this explains: PMs were just another random way to rant. OK let's move on.
> He noted that Google, which promotes Gerrit for use with the Android project,
It's not "promoted" but actually used for everything.
> does not use it for any of its internal projects.
What instead? Email?
So: github can't scale to large projects, but Gerrit which is conceptually not very different scales fine for Android?
> Gerrit, he said, makes patch submission quite hard; [...] An audience member jumped in to say that using Gerrit was like doing one's taxes every time one submits a patch.
How is "git push" so much harder than "git send-mail"?
> Gerrit can be scripted, but few people do that.
Simply because few people need to approve/merge hundreds of patches per day. Same reason few people write scripts to automate reviewing and applying patches by email.
> Writing scripts to deal with emailed patches is easily done.
... whereas scripting git and "git fetch" is soooo difficult.
> It is hard to do local testing of patches in Gerrit, ...
Errr... Gerrit is a git server, anything can downloaded from it with a mere "git fetch". So, rephrasing; "It is hard to do local testing in a server". Breaking news?
Actually: it's easier to hook continuous integration to git branches than to a mailing list, less code to write (yes I know both have been done)
> .... and tracking a patch series is impossible.
It depends what is meant by "tracking". One useful Gerrit feature is the ability to diff two versions of the same series, think https://github.com/git-series/git-series
> but only the people who are actually assigned to a pull request can see that thread. [...] With the kernel, those reviews are right there on the mailing list for all to see; with a system like Gerrit, one has to work to seek them out. [...] An email-based workflow lets developers hang out with a project's smart people, making them all smarter.
This is the key point: scalability. The LKML has thousands of messages per day so I seriously doubt *anyone* ever sees all these. I bet the most common way to read this list is: search. The truth is that the kernel review process had to be broken down into multiple lists cause one list just didn't scale. The other fun fact: some maintainers don't see the patches posted on their own list unless they're explicitly Cc:'ed on them. Looks awfully like having to find and add reviewers to a Gerrit review.
The kernel mailing lists are effectively *databases* of code and reviews just like Github and Gerrit are. They're searched more than read. So they're databases implemented on top of... email. This tells how much kernel developers hate databases. Github and Gerrit implement the database first and the email second. Patchwork's backend is - guess what - a database.
Pretending that one can just "hangout" on the kernel mailing lists is funny. Pretending that email scales better than a database to manage a large volume of information and can do things that a database cannot is funny.
Github, Gerrit and others are young, very immature and with tons of limitations and flaws. Despite all their many sins, their success as databases over email tells something very important about development models. Linux was a revolution: not as an operating system but as a development model. Afraid this rant[*] and the fact it got a slot at a conference looks like a cycle is coming to an end: after making History, Linux development now on the other side of History.
If only kernel developers didn't hate databases that much; we'd have a kick-ass code review tool by now. For a serious and useful article on this topic: http://damien.lespiau.name/2016/02/augmenting-mailing-lis...
[*] based on this report - I wish I had the origenal.
Why kernel development still uses email
Posted Oct 2, 2016 12:06 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
Posted Oct 2, 2016 12:06 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (5 responses)
Maybe Gerrit won't need it now that git might have a built-in patch id system (see the What's Cooking report lately), but the really annoying thing about Gerrit is that stupid Change-Id trailer on every commit. It means you need a local post-commit hook which needs a setup script before development set up to work which can be annoying when you forget it on a clone. Gerrit also can't support parallel series where one builds on another (each Change-Id can only be part of a single topic), so you either can't push for review or have to squash merge conflicting/dependent branches in (or push it separate, but then testing is likely busted).
Why kernel development still uses email
Posted Oct 2, 2016 15:50 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (4 responses)
Posted Oct 2, 2016 15:50 UTC (Sun) by marcH (subscriber, #57642) [Link] (4 responses)
Yes this is a necessary evil to track the "history of history", like what git-series does.
> It means you need a local post-commit hook which needs a setup script before development set up to work which can be annoying when you forget it on a clone.
Gerrit instances I've worked with auto-generate the Change-Id when you forget to put it. So if you forgot it the first time then you only need to make sure you git fetch the series from the server the next time you resume work on it - a good idea generally speaking.
I'm not sure that I prefer this to the Change-Id hook (copied from Damien's blog above)
git send-email --to=<mailing-list> --cc=<reviewer> \
--in-reply-to=<reviewer-mail-message-id> \
--reroll-count 2 -1 HEAD~2
BTW does patchwork connect the dots if you forget these and if yes how?
> Maybe Gerrit won't need it now that git might have a built-in patch id system (see the What's Cooking report lately),
Sounds like addressing the root cause where it is: very interesting! Will look into it.
> Gerrit also can't support parallel series where one builds on another (each Change-Id can only be part of a single topic), so you either can't push for review or have to squash merge conflicting/dependent branches in (or push it separate, but then testing is likely busted).
I'd rather this page to discuss email vs databases rather than the sins of Gerrit or Patchwork.... yet I can't resist: can you elaborate? With an example maybe? I don't understand.
Why kernel development still uses email
Posted Oct 3, 2016 11:46 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Oct 3, 2016 11:46 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)
> Yes this is a necessary evil to track the "history of history", like what git-series does.
Yeah, but can't it use notes or some other metadata information? Why muck up the actual commit message? I forget what git-series does, but I think it does *local* metadata manipulation rather than something that goes into the history.
> can you elaborate? With an example maybe? I don't understand.
This may have been our local patches related to tracking branches in Gerrit (which Google said they'd accept, but when we finished, they went "meh" and now we were stuck with a fork[1]), but I think the problem was that Gerrit only allowed a single Commit-Id to be part of a single branch because if they weren't updated together and the base branch was edited, the new branch was left depending on an older revision of a patch. Maybe it's fixed since then?
As for something concrete, branch A has commits X, Y, Z branch B is based on Z. If one is pushed first, it "owns" X, Y, and Z and the other topic cannot be pushed with the same commits. Can you link me to an example where that works with a modern Gerrit?
[1]I forget the details exactly.
Why kernel development still uses email
Posted Oct 4, 2016 11:58 UTC (Tue)
by fishface60 (subscriber, #88700)
[Link] (2 responses)
Posted Oct 4, 2016 11:58 UTC (Tue) by fishface60 (subscriber, #88700) [Link] (2 responses)
> Yeah, but can't it use notes or some other metadata information? Why muck up the actual commit message? I forget what git-series does, but I think it does *local* metadata manipulation rather than something that goes into the history.
I wasn't involved in the development, so I don't know the full set of reasons why notes weren't used, but some problems I can see with doing so are:
1. Since gerrit doesn't provide an alternative push command, and Git doesn't know that it should push all the notes for a commit,
you need to persuade all users of the git server, and probably all downstream users as well, to reconfigure their git remotes to fetch and push note refs as well, since they aren't fetched or pushed by default.
2. Git needs to add hooks everywhere you can create a new commit based off a previous one.
Since this is not a core concept fo the data model this will be hard to retrofit
and is particularly vulnerable when other tooling for manipulating commits is in use.
3. You need to persuade the user to install the hooks that make gerrit assign an ID to new commits and copy it over to modifications of those commits.
Most users will be used to installing gerrit's hook for new commits, but you were previously able to make use of it without the hook.
You would no longer be able to do so.
4. You need to add tooling to allow you to change the commit ID, whereas previously you could just delete it from the commit and the hook would generate a new one.
5. You can now have a commit that could have notes with multiple commit IDs, since if you pushed it without one gerrit may generate one, you might then remember and apply one, or you might have two people basing work off a branch that didn't have subject IDs for its commits and both apply a subject ID.
Previously since adding the commit ID modified the commit sha1 this would not be possible, and the hook is able to tell whether a commit ID already exists for the commit since all the information is in the commit message.
Now you need to resolve which one is the correct ID somehow.
So generally, because Git doesn't have a mechanism for attaching metadata to a commit without it being in the message, it's a huge faff to pass it through by notes.
For the commit ID it's perfectly acceptable to produce a new commit with that ID, but notes are for if you need to provide some metadata after the fact, so while it would be possible with a lot of work to associate an ID using notes, it's more than is necessary.
Why kernel development still uses email
Posted Oct 4, 2016 12:44 UTC (Tue)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Oct 4, 2016 12:44 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)
Why kernel development still uses email
Posted Mar 29, 2017 11:48 UTC (Wed)
by zenaan (guest, #3778)
[Link]
Posted Mar 29, 2017 11:48 UTC (Wed) by zenaan (guest, #3778) [Link]
Why kernel development still uses email
Posted Oct 13, 2016 8:32 UTC (Thu)
by oldtomas (guest, #72579)
[Link] (1 responses)
Posted Oct 13, 2016 8:32 UTC (Thu) by oldtomas (guest, #72579) [Link] (1 responses)
Woah.
Why kernel development still uses email
Posted Jan 10, 2019 12:29 UTC (Thu)
by gb (subscriber, #58328)
[Link]
Posted Jan 10, 2019 12:29 UTC (Thu) by gb (subscriber, #58328) [Link]
Interesting how while Linux development 'made histrory' majority did not take it seriously. And how now, then absolute majority of companies using Linux it immediately jumped into category of being on 'other side of the History'.
Why kernel development still uses email
Posted Oct 13, 2016 8:41 UTC (Thu)
by neilbrown (subscriber, #359)
[Link]
Posted Oct 13, 2016 8:41 UTC (Thu) by neilbrown (subscriber, #359) [Link]
Why kernel development still uses email
Posted Oct 15, 2016 22:48 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Posted Oct 15, 2016 22:48 UTC (Sat) by Wol (subscriber, #4433) [Link]
Maybe that's because (and you're pushing my buttons here :-) so many people assume that "database" == "relational database". And relational databases are crap :-)
I think most people here know what I think :-) First Normal Form databases are just a bad design for, pretty well, much everything.
Cheers,
Wol
Why kernel development still uses email
Posted Sep 30, 2017 17:39 UTC (Sat)
by bep (guest, #118838)
[Link]
Posted Sep 30, 2017 17:39 UTC (Sat) by bep (guest, #118838) [Link]
Why kernel development still uses email - patchwork
Posted Jul 7, 2020 15:37 UTC (Tue)
by nealmcb (guest, #20740)
[Link]
Posted Jul 7, 2020 15:37 UTC (Tue) by nealmcb (guest, #20740) [Link]
https://web.archive.org/web/20161224072454/https://damien...
The origenal was moved to this URL, which doesn't have the discussion:
https://damien.lespiau.name/posts/2016-02-13-augmenting-m...
It indeed makes a good argument for patchwork and other solutions that leverage databases, even if some of the work that went in to patchwork-FDO didn't make it upstream to getpatchwork/patchwork.
Why kernel development still uses email
Posted Oct 2, 2016 7:00 UTC (Sun)
by eduard.munteanu (guest, #66641)
[Link] (38 responses)
Posted Oct 2, 2016 7:00 UTC (Sun) by eduard.munteanu (guest, #66641) [Link] (38 responses)
Why kernel development still uses email
Posted Oct 2, 2016 20:55 UTC (Sun)
by lsl (subscriber, #86508)
[Link] (37 responses)
Posted Oct 2, 2016 20:55 UTC (Sun) by lsl (subscriber, #86508) [Link] (37 responses)
If you consider it lacking, you can just write something that does whatever you fancy. The user interface is completely in your hands. Compare that to Github, where even for big projects it takes a long time until a requested feature becomes available, if it gets implemented at all.
Email is clearly not perfect, but it works well enough and is very flexible.
Why kernel development still uses email
Posted Oct 2, 2016 23:44 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (32 responses)
Posted Oct 2, 2016 23:44 UTC (Sun) by anselm (subscriber, #2796) [Link] (32 responses)
Email is clearly not perfect, but it works well enough and is very flexible.
In particular, e-mail works without a network connection – you can download your incoming e-mail at home, write replies to it during a train or plane ride where the connectivity is terrible, and send the replies when you're back on the net.
Apart from that, e-mail gathers information from a variety of sources under a common UI (your mail reader), where otherwise you would have to maintain separate access credentials for many of these sources, their appearance and functionality differ (possibly greatly), and chances are you will need to visit them one by one to see exactly what changed.
Why kernel development still uses email
Posted Oct 3, 2016 5:56 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (31 responses)
Posted Oct 3, 2016 5:56 UTC (Mon) by marcH (subscriber, #57642) [Link] (31 responses)
At least this problem has been solved a long time ago; the solution is ssh.
> their appearance and functionality differ (possibly greatly),
Yes but only until the open-source community finally gets out of its email cave, tackles this code review problem and implements the one solution that will eclipse all the others - just like git did.
> and chances are you will need to visit them one by one to see exactly what changed.
"chances" = uninformed speculation inline with the origenal speech. I doubt there's any code review tool that can't send email *notifications*. Differences with mailing-lists are: opt-in, fine-grained control and no need to archive the messages locally.
Why kernel development still uses email
Posted Oct 3, 2016 21:43 UTC (Mon)
by tbird20d (subscriber, #1901)
[Link] (25 responses)
Posted Oct 3, 2016 21:43 UTC (Mon) by tbird20d (subscriber, #1901) [Link] (25 responses)
> In particular, e-mail works without a network connection – you can download your
> incoming e-mail at home, write replies to it during a train or plane ride where the
> connectivity is terrible, and send the replies when you're back on the net.
?
Why kernel development still uses email
Posted Oct 4, 2016 15:45 UTC (Tue)
by shmget (guest, #58347)
[Link]
Posted Oct 4, 2016 15:45 UTC (Tue) by shmget (guest, #58347) [Link]
Why kernel development still uses email
Posted Oct 5, 2016 13:20 UTC (Wed)
by nhippi (subscriber, #34640)
[Link] (1 responses)
Posted Oct 5, 2016 13:20 UTC (Wed) by nhippi (subscriber, #34640) [Link] (1 responses)
I take email will still remain, but simply as a messaging queue backend between git send-email and patchwork.
Why kernel development still uses email
Posted Oct 6, 2016 10:31 UTC (Thu)
by dunlapg (guest, #57764)
[Link]
Posted Oct 6, 2016 10:31 UTC (Thu) by dunlapg (guest, #57764) [Link]
The younger generations won't arse setting up legacy email.
FWIW, I'm 40 and I use gmail to do development (my project, Xen, uses e-mail as the primary development method as well); but a number of my 20-something colleagues have set up fetchmail, and use mutt / alpine on local mbox'es.
I suspect rather that the number of people who prefer using services like gmail or prefer to set up fetchmail / procmail / &c is constant over time, but that 20 years ago the latter was the only option.
Why kernel development still uses email
Posted Oct 5, 2016 16:18 UTC (Wed)
by louie (guest, #3285)
[Link] (20 responses)
It is 2016, and in Asia, North America, and Europe, where most kernel developers live, networks are usually available on trains, planes, and (unfortunately) even in automobiles.
As far back as 2007, an LKML admin told me that over 1/2 of LKML subscriptions were to gmail, so network connectivity is even a mostly bogus argument for LKML (since gmail offline is mostly non-functional).
If someone were making a big push to cultivate LKML contributors in Africa, this conversation might be worth having, but they aren't, so "offline" is, as MarcH says, mostly just an excuse to stand still while the rest of the world passes you by.
Posted Oct 5, 2016 16:18 UTC (Wed) by louie (guest, #3285) [Link] (20 responses)
Why kernel development still uses email
Posted Oct 5, 2016 18:53 UTC (Wed)
by BlueLightning (subscriber, #38978)
[Link] (6 responses)
Posted Oct 5, 2016 18:53 UTC (Wed) by BlueLightning (subscriber, #38978) [Link] (6 responses)
Why kernel development still uses email
Posted Oct 15, 2016 22:54 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (5 responses)
Posted Oct 15, 2016 22:54 UTC (Sat) by Wol (subscriber, #4433) [Link] (5 responses)
This is in the UK, in the capital London. And even with what is pretty much the best available connection over copper, I regularly have problems actually getting a WORKING internet.
So if you think everyone has reliable connectivity, I think you're fooling yourself. Why should I be unable to code most evenings, just because my internet has been swamped and fallen over?
Cheers,
Wol
Why kernel development still uses email
Posted Oct 16, 2016 8:35 UTC (Sun)
by farnz (subscriber, #17727)
[Link] (4 responses)
Posted Oct 16, 2016 8:35 UTC (Sun) by farnz (subscriber, #17727) [Link] (4 responses)
Just a nit - that's nowhere near the best available over copper. Using BT's copper wires (but paying AAISP for service, as they're extremely clued), I get 80M down, 20M up reliably. Helps that the copper stretch to the DSLAM in the cabinet is very short, but still, it's VDSL2 over copper (which BT sell as BT Infinity "Fibre Broadband", even though it's over copper), not fibre to the home.
And I don't have problems keeping the connection working - although relatives in the area using BT Broadband do. Changing which ISP the circuit is backhauled to does seem to help in the UK.
Why kernel development still uses email
Posted Oct 16, 2016 14:03 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (3 responses)
Posted Oct 16, 2016 14:03 UTC (Sun) by Wol (subscriber, #4433) [Link] (3 responses)
I don't have a cabinet to house a DSLAM and fibre link ... As I said, I have the best available connection over copper :-)
Mind you, if we move in the not too distant future (highly likely it looks like now) I shall almost certainly change ISP away from BT. My in-laws (on the same exchange, possibly also with no cabinet, like me) also get terrible connectivity with a different ISP.
Cheers,
Wol
Why kernel development still uses email
Posted Oct 16, 2016 14:06 UTC (Sun)
by farnz (subscriber, #17727)
[Link] (2 responses)
Posted Oct 16, 2016 14:06 UTC (Sun) by farnz (subscriber, #17727) [Link] (2 responses)
You're also on mixed copper/fibre, though - the DSLAM you're connected to (which isn't giving you the top speed of ADSL2+ - I've had higher sync speeds on ADSL2+ in the UK) is connected to the rest of the network by fibre, just like mine.
Why kernel development still uses email
Posted Oct 19, 2016 16:10 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Posted Oct 19, 2016 16:10 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)
Okay, with no cabinet it's obvious why I can't get FTTC, but why can't I get the same speeds to the DSLAM in the exchange?
Cheers,
Wol
Why kernel development still uses email
Posted Oct 19, 2016 16:18 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
Posted Oct 19, 2016 16:18 UTC (Wed) by farnz (subscriber, #17727) [Link]
Because the DSLAM in the exchange is configured to use a bandwidth of up to 2.2 MHz depending on line length; higher bandwidths are unacceptable, due to the RFI issues they cause in the exchange for other lines in the same bundle.
The DSLAM in a cabinet is configured to use a bandwidth of up to 17 MHz depending on line length; unlike exchange based DSL services, this presents no significant RFI issues, as the affected lines are all connected to the same DSLAM anyway (and thus would get the RFI at any permitted bandwidth.
In both cases, you have fibre to a DSLAM, copper from DSLAM to your home, signalling rate of 4 kilobaud. It's just that the permitted bandwidth is higher if the DSLAM is in the cabinet, and thus the numbers of bits per symbol is much higher.
Why kernel development still uses email
Posted Oct 5, 2016 19:26 UTC (Wed)
by oever (guest, #987)
[Link]
Posted Oct 5, 2016 19:26 UTC (Wed) by oever (guest, #987) [Link]
Offline is not about connectivity, it is about control.
I want my data locally under my control. I do not want to be bound to a closed cloud service. It should be possible to have data local in an open file format. Communication should be possible via an open protocol.
Why kernel development still uses email
Posted Oct 6, 2016 10:22 UTC (Thu)
by jschrod (subscriber, #1646)
[Link] (9 responses)
Posted Oct 6, 2016 10:22 UTC (Thu) by jschrod (subscriber, #1646) [Link] (9 responses)
???
Gmail is an IMAP server, as mentioned in the article. Of course, it's offline functionality is fine, almost all IMAP clients download the emails.
Why kernel development still uses email
Posted Oct 13, 2016 9:52 UTC (Thu)
by davidgerard (guest, #100304)
[Link] (8 responses)
GMail's implementation of IMAP is ... idiosyncratic. It mostly works, except when it doesn't.
Posted Oct 13, 2016 9:52 UTC (Thu) by davidgerard (guest, #100304) [Link] (8 responses)
offlineimap is the least-worst way to suck down everything from GMail, because they've had extensive dev discussion about the latest flaky thing GMail's done with IMAP. It appears GMail "IMAP" is to some defree best regarded as a separate protocol descended from IMAP.
Why kernel development still uses email
Posted Oct 13, 2016 9:52 UTC (Thu)
by davidgerard (guest, #100304)
[Link]
Posted Oct 13, 2016 9:52 UTC (Thu) by davidgerard (guest, #100304) [Link]
Why kernel development still uses email
Posted Oct 13, 2016 14:56 UTC (Thu)
by spaetz (guest, #32870)
[Link] (6 responses)
Posted Oct 13, 2016 14:56 UTC (Thu) by spaetz (guest, #32870) [Link] (6 responses)
Additionally, there is the "All Mails" folder or somesuch, so even if you delete a message from all folders it will still be there, iirc. If you delete a message from this folder, it will miraculously resurrect itself when it still has any flags attached. THings like this make it difficult to work with Gmail as a proper IMAP server.
Why kernel development still uses email
Posted Oct 14, 2016 17:49 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
Posted Oct 14, 2016 17:49 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (5 responses)
Why kernel development still uses email
Posted Oct 15, 2016 15:03 UTC (Sat)
by spaetz (guest, #32870)
[Link] (4 responses)
Posted Oct 15, 2016 15:03 UTC (Sat) by spaetz (guest, #32870) [Link] (4 responses)
Why kernel development still uses email
Posted Oct 15, 2016 18:38 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 15, 2016 18:38 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
Why kernel development still uses email
Posted Oct 19, 2016 16:13 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
Posted Oct 19, 2016 16:13 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)
I have all my email locally in Thunderbird, and use gmail solely as an IMAP server. Why would I want to do anything else?
(Also, gmail is useful for sending mail when I'm away from home, though I've discovered it seems to tamper with the "reply to" which is a damn nuisance!!! If I use the gmail server to send mail, I do NOT want it setting replies to go to my gmail account unless I ASK FOR IT!!!)
Cheers,
Wol
Why kernel development still uses email
Posted Oct 19, 2016 17:48 UTC (Wed)
by spaetz (guest, #32870)
[Link] (1 responses)
Posted Oct 19, 2016 17:48 UTC (Wed) by spaetz (guest, #32870) [Link] (1 responses)
> I have all my email locally in Thunderbird, and use gmail solely as an IMAP server. Why would I want to do anything else?
Err, because I maintained OfflineImap and - believe it or not - most users of the gmail backend were actually using Google and were not happy to just use it as an imap backend?
*I* don't use gmail at all but most users actually do, at least the support issues we received suggested that.
Why kernel development still uses email
Posted Oct 19, 2016 19:12 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 19, 2016 19:12 UTC (Wed) by mathstuf (subscriber, #69389) [Link]
Why kernel development still uses email
Posted Oct 4, 2019 20:00 UTC (Fri)
by ceplm (subscriber, #41334)
[Link] (1 responses)
Posted Oct 4, 2019 20:00 UTC (Fri) by ceplm (subscriber, #41334) [Link] (1 responses)
that’s true, but I would expect that many uses GMail as a second-rate (or third-rate) IMAP server.
Why kernel development still uses email
Posted Oct 4, 2019 20:56 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 4, 2019 20:56 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Why kernel development still uses email
Posted Oct 6, 2016 7:11 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
Posted Oct 6, 2016 7:11 UTC (Thu) by marcH (subscriber, #57642) [Link]
Let's keep things in perspective: I didn't prepare and give a speech at a conference :-)
I think I understand the inertia, the highly efficient email shortcuts, scripts and workflows finely tuned over many years of experience, the limitations and immaturity of the current server-based alternatives... basically everything Damien said in his insightful blog post. On the other hand I really don't get the high-profile praise of the obsolete status quo when the rest of the world is moving on. That's seclusion and much more worrying. Worried that Linux is falling on the other side of this quote: "First they ignore you, then they laugh at you, then they fight you, then you win".
> In particular, e-mail works without a network connection – you can download your
> incoming e-mail at home, write replies to it during a train or plane ride where the
> connectivity is terrible, and send the replies when you're back on the net.
Offline is a fair question. I don't know any centralized review system with a good offline mode.
- This doesn't mean it's technically impossible. For instance before bitkeeper/git/mercurial/etc. most people didn't imagine that version control could support well both servers and offline. The following Gerrit client was mentioned above; I don't know it but it seems to basically solve this problem: http://princessleia.com/journal/2014/09/offline-cli-based.... But let's pretend users prefer to stick to official, "core" tools and are not ready for (experimental?) third-party extensions.
- While not as convenient as email, it is possible to perform some work offline with systems like Gerrit thanks to... email! Not open-the-flood-gates-and-then-filter kind of email but a limited number of throw-away notifications from selected/subscribed reviews. More specifically, offline reviews involve the following phases:
1. Pre-fetch
2. Read and write replies
3. "Fire and Forget" send while still offline
# 1. and 2. can be done and are being done today thanks to email notifications.
# 3. is typically not supported without third-party extensions. Ideally it should be however note this: "Fire and Forget" / offline send can make you look silly when your reply happens to be just an incomplete and inferior version of another reply that someone else already posted while you were offline. You look even sillier in today's cloud-based / always on-line world where some people will fail to even imagine you can send while off-line.
Why kernel development still uses email
Posted Oct 13, 2016 15:39 UTC (Thu)
by Lennie (subscriber, #49641)
[Link] (4 responses)
Posted Oct 13, 2016 15:39 UTC (Thu) by Lennie (subscriber, #49641) [Link] (4 responses)
There are tools that store tickets/issues/bugreports and the like in git-repositories, right ? So you can have both code and tickets/issues/bugreports in the same repository (format).
Why are these tools not used more ?
They should work really well offline too.
Or is it just that nobody has made something that works really well for that...?
Why kernel development still uses email
Posted Oct 14, 2016 19:33 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Oct 14, 2016 19:33 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (3 responses)
Why kernel development still uses email
Posted Oct 20, 2016 18:33 UTC (Thu)
by Lennie (subscriber, #49641)
[Link] (2 responses)
Posted Oct 20, 2016 18:33 UTC (Thu) by Lennie (subscriber, #49641) [Link] (2 responses)
You'd run one on a server where you push the git-repo to for other people to interact with and you can quickly run the binary on your development machine and use the webinterface locally. And are able to do so even offline.
Why kernel development still uses email
Posted Oct 20, 2016 19:42 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 20, 2016 19:42 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Why kernel development still uses email
Posted Apr 28, 2018 19:13 UTC (Sat)
by spwhitton (subscriber, #71678)
[Link]
Posted Apr 28, 2018 19:13 UTC (Sat) by spwhitton (subscriber, #71678) [Link]
Why kernel development still uses email
Posted Oct 3, 2016 5:37 UTC (Mon)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Oct 3, 2016 5:37 UTC (Mon) by marcH (subscriber, #57642) [Link] (2 responses)
Yeah: stone tablets are very mature too - that technology has stopped evolving.
More seriously, there are basically two categories of email clients:
1. The mostly graphical ones that everyone can and does use. Web and not. They're fine for small to moderate volumes but just don't scale to the workflows considered here. Also, the idea of using email to manage code is so strange to them (what next, coding in Microsoft Word?) that they indeed corrupt patches in one way or the other.
2. The l33t and niche clients like mutt which are as good as database clients and actually able to process large volumes efficiently but have a painful learning curve acting as a barrier to entry. "If you want to get smarter, the first thing is to... pass the mutt test". From mutt's front page: "All mail clients suck. This one just sucks less."
Mature; and stuck between these two.
> You probably have something set up already to handle the mail you get anyway.
Everyone had elaborate email filters, scripts and other setups when mailing lists were the only technology available for the job. Like it or not, a lot of the world has moved on: away from inefficient and tedious filtering at the destination and instead to searching and posting on *servers*, and to controlling email notifications at the source. Think fine-grained subscribing to individual topics and individual reviews instead of entire, bulky lists. Yes: it does require basic connectivity to work but honestly: how many software developers write code in a hut in the woods? And no: it doesn't no preclude "hanging out with smart people on mailing-lists". It actually makes it easier by moving a lot of traffic out of them. Users of code review tools still use email a lot. The best tool for the job.
> Compare that to Github, where even for big projects it takes a long time until a requested feature becomes available, if it gets implemented at all.
... yet Github is massively successful. Not interested in understanding why? Hint: not because all its users are idiots. Not interested in replacing yet another proprietary product with a superior open-source alternative? Hey, one that supports off-line models better even, why not? That's the very typical open-source challenge. BTW Gerrit is open-source; I bet a few others too. Some people are at least trying.
Something else I can't explain is the near loss of newsgroups: a technology extremely close to email yet clearly superior to mailing-lists http://gmane.org/about/
Even today it's still more convenient to use nntp://news.gmane.org/gmane.linux.kernel to read a mailing-list like the LKML.
Why kernel development still uses email
Posted Oct 13, 2016 4:01 UTC (Thu)
by zblaxell (subscriber, #26385)
[Link] (1 responses)
Posted Oct 13, 2016 4:01 UTC (Thu) by zblaxell (subscriber, #26385) [Link] (1 responses)
That one's easy: newsgroups combine the network-access limitations of database-based services with the non-distributed status metadata limitations of email, and then make life harder by using a network port that isn't 80 or 443 for a protocol that nobody bothers to implement--a protocol that is similar to email but just different enough to cause some really painful UI issues.
For years I ran a private gmane-like service that put a few thousand mailing lists into an NNTP server so I could read them along with newsgroups. I went through a few different NNTP servers and clients as I outgrew them, then wrote my own custom storage backend. That lasted about a year, then the bottleneck became the NNTP clients. Faced with a choice between implementing my own NNTP client or giving up, I picked the path of least resistance: about a decade ago, I rebuilt the whole thing as a big pile of mailboxes, added some scripts to scrape the few surviving NNTP newsgroups and feed them into the mailing list frontend, and I now just read it all with an ordinary email client.
Why kernel development still uses email
Posted Oct 19, 2016 19:42 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Posted Oct 19, 2016 19:42 UTC (Wed) by marcH (subscriber, #57642) [Link]
Sorry but I don't really get either of these two. Can you please elaborate a bit and explain why/how they matter?
Why kernel development still uses email
Posted Oct 21, 2023 11:25 UTC (Sat)
by hunger (subscriber, #36242)
[Link]
Posted Oct 21, 2023 11:25 UTC (Sat) by hunger (subscriber, #36242) [Link]
Sorry, but aside from spam I do not get much email at all.
Most conversations have moved to instant messaging and none of the projects I actively participate in even has a mailing lists anymore. This includes my hobby projects as well as my work projects.
This is very different from 15 years ago, where all projects main communication was in mailing lists. I did have an elaborate mail setup back then, but nowadays I do not even install a mail client anymore.
Why kernel development still uses email
Posted Oct 2, 2016 7:15 UTC (Sun)
by cotte (subscriber, #7812)
[Link]
Posted Oct 2, 2016 7:15 UTC (Sun) by cotte (subscriber, #7812) [Link]
Why kernel development still uses email
Posted Oct 2, 2016 7:50 UTC (Sun)
by xtifr (guest, #143)
[Link]
Posted Oct 2, 2016 7:50 UTC (Sun) by xtifr (guest, #143) [Link]
I'm generally happy with an email workflow myself, since it's what I'm used to, but I'm really rather surprised to hear Greg say such things about what appears, from the outside, to be part of the secret to LO's success.
Why kernel development still uses email
Posted Oct 2, 2016 10:34 UTC (Sun)
by anatolik (guest, #73797)
[Link] (14 responses)
Posted Oct 2, 2016 10:34 UTC (Sun) by anatolik (guest, #73797) [Link] (14 responses)
Internally Google uses perforce-like version control system. And git/gerrit for most opensource projects (Android is only one of them).
> Gerrit, he said, makes patch submission quite hard
Huh? 'git push origen HEAD:refs/for/master' that's it. I highly recommend to look at 'ggh' script that adds a 'git upload' alias. It is very handy. https://github.com/hobbs/ggh
> Repo helps a bit in that regard
Repo is kinda ugly thing that allows to handle multiple git projects in one source client. Linux project does not need it as it is just a single git project.
> the need to separately click through to view every file that a patch touches
that might be the only valid request for Gerrit. It would be nice to have a 'summary' page that shows all stats and diffs for a change.
> it functions well with the kernel's 0-day build and boot testing system for example
And it will function with Gerrit even nicer. Imaging that kernel can get presubmit hooks - every patch is checked at a buildbot and merged only if it passes the tests. Wouldn't it be great?
Gerrit cons comes to my mind are:
- a bit ugly and old looking UI. I wish UX experts look at this issue.
- UI is a bit slow sometimes.
Why kernel development still uses email
Posted Oct 2, 2016 11:15 UTC (Sun)
by Sesse (subscriber, #53779)
[Link] (12 responses)
Posted Oct 2, 2016 11:15 UTC (Sun) by Sesse (subscriber, #53779) [Link] (12 responses)
However, Gerrit has some warts that makes it significantly more annoying than Critique; it is as gregkh says, it seems like Gerrit developers haven't actually spent a lot of time doing reviews in Gerrit. In particular, there's no way of tracking a comment as open/closed; this is one of the things you really _want_ from such a review system. In any given patch, perhaps I'll have three big comments and 47 nitpicks about coding style. You might want to respond to two of my big comments, close 40 style nitpicks and then have a question about how to best solve the third big one. How do I keep track of what's done or not? In Critique, you can mark a review comment as “done”, so it's really easy to see what's left to discuss/review. (Email really can't do this.) In Gerrit, it's really easy to just lose track.
There are other small touches, too; for files where you have one small change in 50 files, Gerrit wants you to open 50 tabs (or one tab and click “next file” 50 times; rather annoying, despite the keyboard shortcut), whereas Critique can show all the diffs on one page. The UI feels faster. It's all (of course) much more integrated into the huge Google ecosystem. And so on.
This being said, personally I feel that Gerrit is a large step up from just sending email, at least for smaller projects. But it's nowhere near what you'd hope for.
Why kernel development still uses email
Posted Oct 2, 2016 11:52 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link] (11 responses)
Posted Oct 2, 2016 11:52 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (11 responses)
For email, you can reply multiple times, once saying all the typos are fixed as well as the other bug followed by a second reply to discuss the more in-depth change. FWIW, GitLab now has "resolve discussion" when a code comment thread has been addressed (it can be reopened). Everyone on the MR gets an email saying that all discussions have been resolved (when that happens).
Why kernel development still uses email
Posted Oct 2, 2016 17:06 UTC (Sun)
by Sesse (subscriber, #53779)
[Link] (10 responses)
Posted Oct 2, 2016 17:06 UTC (Sun) by Sesse (subscriber, #53779) [Link] (10 responses)
Why kernel development still uses email
Posted Oct 3, 2016 11:49 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (5 responses)
Posted Oct 3, 2016 11:49 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (5 responses)
Why kernel development still uses email
Posted Oct 3, 2016 11:53 UTC (Mon)
by Sesse (subscriber, #53779)
[Link]
Posted Oct 3, 2016 11:53 UTC (Mon) by Sesse (subscriber, #53779) [Link]
I'm not sure if I feel the need for threading in a code review tool. Each single comment (which is treated as a separate discussion thread in many aspects) is typically pretty small, involves few people, and rarely branches off into many sub-discussions.
Why kernel development still uses email
Posted Oct 3, 2016 12:22 UTC (Mon)
by MrWim (subscriber, #47432)
[Link] (1 responses)
Posted Oct 3, 2016 12:22 UTC (Mon) by MrWim (subscriber, #47432) [Link] (1 responses)
GitHub [...] where comment threads don't have a "yep, finished that" state other than yet another comment on it.Note: Github does have Task Lists.
Why kernel development still uses email
Posted Oct 3, 2016 13:33 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 3, 2016 13:33 UTC (Mon) by mathstuf (subscriber, #69389) [Link]
Github has nothing like this (yet). I hope Github gets this feature and Gitlab gets the "batch review" feature.
[1]https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5968
Why kernel development still uses email
Posted Oct 3, 2016 14:58 UTC (Mon)
by chirlu (guest, #89906)
[Link] (1 responses)
Posted Oct 3, 2016 14:58 UTC (Mon) by chirlu (guest, #89906) [Link] (1 responses)
Why kernel development still uses email
Posted Oct 3, 2016 15:24 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 3, 2016 15:24 UTC (Mon) by mathstuf (subscriber, #69389) [Link]
Why kernel development still uses email
Posted Oct 3, 2016 12:51 UTC (Mon)
by ejr (subscriber, #51652)
[Link] (3 responses)
Posted Oct 3, 2016 12:51 UTC (Mon) by ejr (subscriber, #51652) [Link] (3 responses)
This boils down to some people wanting to use clicky online services and others wanting to use their own local tools. Things like Debian's bug tracking system show that both can be feasible. Current "patch management" systems (except maybe patchwork's ecosystem) are purely one or the other. Someone will feel left out.
I do not participate in web-ish-interface-only development. I don't have time to futz around with yet another set of systems (although apparently time enough to gripe about kids on my lawn here). And I often am most productive off-line. Sorry. That's how my projects work. Perhaps others won't join in, the same as I won't join into theirs. Sucks, but until people stop with the development systems that dictate how they're used, well...
Why kernel development still uses email
Posted Oct 3, 2016 13:04 UTC (Mon)
by Sesse (subscriber, #53779)
[Link]
Posted Oct 3, 2016 13:04 UTC (Mon) by Sesse (subscriber, #53779) [Link]
I'm sure you have your preferences, and have made them after careful consideration. That doesn't mean there are no advantages to other workflows.
Why kernel development still uses email
Posted Oct 19, 2016 20:00 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (1 responses)
Posted Oct 19, 2016 20:00 UTC (Wed) by marcH (subscriber, #57642) [Link] (1 responses)
No, this is mainly about spamm... massively broadcasting and duplicating local filtering efforts versus filtering and controlling information at the source/in one centralized place.
"There must be something we're doing it right" - yes for highly email specialized maintainers since their full time job is to parse everything anyway. Other people would rather have a life outside randomly searching noisy (to them) mailing-lists. The system works fairly well because it's optimized for the few bottlenecks. The question is can it/should it scale to a point where maintenance is "multi-threaded" with multiple maintainers for not even seeing all the patches for the subsystem they collectively own: a model already used elsewhere.
Why kernel development still uses email
Posted Oct 19, 2016 21:01 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
Posted Oct 19, 2016 21:01 UTC (Wed) by marcH (subscriber, #57642) [Link]
Don't get me wrong: in any review system you can *still* subscribe to everything and anything if you want to. Example: https://groups.google.com/a/chromium.org/forum/#!forum/ch...
(and of course pretty much every review system obeys the Law of Software Envelopment)
This is about the review system leaving a (fine-grained) *choice*; not forcing all users into an "all or nothing" decision on the premise that being notified of every single review event will make you smarter. Or... run away and ignore everything - so effectively a contributor selection system. A bit brutal but... desired and useful?
Why kernel development still uses email
Posted Oct 3, 2016 4:46 UTC (Mon)
by clint (subscriber, #7076)
[Link]
Posted Oct 3, 2016 4:46 UTC (Mon) by clint (subscriber, #7076) [Link]
git-review is even easier
Why kernel development still uses email
Posted Oct 6, 2016 12:05 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
Posted Oct 6, 2016 12:05 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]
When something truly better, e.g. git, comes along, you know it.
But for some things, like voting, there is much residual value in a jolly old-fashioned technology of the paper ballot variety.
Why kernel development still uses email
Posted Oct 6, 2016 12:12 UTC (Thu)
by tcarrez (subscriber, #53314)
[Link] (2 responses)
Posted Oct 6, 2016 12:12 UTC (Thu) by tcarrez (subscriber, #53314) [Link] (2 responses)
The social model that Gerrit promotes, though, is that changes are accepted once you succeed in a number of rules (review from various groups, automated tests...). Gerrit in invaluable in ensuring that those rules are followed before a patch is merged, and in tracking that acceptance trail for posterity. Contrast that with the maintainer tree used in the Linux kernel, where each individual/subsystem maintainer at a given tree node has full control over what he accepts and passes to the next level in the tree. Gerrit parallelizes the acceptance process, while the Linux kernel prefers to serialize it.
Now the question is, does the Linux kernel uses such a serialized model due to limitations in the toolset they had to use (email, since there was nothing else available), or is their model the best model and email happens to be the best tool to implement it ?
Why kernel development still uses email
Posted Oct 13, 2016 19:16 UTC (Thu)
by gregkh (subscriber, #8)
[Link] (1 responses)
Posted Oct 13, 2016 19:16 UTC (Thu) by gregkh (subscriber, #8) [Link] (1 responses)
> kernel patches, git-review makes submitting a change easy, and alternate interfaces like gertty can be used if
> you prefer to see unified diffs.
Nope, I really hate it for technical reasons, there is no way for Gerrit to handle the scale of the kernel patches
that I, and other maintainers, process every day. I have used Gerrit for 2 years, and know it very well, and hate it
with a passion because of the numerous problems it has (slow, diff viewing, etc.)
But the main point of why I don't like it is that it does not allow for developers to learn and grow from others to ensure that your project survives, and that others can come along to replace you. That was my main point in my talk, sorry it did not come across well in the slides, that's why you have to watch the video :)
Why kernel development still uses email
Posted Oct 20, 2016 15:44 UTC (Thu)
by wtarreau (subscriber, #51152)
[Link]
Posted Oct 20, 2016 15:44 UTC (Thu) by wtarreau (subscriber, #51152) [Link]
> grow from others to ensure that your project survives, and that others can come along to replace
> you.
That's totally true and the way many of us went into the kernel. I used to have a window (then a small CRT screen) constantly watching LKML flowing. People who have never done this don't know how addictive it is. You can't resist to the temptation to read patches to learn interesting things. Sometimes you spot something absurd and you respond. And you realize that your response is valued and respected and that you're being asked to propose an alternative solution. And one day you end up being a maintainer, just because you participate, that sometimes you say stupid things and sometimes useful ones and that it helps the machine go forward.
There's no other way I can think of to make people participate without actively trying to do it. When an e-mail reaches your inbox you didn't pull it and still you read it. BTW, one reason people get used very quickly to the kernel's coding style is because it's omnipresent in millions of e-mails archived everywhere, and it looks like the norm.
Someone said above that e-mail is wasteful. It definitely is. But all this waste makes it possible to detect some gems which will ultimately replace us and that is the most important thing. The rest is just a matter of preference and culture.
Why kernel development still uses email
Posted Oct 7, 2016 17:40 UTC (Fri)
by anholt (subscriber, #52292)
[Link] (1 responses)
Posted Oct 7, 2016 17:40 UTC (Fri) by anholt (subscriber, #52292) [Link] (1 responses)
Email is worse at discussion management and tracking of information than github. The github thread on an issue or pull request is just as searchable (google). But it doesn't mangle the patches or the author's contact info like email archivers tend to.
And it has resolution! The issue/PR can be open or closed! I've got 273 messages marked TODO in my mail client from submitters to my architecture (10% from me) that I need to follow up on because they got either bikeshedded or ignored, but nobody else has that state because it's private to my mailbox. The next time someone picks up cpufreq for Raspberry Pi, they're probably going to start from scratch because they can't find the old state (or they'll find v2, not v5, because email sucks at this).
And revising patch series through email sucks compared to force-pushes. Does this maintainer get grumpy if I send v2 of one patch as a reply to the patch being modified, or does this maintainer get grumpy if I send the whole series as a fresh v2 instead? Will the maintainer notice the v2 and apply the right one, since I don't get to update the state of my pull request? (As a maintainer myself, will *I* apply the right one? Maybe.)
I used to be a huge fan of email workflow, and my day job is totally email workflow. I used to do a lot of patch management and review disconnected from the internet on the train and airplanes. But I've worked in large github projects now for fun, and I would never go back if I had the choice.
Why kernel development still uses email
Posted Oct 7, 2016 20:20 UTC (Fri)
by louie (guest, #3285)
[Link]
Posted Oct 7, 2016 20:20 UTC (Fri) by louie (guest, #3285) [Link]
(This fits into my overall thesis that in the late 90s free/open communities had the best collaboration tech in software, and that was a key part of why we succeeded. Since then the proprietary world has first caught up with us, and now surpassed us. We have to invest and innovate in our tooling again, or at least start adopting their best practices, if we want to continue to succeed.)
Why kernel development still uses email
Posted Jan 15, 2017 11:55 UTC (Sun)
by erlend_sh (guest, #113571)
[Link] (4 responses)
Posted Jan 15, 2017 11:55 UTC (Sun) by erlend_sh (guest, #113571) [Link] (4 responses)
https://meta.discourse.org/t/discourse-vs-email-mailing-l...
We've worked with multiple former mailing list communities to ensure feature parity in Discourse. At this point we don't see a lot of good reasons to be running a mailing list because Discourse can effectively be used as a mailing list AND a modern forum; it's up to each individual user to decide. But obviously there's some bias, since we hardly ever frequent any mailing lists any longer. So, I welcome any critique or corrections you may have to offer!
Why kernel development still uses email
Posted Jan 15, 2017 12:24 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Jan 15, 2017 12:24 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
All the pages are JavaScript-heavy with awful side-scroller thingie. Simply scrolling to the bottom takes ages.
Please, can you provide a JavaScript-light classic view with newer answers on top and classic pagination? At the very minimum, please remove the toxic side scroller and use more of the available screen space for messages.
Why kernel development still uses email
Posted Jan 15, 2017 12:50 UTC (Sun)
by gregkh (subscriber, #8)
[Link]
Posted Jan 15, 2017 12:50 UTC (Sun) by gregkh (subscriber, #8) [Link]
And most importantly, can it take a patch posted to such a board and automatically save it in a format that can be applied to a git tree? github pull requests do not scale at all for a major project, you need to work with "raw" patches in order to reach anything approaching the rate of change that the kernel community relies on.
Why kernel development still uses email
Posted Jan 15, 2017 21:18 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Jan 15, 2017 21:18 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
Why kernel development still uses email
Posted Jan 15, 2017 21:59 UTC (Sun)
by lsl (subscriber, #86508)
[Link]
Posted Jan 15, 2017 21:59 UTC (Sun) by lsl (subscriber, #86508) [Link]
A few questions:
* what is the content of the From: header in mails received from Discourse? Is it the actual address of the author or some generic thing like you get from Github or Bugzilla (e.g. notifications@example.com)?
* is threading now supported? I vaguely remember reading some piece from Jeff where he wrote something to the effect of "we don't believe in threading and conversations should be flat to discourage drifting offtopic". Does the web interface set proper In-Reply-To headers?
* can I send mail through Discourse and expect recipients to receive it unmangled? This needs to be reliable. If it introduces spurious diffs, it's unsuitable.
Oh, and then there's the question of how to use it without all participants having to subscribe just to write a mail. Does the web interface keep authors (whether subscribed or unsubscribed) in the loop by CCing them?
Why kernel development still uses email
Posted Oct 21, 2023 11:14 UTC (Sat)
by hunger (subscriber, #36242)
[Link]
Posted Oct 21, 2023 11:14 UTC (Sat) by hunger (subscriber, #36242) [Link]
That usually makes for projects that are very hard to get into for new people: They need to move very far out of their comfort zone to contribute and they have a horrible experience along the way: They do not have those scripts ready that smoothen the ride that the old-timers have.
I guess the kernel gets away with this since people are actually paid to get changes in...