整理した方がいい？

Kconfigのデフォルト（コンパイル時のデフォルト）: no
boot parameterのデフォルト: yes

なので、今から使う方々にとっては自分でコンパイルしてるはずなので、デフォルト無効、
しばらくたってディストリに標準搭載されるとデフォルト有効。

・VFS のスケーラビリティ向上
・RCU (Read/Copy/Update) ベースのパス名検索

この２つを離れた行におくのはいかがなものか。RCU walkはVFS scalability patchの本丸なので。

・4KB 超ページへの透過アクセス

はちょっとひどい訳だと思う。hugetlbfs非対応の普通のアプリケーションに対してカーネルが内部で透過的に
ヒュージページに変換して性能を上げようという機能ですよ。

最終的にデフォルトOFFになったはずだから気にしなくていい気がしますが、どうでしょうか

なんか話が続いているようだったのでTogetterを更新しました。
誰でも更新可に設定してあるので、面白いエピソードがあれば追記してやってください。

beroさんが正しいと思います。kernelnewbiesの中の人も人間なのでたまには間違います
（カーネルの変更を全ウォッチなんてやっとれんわ！）
逆に考えましょう。たまには、こういうのがあると丸写しライターがあぶり出されていいじゃないかと

富士通は機種依存部分は手薄で、ほとんどがコアコードへの貢献。これは結構特色だと思う。
SPARCはDavid Millerの趣味プロジェクトで、FR-Vもredhatがメンテしていて富士通からの
submitは（少なくともLKMLでは）見ない。裏でやりとりしまくってる可能性はあるが。

GoogleはほとんどAndrew Morton一人のカウントでそれ以外の貢献はほぼ０．Sunもたしか一人だけ趣味パッチを投げまくっている人がいるだけで企業としては貢献０．
SparcコードはDavid Miller(ネットワークのメンテナ)がネットワークのコード見るの飽きた時だけ更新されるイメージ

と、報告書には書いてあるけど、しょせんメールアドレスで集計しているだけなので、いくつも例外があるのであった。
ぶっちゃけ、土日だけ違うメアドになるのって、お互いにやりにくいので会社アドレスで趣味パッチも対応するか、
常に会社アドレスを使わないかの二択になりがち。
んで、あの集計は、フリーメール系に関しては、その時の在籍企業を別ルート（主に自己申告）で集計して、パッチ内容を考えずに
その企業に全部足してしまっているので実情としては業務かどうかはまったく分からない値である。

まあ、普通の人は平日の方が休日よりも多いはずなので、業務パッチの方が多くなり誤差は大きくないはずなんですが、
これも例外がいっぱいあって・・・・

ドライバもアーキ依存も全部含まれてます。ぶっちゃけIBMやParallels など普段LKMLでみない企業がいくつも入っているのは
へんてこアーキを持っているところが大きい。