Re: Linux 2.6.32-rc3

Theodore Tso
2009-10-06T17:45:50Z

On Tue, Oct 06, 2009 at 08:42:18AM -0700, Linus Torvalds wrote:
> Now, that's not actually true, because (a) people rebase and (b) even in
> the absense of rebases I do merge with people like Andrew by email, so we
> actually end up having statistics like these:
>
> 32 SUBLEVEL = 29
> 383 SUBLEVEL = 30
> 8795 SUBLEVEL = 31
> 1 SUBLEVEL = 32
>
> which is actually a bit sad in itself (showing just _how_ many people
> rebased their work on top of a release), but is still showing that we
> actually had 32 new commits in there that were based on a 2.6.29 kernel

It's actually not quite so bad. If you take into account
Extraversion, the stats that you get look like this[1]:

4 29-rc2
28 29-rc8
331 30
4 30-rc2
48 30-rc5
3867 31
561 31-rc1
895 31-rc2
190 31-rc3
278 31-rc4
1245 31-rc5
521 31-rc6
515 31-rc7
387 31-rc8
336 31-rc9
1 32-rc2

That actually shows that well over half of the commit based off of
2.6.31 were actually based off of some 2.6.31-rc release, based on
something *before* 2.6.31 released.

Of the 3867 that were based on something between 2.6.31 and
2.6.31-rc1, that may be explained by people (like me) who will do a
test merge, and if the test merge has conflicts, prefer to resolve the
conflicts via a rebase and a re-run of the regression test suite, as
opposed to either (a) having the upstream maintainer (you) do handle
the merge, or (b) having two merges in the history; one merge by the
maintainer to resolve the merge conflict, and another by the upstream
maintainer when they pull in the topic branch.

Some (probably small percentage of the commits based on something
between 2.6.31 and 2.6.31-rc1 can probably be explained by on bug
fixes after an initial merge, but granted that's probably a pretty
small set.

- Ted

\[1] Generated using:

git rev-list v2.6.31..v2.6.32-rc1 |
while read a
do
git show $a:Makefile | head -4 > /tmp/foo
awk '/^SUBLEVEL/ {printf("%s", $3)}; /^EXTRAVERSION/ {print $3}' < /tmp/foo
done | sort | uniq -c