SoylentNews is people
SoylentNews
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.
(Score: 3, Informative) by TheRaven on Monday October 03 2016, @04:28PM
We're all old devs and we all know why the BSDs stick to their broken centralized CVS development model
I'm not sure what this is supposed to mean. From the FreeBSD perspective:
sudo mod me up
(Score: 0) by Anonymous Coward on Monday October 03 2016, @05:08PM
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
sudo mod me up
(Score: 0) by Anonymous Coward on Tuesday October 04 2016, @04:05PM
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
sudo mod me up
(Score: 2) by RamiK on Tuesday October 04 2016, @04:14AM
I'm not sure what this is supposed to mean.
It's easy championing the cathedral vs. bazaar when you're the priesthood.
We don't use git because of the license
Then what's preventing FreeBSD from picking up DCVS or even rolling your own?
none of the other distributed revision control systems has anything like the mindshare. A lot of our downstream users don't want...
See previous comment.
We host the project ourselves on our own infrastructure
Meaning, what? You can't run a decentralized SCM on your own hardware?
We have no objection to GitHub and a lot of downstream users
I can understand a person wanting to send a patch or two via email if they just want to get something fixed and otherwise aren't actively involved in development. But why prefer git over cvs if people are so happy with CVS?
We've had a couple of developers work...
Steps for flavor-of-the-month-SCM to git integration:
1. Learn git.
2. Realize git is better.
3. Get demoralized when you realize your team knows this but prefers keeping CVS\SVN\whatever to concentrate power.
4. Login to SoylentNews one day and and write a post explaining things on on an opportune moment.
5. Post a reply to TheRaven further detailing this.
I shit you not. I worked at integration coming from centralized SCMs and got converted myself. I've sat through the meetings and heard what people were arguing and it wasn't "mindshare".
We use GitHub as the authoritative repo for a number of sub projects
I'm not arguing specifically for GitHub. I'm arguing for decentralized SCMs and a bazaar development model.
You may not be familiar with this one coming from FreeBSD, but there's a running bitter-joke \ sad-truth in the OpenBSD circles regarding the NetBSD split being the result of CVS and how it wouldn't have happened if they were just using Git. The idea being that the projects wouldn't have drifted apart as badly as they did solely over a power struggle which would have given time for the dust to settle and people to note Theo was right.
Not to say git prevent every fork... After all, Android would have happened regardless seeing how the whole point was to focus on the embedded market that wasn't being represented in the Linux Foundation and was, and is, being ignored in design choices to this day.
But still, it's a valid point.
compiling...
(Score: 2) by TheRaven on Tuesday October 04 2016, @08:25AM
Then what's preventing FreeBSD from picking up DCVS or even rolling your own?
Rolling our own would take manpower away from other projects. That's not helpful. As to picking up another DVCS, git has most of the mindshare and svn has far better integration with git than any DCVS that we've seen. It's trivial for us to keep git mirrors in sync with svn. It's far harder to do the same with something like Fossil (which we also evaluated). Oh, and most DVCSs really scale badly to a repo the size (including history size) of FreeBSD. Git seems to just about handle it, but you'll notice that most projects of a similar size to FreeBSD use submodules, Google repo, or some other ad-hoc solution to split themselves between multiple repos to avoid these issues. Most of these lose atomic commits or make long-term branches (which we need to support backports for our 5 year support window for a major release) or other features that we use a lot.
Meaning, what? You can't run a decentralized SCM on your own hardware?
We can, and we do host a git repo, but there's far less benefit to that than to. We also mirror it to GitHub. So far, we've seen far more people care about the social aspects of GitHub than care about the underlying revision control system.
I can understand a person wanting to send a patch or two via email if they just want to get something fixed and otherwise aren't actively involved in development. But why prefer git over cvs if people are so happy with CVS?
Not sure what the relevance is for CVS. We moved to svn a long time ago. Most committers still use svn directly, an increasing number use git-svn. We give them the choice. External developers often fork on GitHub and then send pull requests. The GitHub model also makes it easy to do code review for external developers.
I shit you not. I worked at integration coming from centralized SCMs and got converted myself. I've sat through the meetings and heard what people were arguing and it wasn't "mindshare".
I find this whole section hard to parse, so I'm only quoting it in part. I've explained why FreeBSD uses svn as the authoritative repo, but that doesn't stop developers from using git. In contrast, switching the authoritative repo to git would prevent downstream users from using svn.
I'm not arguing specifically for GitHub. I'm arguing for decentralized SCMs and a bazaar development model.
We already have the latter. Take a look at the number of forks of the FreeBSD repo on GitHub. That doesn't tell the whole story, because GitHub doesn't allow you to do a private fork of a public repo and a lot of companies just clone the repo internally. They send patches back either via GitHub or via the mailing lists (more commonly via the lists because the GitHub integration isn't that great yet. Like I said, people are working on it).
And, honestly, if you're arguing for git and not GitHub then you're missing the point. I've taken projects through the transition from svn to GitHub and found a jump in the number of external contributors. I've never seen anything like this simply from a switch to a different revision control system or model. A couple of projects I've been very peripherally involved in moved to hg and fossil and saw contributions drop off. The advantages come from GitHub, not from git itself.
sudo mod me up
(Score: 2) by RamiK on Tuesday October 04 2016, @06:40PM
Mostly opinionated so I won't argue it directly. However:
The advantages come from GitHub, not from git itself.
can't be denied. But I still say it's the development model. GitHub simply enforces it by being a trusted third party and offering tools tailored with contributors' convenience in-mind like issues and pull-requests.
Extreme example: I was committing patches to a small client side tool a little while ago but upstream said the features weren't of interest. I thought that's strange since it seemed of pretty obvious benefit so I glanced over at the rejected PRs and active Forks and lo-and-behold, a dominant non-official and fork was actively taking patches from all over the place,
I submitted my PR there and after a short review process the bulk of it got accepted (around 300 loc) with the only comment regarding it's relevance was "Oh that's really handy, thx".
A few month later, the fork was announced. As it turned out, the original upstream was maintaining a for-paying-customers patch-set while keeping the official repository lacking all manner of necessary client-side features by rejecting patches. They couldn't close-source since they started off GPLv2 and already took-in a lot of contributions, so they kept a protocol compatible upstream while refusing to add features and only taking in bug fixes. Eventually, they even went as far as to remove features and that's when a bunch of contributors decided they had enough.
In most cases, the problems are nearly as nefarious. However, when I see GNU projects use Savannah exclusively; BSDs self-host CVS\SVNs with their own behind the scene review process; Or google projects host on github but then use gerrit... I look to see if there are alternatives before investing time into those tools.
I'm not saying every project avoiding third party hosting and reviews is necessarily doing something bad. I'm just saying lacking transparency usually doesn't end up well in the long run.
But hey, your mileage may vary.
compiling...