LWN: Comments on "Where 2.6.25 came from"

Comments and questions about graph

pr1268 — Mon, 07 Apr 2008 21:23:47 +0000

First of all, many thanks to Linus (for git and its repository enabling the compilation of these statistics), Greg KH, Amanda, and our editor (for the article and gitdm), René Descartes (for the coordinate system bearing his name on which a function like ΔLOC/Δt can be plotted), and to Sir Isaac Newton and Gottfried Leibniz for discovering (inventing?) differential calculus, all of which allows me to comment on, and ask about, our editor's informative graph:

Overall, the entire plot is relatively constant slope (with a barely-perceivable increase in more recent times)--this means that the rate of kernel development appears to be in a state of steady development, with a hint of increased patch submission rate in the newer releases.

However, there's one thing I notice mildly unusual: the steep vertical rises of new code submissions in the patch windows of 2.6.23 and .24 are taller than previous ones, with their matching stabilization periods correspondingly longer.

Yet, with the overall slope nearly constant, this would seem to imply that the stabilization period (shallow slope) is proportional to the number of patches submitted at the release window (steep slope).

Are the stabilization periods becoming longer because of the additional time to test all the new code? Or, is more code being submitted at the release window due to the longer time between releases? Thanks again!

P.S. I calculate ΔLOC/Δt ≅ (5.5M - .5M) LOC / 2 yr ≅ 1 new LOC every 12.6144 seconds.

Where 2.6.25 came from

bunk — Sun, 06 Apr 2008 10:59:00 +0000

I just notice I forgot to add a smiley after the "Don't believe any statistics you haven't
faked yourself."

I don't claim this graph was faked (I haven't checked, but it's most likely correct).

But it's important to realize that the scale of the graph means that for example the step you
see one month before the release of 2.6.23 can easily equal 100.000 lines of code (the
re-addition of the sk98lin driver alone were over 40.000 lines of code).

Stabilization, also known as bugfixing, tends to consist of small patches (usually < 100 lines
changed, often even < 10 lines changed).

And these patches are simply too small for having any visible effect on a "count of lines
changed" graph for the Linux kernel.

Check e.g. http://lwn.net/Articles/274992/ for an explanation by Linus himself regarding what
causes most of the line changes later in the release cycle.

Where 2.6.25 came from

bunk — Sun, 06 Apr 2008 10:28:28 +0000

You said:
From my readings of the graph
the last 2 kernels have very steep merge. 2.6.19 started merging late
2.6.22 has had more late merges than its successors
2.6.20 seems to have stabilized early

Don't believe any statistics you haven't faked yourself.

There is no strong relation between the number of changes and the number of lines changed.

And none of them has any strong relation to when a kernel stabilizes.

An increase in the "count of lines changed over time" graph can e.g. be one or more of the
following:
* many bugfixes
* defconfig updates
* addition or removal of drivers

It's a nice graph, but when you ignore the fact that it contains zero information *why* lines
changed all conclusions you draw are invalid.

Where 2.6.25 came from

lacostej — Sat, 05 Apr 2008 05:27:01 +0000

"2.6.16 is mostly off the graph. Are you off by one?"

yep. I think I got the others right.

Where 2.6.25 came from

roelofs — Fri, 04 Apr 2008 20:41:36 +0000

2.6.16 seems to have had a bad stabilization

2.6.16 is mostly off the graph. Are you off by one?

Greg

Where 2.6.25 came from

lacostej — Thu, 03 Apr 2008 12:34:20 +0000

What would be interesting is to compare information found in the first graph, e.g.
* size of the 'stair-step'
* comparison of the stair size with the release period length
* stabilization (e.g. inclination angle of the slope after the stair)
* average amount of reviews per change
* ...
with external information (perceived or computed stability, number of security issues
introduced in a release, holidays)

From my readings of the graph
the last 2 kernels have very steep merge. 2.6.19 started merging late
2.6.22 has had more late merges than its successors
2.6.20 seems to have stabilized early
2.6.16 seems to have had a bad stabilization