linux-kernel - Re: Linux 2.6.32-rc3

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 6 Oct 2009 13:44:50 -0400
From:	Theodore Tso <tytso@....edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Dirk Hohndel <hohndel@...radead.org>,
	Len Brown <lenb@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Linux 2.6.32-rc3

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/