
Linus Torvalds氏、「GitHubが生成するマージは使い物にならない」と語る 47
ストーリー by nagazou
ダメ絶対 部門より
ダメ絶対 部門より
Linuxディストリビューション5.15では、Linus Torvalds氏がLinuxカーネルにParagon Software製のNTFS3カーネルドライバーを導入を認め、WindowsのNTFSファイルシステムをサポートするためのNTFS3カーネルドライバーが導入されることとなった。新たなドライバーは現在利用可能なNTFSドライバーと比較して機能およびパフォーマンスにおいて優れているとされる(Linus Torvalds氏のコメント、The Register、Phoronix、Market Research Telecast、ZDNet Japan)。
Torvalds氏は8月にNTFS3カーネルドライバーの統合許可を行い、Paragon Softwareに対し、「とにかくGitのpullリクエスト出してほしい」と伝えていたそうだ。対してParagon Softwareは3日にプルリクエストを送ったと回答していたものの、それはTorvalds氏の意向に反し、GitHubのウェブインターフェースから送信されたものだったとのこと。
Torvalds氏は、将来のプルリクエストを改善するため、Paragon SoftwareのKomarov氏にいくつかの注意を行っている。一つはGitHubのウェブインターフェースからLinuxカーネルにコードをマージするのは「絶対に」避けるべきだとするもの。
曰く、GitHubが生成するマージは全く使い物にならない。Linuxカーネルのマージは「適切に」行う必要があるが、マージに関連する情報を含む適切なコミットメッセージが必要だ。しかし、GitHubのマージはすべてを台無しにすると話している。ほかにも、GitHubのアカウントを使用する場合、プルリクエストにブランチだけでなく署名付きタグを付けてほしいなどに関しても指摘している(Linus Torvalds氏のコメントその2)。
Torvalds氏は8月にNTFS3カーネルドライバーの統合許可を行い、Paragon Softwareに対し、「とにかくGitのpullリクエスト出してほしい」と伝えていたそうだ。対してParagon Softwareは3日にプルリクエストを送ったと回答していたものの、それはTorvalds氏の意向に反し、GitHubのウェブインターフェースから送信されたものだったとのこと。
Torvalds氏は、将来のプルリクエストを改善するため、Paragon SoftwareのKomarov氏にいくつかの注意を行っている。一つはGitHubのウェブインターフェースからLinuxカーネルにコードをマージするのは「絶対に」避けるべきだとするもの。
曰く、GitHubが生成するマージは全く使い物にならない。Linuxカーネルのマージは「適切に」行う必要があるが、マージに関連する情報を含む適切なコミットメッセージが必要だ。しかし、GitHubのマージはすべてを台無しにすると話している。ほかにも、GitHubのアカウントを使用する場合、プルリクエストにブランチだけでなく署名付きタグを付けてほしいなどに関しても指摘している(Linus Torvalds氏のコメントその2)。
要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:5, 参考になる)
Linusが言ってることは、mergeする側の人間(つまりLinusたち)の負担が増えるからgithub経由でのpullリクエストはご遠慮ください、って事ですね。
主張だけ見れば当たり前の話でわざわざニュースで取り上げるような話じゃないんだけど
Linusが投げたメールでは、使い物にならない(原文では absolutely useless garbage)って過激な表現でこき下ろす感じになってて笑えます。
ユーザー目線で見れば ntfsのカーネルドライバは Linux 5.15 の目玉機能になります。
今までのntfsサポートは、タイムスタンプが正常に読み込めてなくて大事故が発生するとか、readアクセスでさえ使えそうで使い物にならない状態でした。
Linux使ってるとntfsなんて滅多にmountしないんですが、外付けHDDの受け渡しなどで時々mountする羽目になるので、嬉しいユーザも多いかと思います。
Re:要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:2)
https://www.kernel.org/doc/html/latest/maintainer/pull-requests.html [kernel.org]
が少し詳しくなるんですかね?
利用者一辺倒なのでここらへんを読んだ記憶はないですが・・・
Re:要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:2, 興味深い)
リンク先に、
Linus will only accept pull requests based on a signed tag. Other maintainers may differ.
とか
Linus responded that he tends to prefer the git:// protocol. Other maintainers may have different preferences.
とか、名指しされているのは笑う。
# 経緯を全く知らないので、(気難しい)メンテナー対応マニュアルって印象が
Re:要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:1)
> absolutely useless garbage
フィンランド語では「ちょっと使えない」という意味になります
Re: (スコア:0)
お、ヘイト
Re: (スコア:0)
京都弁だとどうかも気になります。
Re:要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:1)
えらいユニークなpullリクエストどすなあ。
うちらこないな高度なpullリクエストよう使わしまへんわ。
Re:要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:1)
若い頃からリスペクトしてきた京都人が多い(親戚)のですが、こんなん言われたら絶望するかもw
Re: (スコア:0)
リーナスはフィンランド人だけどスゥエーデン語だけどな
Re: (スコア:0)
Linusがgithubへpullリクエストの改善についてpullリクエストすればいいということですね
Re: (スコア:0)
Githubってプルリクエスト送れるように公開されてんの?
Re: (スコア:0)
Linus が GitHub を誉めているところ
>github is a perfectly fine hosting site, and it does a number of other things well too,
こき下ろしているところ(前文の直後)
>but merges is not one of those things.
Re: (スコア:0)
こき下ろしているかな?
「mergeはそう(うまくやっている物事)ではない」
と言っているだけだし。
Re: (スコア:0)
マージをうまくやれないバージョン管理システムていったい…
Re: (スコア:0)
Linux使ってるとntfsなんて滅多にmountしないんですが、外付けHDDの受け渡しなどで時々mountする羽目になるので、嬉しいユーザも多いかと思います。
サーバだのWeb開発環境だのならともかく、デスクトップユーザーなら日常的に使ってますよ。
ちなみにUnix File Systemの書き込み機能は依然としてdengerous。あの頃から進歩してないみたいですね。
古いストレージの読み込みができれば大抵のユーザーは足りてしまうのかしら。
# NTFSの書き込みサポート [srad.jp]にわくわくしてはや15年。今は昔。
Re:要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:2)
各Unix系OSで好き勝手に拡張してる。
やるとしたらUFS(FreeBSD), UFS(Solaris)みたいに分けて実装するしかなさそう。
# Linux以外のUnix系OSにはあまり詳しくないが…
Re:要はカーネル開発者の負担軽減に協力してほしい、ってこと (スコア:1)
dangerous ですね。
本当にそんな事言ったの? (スコア:2, おもしろおかしい)
マージですか
Re: (スコア:0)
マージですよ
Re: (スコア:0)
マージ・マジ・マジカ
Re: (スコア:0)
約9000円のスクラッチペンはやりすぎだと思った
https://www.takaratomy.co.jp/products/mazica_party/lineup/mz-16.html [takaratomy.co.jp]
#違う
Re: (スコア:0)
ガイジwww
「今回はいいよ」って言ってるじゃん (スコア:2, 参考になる)
Linux も昔よりずいぶん丸くなって、"Ok, to expedite this all and not cause any further pointless churn and
jumping through hoops, I'll let it slide this time" (これ以上もめたりハードルを高くして遅らせたくないから今回はいいことにするよ) "the initial pull often has a few oddities and I'll accept them now, but for continued development you need to do things properly." (最初のpullは変なとこもあるけど受け入れるよ、継続的に開発に参加するなら正しい流儀を覚えていってね) と言ってる。非常に真っ当な反応。
Re: (スコア:0)
そりゃ、急かした本人だし、コレでキレたら阿呆ですがな。
部下に仕事を引き継ぎせずにこれ明日までにやっといてと丸投げして、
できた成果物が思ってたのと違うみたいな状況でしょ。
デキル部下なら質問してきたり資料さがしたりするだろうけど、みんなデキル部下じゃないし。
Re: (スコア:0)
阿呆ではないと思うけどなぁ。ちょっと例えが悪すぎるよ。
Paragon Softwareは別にLinusの部下じゃないわけだし、そもそも個人ですらない。
しかも、別に「明日までにやっといて」なんてLinus言ってないんじゃないの?
詳細な経緯しらないから、もし指示なり要請なり出してたんならごめんやけど、Linusが直接どっかのデベロッパに
「これやれ」
なんて言うわけがないと思うんだよなぁ。
丸くなったのは当然悪い事じゃ無いけど、昔のままのスタイルでも別に良かったんでないかな、って思ってる。見てて楽しいから。
Re: (スコア:0)
あ、ごめん。
俺がアホやったみたいだ。
言ってるな、Linus。
本文の流し読み、良くないね。反省します。
Re: (スコア:0)
四角いLinuxをください
確かにgithubのマージコミットのメッセージは役に立たない (スコア:1)
>マージに関連する情報を含む適切なコミットメッセージが必要
これに尽きる。
これは内容把握してる人間自身が書くしかないんでgithubが生成するメッセージは必要な情報がなくてhistoryのノイズになる。
Re: (スコア:0)
内容把握してる人間自身が書くしかない
TPOをわきまえ価値があるコメントが書ければ、それは一流のエンジニアだ
ってOJTの先輩が言ってた
良い方法があります (スコア:0)
systend-gitとsystend-githubがあればいいのですよ(オイヤメロ
Re: (スコア:0)
systemd-kernelとsystemd-linuxはまだですか?
ローカル・ルールの話か。 (スコア:0)
分かりやすくドキュメント化されてないと初見は戸惑うだけだし。
GitHubにローカル・ルールに沿ったチェックやワークフロー機能が追加されると良いかも。
Re: (スコア:0)
ローカルルールとは言え、世界最大のローカルプロジェクトの影響はグローバルスタンダード並に大きい。
Re: (スコア:0)
GitHubのローカルルールをLinuxカーネルのgitリポジトリに持ち込むなってことでは?
Re: (スコア:0)
gitやGitLabだろうとLinuxカーネルのgitリポジトリの作法に従わなきゃ同じ事言われるだろうからその指摘は的外れ。
Re: (スコア:0)
別コメントによるとLinuxのローカルルールですらなくLinusの俺様ルールのような。
「ま、まああんたほどの実力者がそう言うのなら…」
Re: (スコア:0)
ローカル(gitの開発目的プロジェクト、かつ開発者本人の)ルールですな。
某クラウド会計ソフトを作ってる会社では (スコア:0)
masterではなく、テスト用のブランチにマージしろ
このルールを無視したら、一度目は警告で済ませるけど、二度目は雇用契約を解除するなんてルールがある
ローカルルールに沿っていなければマージやプルリクできない仕組みとかあってもいいかも
Re:某クラウド会計ソフトを作ってる会社では (スコア:1)
> 一度目は警告で済ませるけど、二度目は雇用契約を解除するなんてルールがある
それこそ GitHub でも、ブランチの保護と承認マージの機能はあると思うんだけど、
なんでルールで縛るんですかね?
> ローカルルールに沿っていなければマージやプルリクできない仕組みとかあってもいいかも
これは commit hook とか merge hook がその「仕組み」なんじゃないん?
Re: (スコア:0)
問題はやりたい事がhookで完結できない点。
テストか否かとかhookじゃ判別できない。
Re: (スコア:0)
いや、流石にmasterは権限絞れよと思ってしまう
NTFSはリードオンリーでマウントするのがいい (スコア:0)
LinuxからNTFSを書き込み可能としてマウントして書き込むと、なにかとトラブルが多い
リードオンリーでマウントして、読み込み専用で使うのが最適
読み込みオンリーなら、いままでトラブルにあったことは無い
Re: (スコア:0)
既存のNTFSドライバーにそういった問題があるからもっと品質が高いやつで置き換えようぜってのが今回の話なのですが
面倒臭いから貢献したくない (スコア:0)
ってなるわ。
いや大きな組織で大物のやり取りするならプロトコルは大事ってのは承知だけどね。
Re:面倒臭いから貢献したくない (スコア:1)
気持ちはわかる。でも、それに対して
a)そうなったらコミットする人が減って困るので、柔軟にルールを改善していく必要がある
b)そういうルールを守れない人は参加されると逆に迷惑なので、むしろ来ないでほしい
という両方の反応があるわけだ。
で、普通はa)が選ばれることが多いんだけど、オープンソースでの開発では、b)が正解であることが結構あるんで。
Re: (スコア:0)
マージ後にメンテナンスするのはえてして他の人なので以後のメンテナンスコストを増やしてまで、雑な貢献受け入れないっていうのは、オープンソース以外でもそれなりに
Re: (スコア:0)
まあ本当に必要なら元から居る誰かが書くでしょう。