login
Search
BitKeeper creator Larry McVoy [interview] recently commented on the sheer quantity of work going on in the Linux kernel. He summarizes:
"What that means is that in about a year, you've managed to create 65,337 changesets. That's 179 per day, 7.4/hour, 24x7. You guys are busy. To put that in perspective, the most active project on sourceforge today, Gaim, has 805 commits to its changelog. Over 3.5 years. That means you are changing your source base 284x more often than they are. And that's just the BK users, that doesn't count the people not using BK, which are a substantial fraction."
Larry posted similar statistics a little over a year ago [story] which also showed a tremendous rate of activity. Read on for the full email.
From: Larry McVoy [email blocked] To: linux-kernel [email blocked] Subject: Silly BK statistics Date: Mon, 13 Oct 2003 19:55:51 -0700 You guys work way too hard. The BK openlogging tree, which has all changesets ever made by anyone in the Linux kernel, was getting big. Really big. The nodes in the graph have internal "serial numbers" which are currently 16 bits, i.e., there can't be more than 64K nodes in the graph. I sent mail to some of my engineers this morning saying "hey, I suspect the Linux openlogging tree is about overflow, we need to go to 32 bit ser_t's." I had no idea how close we were, I just knew it was a problem we needed to solve. I just got mail from one of the team which reads: "With 199 serials shy of overflowing , the 32 bit version is now installed". What that means is that in about a year, you've managed to create 65,337 changesets. That's 179 per day, 7.4/hour, 24x7. You guys are busy. To put that in perspective, the most active project on sourceforge today, Gaim, has 805 commits to its changelog. Over 3.5 years. That means you are changing your source base 284x more often than they are. And that's just the BK users, that doesn't count the people not using BK, which are a substantial fraction. No matter how you slice it, it is pretty amazing rate of change. If change is good, you guys rock, I've never seen anything like it. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Measuring commits to the chan
Measuring commits to the changelog may not do Gaim justice. The sourceforge project page at http://sf.net/projects/gaim says, for example:
" CVS Repository ( 13,529 commits, 3,435 adds )"
--
schnee
Directly comparable?
I'm not sure that is directly comparable. CVS commits and adds are per-file. BK changesets (I believe) are cross-file.
-molo
Yes, it is not directly compa
Yes, it is not directly comparable. But then, changelog commits and kitbeeper changesets aren't, either; and, for that matter, Gaim is not even the most active project on sourceforge, anyway, if you measure by CVS commits etc. (for example, the "compiere" project has: "CVS Repository ( 28,022 commits, 4,476 adds )").
FWIW, IIRC, the "most active" list on Sourceforge is based on pageviews and downloads rather than project CVS activity, anyway.
--
schnee
Impressive
It's impressive they can do that while still keeping things in relatively working condition.
It would be very interesting
It would be very interesting to compare theses numbers with some big open source project, such as Mozilla. Gaim has much less source code, and is much less used than the Linux kernel, so it's not the same category.
KDE numbers
Each week there are an average of 2000 commits. That is multifile atomic commits, not counting each file change.
Again, not changesets. I believe that changesets are usually a bit larger. Size of each commit ranges from one liner bug fixes to major feature implementations. The total also includes i18n translations. And all the applications that are in the KDE repository, ie. Koffice, etc.
Still, an impressive amount of work.
Derek
KDE-CVS-Digest
graph
Btw. I graphed this with rrdtool the other day:
http://people.0x63.nu/~andersg/lk-csets.png
linux on CIA
The CIA bot gets real-time commit notification from both linux and gaim, so you can compare them on its stats page.