Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Monday October 03 2016, @07:58AM   Printer-friendly
from the because-it-works dept.

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

[More ...]

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.

[...]

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Monday October 03 2016, @05:08PM

    by Anonymous Coward on Monday October 03 2016, @05:08PM (#409517)

    That comment seems completely self-contradictory. You don't use git because of the license, but use Github despite the license and the fact it uses git.

  • (Score: 2) by TheRaven on Tuesday October 04 2016, @08:11AM

    by TheRaven (270) on Tuesday October 04 2016, @08:11AM (#409862) Journal
    We don't create infrastructure where developers are required to use git, but we create infrastructure where developers are able to use git (and GitHub). Freedom is something that BSD communities tend to be quite keen on. We won't force GPL'd code on you, but if you're happy to accept it then you're very welcome to use it in your own workflow and we'll try hard to accommodate that.
    --
    sudo mod me up
    • (Score: 0) by Anonymous Coward on Tuesday October 04 2016, @04:05PM

      by Anonymous Coward on Tuesday October 04 2016, @04:05PM (#410052)

      I get the stuff hosted yourself, but you said "We use GitHub as the authoritative repo for a number of sub projects (e.g. the packaging system)." So if people want to contribute to that area, then they are forced to use Github (and git for real power over commits). Perhaps I am missing something still, but the svnweb doesn't seem to mirror all of the Github stuff. It definitely isn't fully bidirectional from what I've seen, as well.

      • (Score: 2) by TheRaven on Wednesday October 05 2016, @07:57AM

        by TheRaven (270) on Wednesday October 05 2016, @07:57AM (#410528) Journal
        Note that using GitHub doesn't force people to use git. You can do an svn checkout of any GitHub repo. It does force you to use GitHub (which has non-free JavaScript, which caused me to receive a lot of rants when I moved the GNU project that I maintain to GitHub). It's largely an experiment at this stage. We'll see how it goes over time.
        --
        sudo mod me up