Linuxカーネルのリリースペースは早すぎる？ 48
ストーリー by hylom
迅速な修正はよいことだが 部門より
迅速な修正はよいことだが 部門より
あるAnonymous Coward 曰く、
6月30日にリリースされたLinuxカーネル 3.10に対するセキュリティアップデートが、一日に2回もリリースされる事態が発生した（eWeek）。Linuxカーネル3.10は「long-term supported」として長期にわたってサポートが行われる予定の安定版カーネルであるが、短期間で修正リリースが続いたことについて、否定的な声も上がっているという（本家/.）。
問題の原因は、報告されていたパッチをRelease Previewバージョンでのレビュー中に誤って壊してしまったためだという。そのため修正自体は迅速に行われたのだが、これを受けてLinux Kernel Mailing Listでは安定版カーネルのリリース速度についての議論が起きているとのことだ。
リリースのスピードが問題なのではなく (スコア:5, すばらしい洞察)
リリースをしたものの中に壊れたものが混入したことが原因だと思うので
リリースのペースも大事かもしれないけど、チェック体制的なものをどうこうしたほうがいいんじゃなのか？
リリースのペースを緩めようがどうしようが混入する可能性が否めない以上はリリースペースの問題じゃないように見えるが・・・
Re: (スコア:0)
作業要員はそう簡単に増やせないから、リリース当たりの作業時間を延ばして
チェック体制の強化を考えてるんだろ。
それで作業時間を長くとれるようにリリース間隔を広げようという話でしょう。
この程度は相手の話を聞いて説明されなくても汲み取るべき。
Re:リリースのスピードが問題なのではなく (スコア:1)
一般論を記述します。
自動でチェックする、あるいは、壊れないような仕組みを作れば宜しい。
# 最近の人はQC活動とかしてないの？
Re: (スコア:0)
これもその後続く一般論ですが。
では将軍様、
自動でチェックしますのでチェックツールください。
壊れないような仕組みを作ってください。
Re: (スコア:0)
仕組みを作る努力もせずに、リリース間隔を延ばせばいいって判断することが安直で頭悪いという話では？
Re: (スコア:0)
うーん、一般論としての「自動でチェックすればよい」は、
猫に鈴つければいいじゃん、と同じに聞こえる、つまり、なにも解決に
つながらない一般論であって、「うまくやればいいじゃん」と言っているのと
同じ、という指摘なのでは？
Re: (スコア:0)
> うーん、一般論としての「自動でチェックすればよい」は、
> 猫に鈴つければいいじゃん、と同じに聞こえる
そんなことを言ってるのはあんただけでは？、
Re: (スコア:0)
私は別人だけど、私もそんな感じに聞こえる。
さらに加えるなら「鈴つける努力しろ」とも。
まあ、一般論で語ることが既に間違いなんだとは思うけどね。
というか自動チェックって具体的にどんなの考えてるの？
テスト駆動とかそういうのしか思い浮かばないけど、それだと、じゃ、誰がテスト書くの？書いてくれるの？っていう。
そんな努力するなら、そう、努力するならチェック期間伸ばせばいいじゃん。
っていうか、やりたきゃ君がすればいいじゃん、っていう言い出しっぺの法則が出てくるんだけどね。
Re: (スコア:0)
って知らない？
Re: (スコア:0)
それこそ意味なくない？
だって間隔広げたら解決するわけじゃないんだしさ。
広げたことによる弊害とか出てくるわけだし。
間隔広げてチェックの時間に余裕を持たせるってのはこの場合の解決策とは違う気がする。
Re: (スコア:0)
なんで？作業増やすのになんでそのための時間を取ろうとしない？マゾ？
ていうかどんな場合を想定してどんな解決策を想定してるの？
1日で発見解決出来るようなものだよ？その時間あれば解決出来たわけだよ？あとは目の数を考慮するだけだよね？
そんなわけで、
変なパッチいれちゃった→チェック期間が必要だね（リリース間隔伸びるけど）→RCだそうRC2までにしよう3ヵ月は勘弁（何の話？）いやsnapshotで……
という話みたいですが。
Re: (スコア:0)
じゃあ1日延ばせば解決だから議論する余地なくね？
Re: (スコア:0)
あとは目の数を考慮するだけだよね？
Re: (スコア:0)
日本だとこういうブラックジョークってなかなかわかりにくいよね。
Re: (スコア:0)
ここでいきなりアラスカの話をされてもわからんからな。
気をつけておくれよ。
Re: (スコア:0)
目の数を確保すれば、リリース間隔は今のままてもいいんじゃね？
Re: (スコア:0)
結局、目の数を増やすには「しょっちゅうリリース」するのが覿面なわけで、
リリース間隔を広げようってわけじゃなくて、
「これ外伝でナンバリングタイトルじゃないから全年齢対象でなくてもいいよね」
的なリリースを導入しようって話？
Re: (スコア:0)
また良く分からん喩えをw
まあRCがリリースならそーだね頭痛が痛くない的な？
つかkernel.orgの感覚とか分からんけれども間隔くらい分かるだろ？的コメント多数？
それともRCがリリースだJKむしろリリースがRCだJC的な？
Re: (スコア:0)
間隔広げたら解決に向かえるでしょ。
その時間をチェックに注ぎ込むこともできるんだしさ。
「この場合の解決策とは違う気がする」ってのは、具体的にどういうこと?
Re: (スコア:0)
投入するヒューマンパワーの質と量に依存するものは解決策ではないって考え方が根底にあるのでは。
もっと汎用性と網羅性を保障するテクニカルなロジックで解決しないと、同系別種の問題が再発します。
Re: (スコア:0)
実際にこれでは時間が足りなくて十分にチェックできないという声が上がっていたのならともかく、そうでないのなら「これからはチェック時間を増やします」という報告は再提出させるけどなぁ。
全面的に同意 (スコア:0)
リリース後、次のリリースまでは最低でも１ヶ月、
間隔を空けるべきだ！
#目的と手段を取り違えてるって意味だと思うよ
Re: (スコア:0)
そういう風に時間をかければ解決とかバカなこといってるから突っ込まれるんだろう。
Re: (スコア:0)
より多くの時間を費やすのは解決策ではない対応策だよ。対応策であるからあらゆる問題に対応してマイナスにはならない万能手法でもある。なんでその程度も読み違えるのかと。
時間を費やさないことで余計に発生しうる問題を費やすことで事前に回避する効果も期待するわけだよ。
そして解決策が即時適用可能ならよいが、おそらく人材を探したりツールを開発したり、解決策で新たに別の問題が発生しないかどうかの検証など時間がかかると予想される。となれば即時に適用できる万能手法たる時間をかけようという話が出てくるのは自然な流れであろう。
Re: (スコア:0)
対応策だけで解決策をたてないからバカだといわれてるのでは？
それとも間隔を延ばすって対応策だけでなく、具合的な解決策が記事にかかれてる？
あんたの妄想でないの？
Re: (スコア:0)
「リリース後12時間はチェック期間」とかにすれば人柱が勝手にチェックしてくれるんじゃね？
安定版を欲する人はその後にダウンロードしてね♪ って。
なんたらの法則 (スコア:0)
入念にテストした筈なのに、
リリース依頼出した直後、
バグを見つけてしまう。
#ありすぎて困る
Re: (スコア:0)
そこからさらに+12時間すればいい。
＃終わらねえ…
技術者じゃ無いから、ディストリにまかせるよ (スコア:3)
普通の人がLinuxを使うなら、そこの早すぎは、ほとんど問題になりませんよね?
素人にとってのLinuxと、技術者にとってのLinuxには大きな隔たりがあって
素人にはその隔たりがわからないことがあることを、ちょっと面倒に思っています。
(Windowsもまた、同じような隔たりがあることは、けっこう認知されているようなのに)
最新のカーネルソースをダウンロードしてきて導入するって
開発目的以外でやる人はどのくらいいるんでしょう?
私は、CはHello Worldを出すコードもうろ覚えというレベルなので
よほどのことが無いかぎりソースコードを扱うことがありません。
Ubuntu系を使い、最新版を追いかけず、LTS版を使うようにしています。
ですから、このKDE環境のPCでも3.2系のものを使っています。
19ヶ月も前の"古いカーネル"…なのでしょうか?
より新しいカーネルを求めるのであれば、UbuntuのLTSには
ポイントリリースやバックポートカーネルといった制度があって
linux-image-hwe-genericパッケージを追加していれば
12.04.3ポイントリリースで、3.8系カーネルも使えるようになっているようです。
が、このPCのカーネルは、依然linux-image-3.2.0-52-genericパッケージです。
「ディストリビューションの用意したカーネルで充分じゃないか」と思っています。
Re: (スコア:0)
私は、ただの Linux ユーザーで、仕事の道具としてしか使ってませんが、
10年くらい前は、普通にそれやってました。ほとんど趣味でしたが。
（だいたい 20年程度の Unix 歴です)
少し古い人はたぶん趣味でみんなやっている。
・・・ただ、今はもうそういうことしてないですけどね。
そういう熱意はないし。
他にもやることが多いし、
趣味で Linux つかってないので。
なによりも学生でなくなってからずいぶんと立っていることも大きい。
ディストリビューションの用意したカーネルで十分ってのは道具として健全だと思います。
同意です。
コンピューター(Unix)が趣味としても多様性が増えたと言うことで、それでどうと思うこともない。
Re: (スコア:0)
昔はACパッチ目当てにRedHat使ってたな。
もちろんアランコックスのパッチな。
同じACでもAnonymousCowardのパッチは嫌すぎる。
信頼性を重視するならもっと枯れたものを使ったほうがいいだろうから更新の遅くサポートの長いディストリを使うべきじゃないかな。
こういうものは新機能が関係ないならセキュリティ対応があるなら古ければ古いほどいいと思うけど。
あ…ありのまま 一昨日 起こった事を話すぜ！ (スコア:1)
『朝起きたら3.10.8がリリースされていたので、落としてきてmakeした
と思ったら昼過ぎには3.10.9がリリースされていた』
な… 何を言ってるのか わからねーと思うが
おれも何をされたのかわからなかった…
頭がどうにかなりそうだった…
寝惚けてたとかリリースペースが早いとか
そんなチャチなもんじゃあ 断じてねえ
もっと恐ろしいものの片鱗を味わったぜ…
Re:あ…ありのまま 一昨日 起こった事を話すぜ！ (スコア:2)
私の場合は個人PCなので、ChangeLog読んで自分の構成にて影響のないアップデートにはのんびり対応する。
のんびりしてすっかり忘れることがあるので、ログイン時にkernel.orgのstableのバージョンとシステムのバージョンを比較して古いバージョンになっていたら警告するようにした。
とはいえ、アップデートした翌日のログインで警告が出るとさすがにげんなりいたしますな。
Re:あ…ありのまま 一昨日 起こった事を話すぜ！ (スコア:2)
Re: (スコア:0)
「リリースペースが早い」なんてチャチなことですよね
Re: (スコア:0)
今まで動いていたカーネル消しちゃったの。
色々誤解のあるタレコミの気がする (スコア:1)
と言っても私はkernel.orgどころかlinuxにもほぼ触らない外の人だが、ちょっと追ってみたのでまとめる。
正しいかは知らない。
発生事象：
担当メンテナGreg KHが、安定版に当てるべきではない開発版だけのパッチを当てて安定版をリリースしてしまった。
背景となる現在の安定版リリースサイクル：
数多くのパッチのうち、開発版に取り入れるパッチがlinusツリーに導入される。
その後、またはlinusツリーと同時にstableツリーのheadにも導入される。
その後（数日～十日？）、安定版に取り入れるパッチが選ばれstableツリーの各安定版ブランチにバックポートされる。
＃今回ココで選択ミス？
その後（1～2日？）、各ブランチにタグが打たれてリリースされる
問題提起：
安定版ブランチにバックポートされてからリリースまでが速すぎるんじゃないか？緊急や定形のパッチを除き、安定版もパッチを当てたあとで一旦RCを出して待とう（Greg KH）
いや、RCを出すか出さないかが重要なんじゃない、バックポートされてからリリースの間に待つことが重要なんだ。
カーネルUPdateは迅速で良い (スコア:1)
今北産業 (スコア:0)
どなたかその議論の内容を3行でまとめていただけませんか?
Re: (スコア:0)
無
理
だ
Re: (スコア:0)
グ
グ
れ
Re: (スコア:0)
パソコンで表示して一行でも、スマホでは数行になることあり。一行の定義を求む。
Re: (スコア:0)
CR（復帰、0x0D）またはLF（改行、0x0A）およびその組み合わせまでが一（論理）行です
Re: (スコア:0)
つまり、３段落ですな？
HP100LXというものがあった (スコア:0)
たとえ、CGAやEGAの端末があったとしても、SuperVGAの端末があっても
我々の手に30行計画が与えられたとしても…
パソコン通信時代の一画面の基準は80x25文字でした。
長文の目安も、この画面の広さでアプリケーションの表示部を考慮し
22,3行を越え、スクロールを要するものが長文という考え方がありました。
一行の基準はASCII文字80文字(日本語40文字)でいいでしょ?
引用符を付加したときのことを想定して
75文字程度で改行するのがマナーとも言われていましたね。
/.J の記事も… (スコア:0)
Linux カーネルも然ることながら、最近の /.J の記事の追加ペースも早すぎでふ。
Re: (スコア:0)
おかしいなぁ。
reoが死んだ分、ペースが落ちてるはずなんだけどなぁ。
ミスをなくすためのコードレビューでミスが発生したら打つ手はない (スコア:0)
こないだのサッカー日本代表戦の吉田選手のヒールパスと一緒だよ。カバーリングが不可能なミスというものは存在する。