LWN: Comments on "A look at the 3.12 development cycle"

No Time Zones

ldo — Sun, 03 Nov 2013 06:16:47 +0000

I personally think time zones have no place in the commit history. I don’t know why Git includes them. I’ve been using this patch in my Git builds for a while now:

--- date.c-orig 2008-05-28 19:56:46.000000000 +1200
+++ date.c 2008-05-31 00:48:17.000000000 +1200
@@ -611,8 +611,12 @@

time(&now);

+#if 0
offset = tm_to_time_t(localtime(&now)) - now;
offset /= 60;
+#else
+ offset = 0;
+#endif

date_string(now, offset, buf, bufsize);
}

A look at the 3.12 development cycle - time zones

gnu_andrew — Thu, 31 Oct 2013 03:04:57 +0000

Except those in the southern hemisphere, which are just now entering summer time; Sydney just moved from +10 to +11 at the beginning of October and Rio moved to -2 a week and a half ago.

http://www.timeanddate.com/time/dst/2013.html

A look at the 3.12 development cycle

nix — Wed, 30 Oct 2013 00:00:36 +0000

Hm. OK, my oneliner was buggy. Thank you for re-emphasising my point!

A look at the 3.12 development cycle

BenHutchings — Tue, 29 Oct 2013 22:00:14 +0000

Most of the wireless drivers in staging include their own snapshot of the 802.11 stack (at least initially).

A look at the 3.12 development cycle

eternaleye — Tue, 29 Oct 2013 21:50:47 +0000

Well, one thing that would interest me is checking _negative_ metrics - how many patches were reverted? What's the distribution of CVEs among git blame? The main problem I see there is that while these are 'negative' metrics in the sense of 'there was a problem' they'd likely get interpreted in the sense of 'this person is a problem'.

The _benefit_ is that they might indicate places where more documentation, more review, or other such things are needed. If, for instance, (random subsystem, not actually based on anything) networking code sees a higher rate of reversions or CVEs per commit or changed line, that could be a damn good signal that there needs to be some examination of why it happens. It could be that networking code is just plain more exposed as an attack surface, but it could also be something resolvable.

From another angle, debiting reversions against the reverted patch author's commits and lines of code could be interesting as a reverted commit is a no-op in terms of useful change, even though (as Linus has had to point out at times) it's certainly not a no-op in terms of code.

Another interesting thought is the number of first-time contributors per kernel, or new email domains (likely correlated to new companies becoming involved in development) - those would be well worth bringing up, and acknowledging them could have beneficial effects by rewarding participation (and providing a signal to people like me of companies that might be worth looking into/supporting/checking out the products of).

African developers

robbe — Mon, 28 Oct 2013 08:01:54 +0000

Assuming you didn't mean binary orders of magnitude, that is less than six developers. That's really some room for improvement!

... Asia ... Women ... Africa ........ World Domination
              ↑
              └─ we are here

A look at the 3.12 development cycle - time zones

giraffedata — Fri, 25 Oct 2013 16:29:21 +0000

I believe essentially all places that use summer time at all were using it throughout the release cycle.

Also, there aren't enough contributors in places that don't use summer time to make a noticeable difference in the histogram.

A look at the 3.12 development cycle

brother_rat — Fri, 25 Oct 2013 07:49:15 +0000

There is only one country that lives in +5:30 — India.

and Sri Lanka.

A look at the 3.12 development cycle

jani — Thu, 24 Oct 2013 21:27:23 +0000

> Why not look for the best bug fix and reward the really hard work.

In this respect, it would be interesting to see similar statistics for commits backported to stable kernels.

A look at the 3.12 development cycle

r.g.b. — Thu, 24 Oct 2013 14:18:50 +0000

Newfoundland(Saint John's) is UTC -3:30(-2:30 daylight savings), so nix that from the graph. Atlantic Canada and Labrador are UTC-3:00 at the moment in Daylight savings, so that graph could conceivably include New Brunswick (Frederickton, Moncton, Saint John), Nova Scotia(Halifax) and PEI(Charlottetown). There isn't much in Labrador(largest town of 8,000).

Having said that, Brazil does seem more likely.

A look at the 3.12 development cycle

josh — Thu, 24 Oct 2013 12:32:09 +0000

"improve", not "perfect".

A look at the 3.12 development cycle

jnareb — Thu, 24 Oct 2013 11:07:57 +0000

> It should be possible to improve the time-zone-based estimates significantly by correlating date with time zone: the combination of the two along with the tzdata time zone database should mostly distinguish between adjacent time zones that might or might not have a DST off-by-one error.

This assumes that all countries in the same timezone have their DST switch times (some countries do not use DST, some switch at different dates though differences are small) and DST offset synchronized (compare northern and southern hemisphere DST).

A look at the 3.12 development cycle

corbet — Thu, 24 Oct 2013 08:58:11 +0000

Trust me, I know that these are poor metrics. I sure wish I could come up with a better one that would scale to a project with tens of thousands of commits every year...

A look at the 3.12 development cycle

josh — Thu, 24 Oct 2013 00:07:33 +0000

It should be possible to improve the time-zone-based estimates significantly by correlating date with time zone: the combination of the two along with the tzdata time zone database should mostly distinguish between adjacent time zones that might or might not have a DST off-by-one error.

A look at the 3.12 development cycle

pjtait — Wed, 23 Oct 2013 21:56:21 +0000

As confirmed by looking at the contributions from PST (UTC-8).

A look at the 3.12 development cycle

dashesy — Wed, 23 Oct 2013 21:45:11 +0000

If hiring management looks at LoC to hire, it is them to blame for demise of their company. IMO, just contributing to the kernel is enough for most positions, but more LoC also means revealing more about the talent, just more material to look in the eyes of the wise :)

Still useful

david.a.wheeler — Wed, 23 Oct 2013 21:04:16 +0000

I suspect that a lot of code written to take "as many lines as possible" would be rejected, especially since there's an established format. So while lines of code are only a rough estimate of effort, lines of code are still strongly correlated with effort.

You could try using a SLOC-counting tool that strips out comments and blank lines.

A look at the 3.12 development cycle

HelloWorld — Wed, 23 Oct 2013 20:53:34 +0000

I can't help but agree. Well-written code tends to be much shorter than badly-written one, so the LoC numbers mean nothing. And what's even worse is that they might lead people (e. g. hiring managers) to the wrong conclusions about who is productive and who isn't. I think they're therefore worse than useless. Sorry Jon :-(

A look at the 3.12 development cycle

dougg — Wed, 23 Oct 2013 20:32:03 +0000

This stuff is just for code accountants. According to git blame on sg.c the LWN editor was responsible for a single right brace in 2008?? [I guess some else changed the rest of his patch.]

Why not look for the best bug fix and reward the really hard work.

A look at the 3.12 development cycle

Tara_Li — Wed, 23 Oct 2013 20:11:34 +0000

With regards to the Devs with most changesets, and Devs with most lines - is there perhaps an option to look at how lines per changeset might affect that, as a Dev might have one particularly large changeset with a lot of lines that would bump her up one list, and not the other...

It might be interesting to look at the differences in what small changesets do, and what large ones do, other than, of course, in drivers. I expect most of the large ones get covered, with descriptions of what ABI is getting munged, or what subsystem is getting ripped out and replaced, but I expect the janitors show up in the small changesets.

A look at the 3.12 development cycle

mslusarz — Wed, 23 Oct 2013 19:50:45 +0000

In case of nouveau you didn't count subdirectories. For Linux 3.11:

$ find drivers/gpu/drm/nouveau/ -name "*.[ch]" -exec cat {} \;|wc -l
96886

A look at the 3.12 development cycle

Lumag — Wed, 23 Oct 2013 18:26:52 +0000

+4 is European part of Russia (and also Saudi/Iraq/Syria + some Africa countries).

A look at the 3.12 development cycle

nix — Wed, 23 Oct 2013 18:15:11 +0000

If you ignore networking drivers, one of the graphics drivers would win by a mile:

radeon: 181934
i915: 69779
gma500: 32005
nouveau: 23347

(the ugly oneliner I'm using for this is just looking at all files under particular directories, so I can't look at network drivers so accurately -- but even wireless drivers seem to come in at the same sort of size as nouveau, and *much* smaller than radeon.)

A look at the 3.12 development cycle

dashesy — Wed, 23 Oct 2013 17:37:17 +0000

92908 lines of code for a driver is interesting, considering that presumably there is already a networking subsystem. I wonder which driver is the largest one in size.

African developers

corbet — Wed, 23 Oct 2013 15:07:22 +0000

Very few, alas. I feel confident in saying that the number is at least two orders of magnitude less than Europe's, so they are pretty much in the noise for the purposes of this (already noisy) exercise.

A look at the 3.12 development cycle

niner — Wed, 23 Oct 2013 14:49:36 +0000

Africa uses the same time zones as Europe. Are there no African kernel hackers?

A look at the 3.12 development cycle

rvfh — Wed, 23 Oct 2013 12:23:14 +0000

Summer time adds one.

A look at the 3.12 development cycle

tdalman — Wed, 23 Oct 2013 12:12:40 +0000

> Going west from there, +2 to +4 will be dominated by continental Europe, with the central European time zone accounting for 23% of the changes in 3.12. The UK and Ireland, at +1, put in another 10%

AFAIK UK and Ireland are at GMT+0, while western Europe is at +1. That said, the contribution from UK and Ireland is at about 2%, right ?

A look at the 3.12 development cycle

bokr — Wed, 23 Oct 2013 11:45:47 +0000

Your editor's time zone (-6), alas, was the source of only 1% of the changes going into this release; it must be time to pull together some white-space patches to improve that situation.

That makes me wonder how the statistics would look for changes just to the residue after stripping all comments and canonicalizing white space.