パスワードを忘れた? アカウント作成
12995956 story
Linux

Linuxの開発者であるLinus Torvalds氏がGitHub上でプルリクエストを受け付けない理由 40

ストーリー by hylom
少なくともGitHubのみに依存しないのは正しいと思う 部門より
insiderman 曰く、

Redditで「This is why Linus doesn't accept PRs from GitHub」(LinusがGitHubからのプルリクエストを受け付けない理由がこれだ)という画像が話題になっている。

ここで言われている「Linus」は、もちろんLinuxの開発者であるLinus Torvalds氏。この画像は、GitHub上のLinuxのリポジトリに対する「Delete duplicate word "long long" in Introduction」(イントロダクション中でダブっている「long long」という単語を削除)いうプルリクエスト。これに対し、ほかの開発者からが「long long」は単語がダブってるわけではなくそういう型であるとの返答が付いている。

Redditではこれに対し批判と擁護の両方のコメントが寄せられている。Linuxでは過去に単にドキュメントの見出しテキストを装飾するための「-」(ハイフン)が不足しているのを修正するというコミットが受け付けられている例があり、正当な手順で正当な内容の修正が送られれば誰からの修正も受け付けるというスタンスである。

なお、Linus氏はGitHubのプルリクエストを使用しないことを明言しているが、その理由は有効なメールアドレスなどの情報がプルリクエストには抜けていたり、diffが非実用的であるといった理由を述べている。また、Gitのプルリクエスト機能やGitHubのホスティングサービスについては好意的に評価しているが、GitHubのプルリクエストについては総合的に見て劣っており、使えない物となっていると評している。Linus氏はそのことをGitHubに伝えたがGitHub側は取り合わなかったそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by annoymouse coward (11178) on 2016年11月29日 21時37分 (#3122056) 日記

    プルリクエストは受け付ける側の負担を考慮して出すべきだと思います

    たとえばコミットメッセージには
    (1)変更の概要(何を変更したか)
    (2)変更の理由(何故変更したのか)
    の両方を書くべきです

    受け付ける側の立場からすると
    この2つの情報が揃って初めて merge してみるかという気になります

    タレコミのプルリクエストの例では(2)が欠けており
    変更の必要性が伝わってきません
    これでは無視されたり却下されても文句は言えないと思います

    • by Anonymous Coward
      > タレコミのプルリクエストの例では(2)が欠けており
      > 変更の必要性が伝わってきません

      そういう問題だろうか。
      あなたは「『ほどほどに』という単語は『ほど』がduplicateして間違っているので修正しました」、というpull requestを「mergeしてみるか」という気になるのでしょうか。
      • by Anonymous Coward

        ネタなのかマジなのか、わかんねぇなぁ

      • by Anonymous Coward

        >「『ほどほどに』という単語は『ほど』がduplicateして間違っているので修正しました」
        それをなぜ間違いとしているかが書かれてないから(2)の要件を満たしてないと言ってるように見えるけど
        ちゃんと読めてます?

        • by Anonymous Coward

          普通に考えれば間違いではないのが明らかなので要件以前に日本語(入門書レベルのソース)くらい読めるようになってから来いよオラァん!
          という話では?

        • by Anonymous Coward

          Linux Torvalds氏がスラドを読まない理由

    • by Anonymous Coward

      理由が他者に分からないならそれは書くべきだし、相手が分からなくて知りたそうな事は書いた方が良いのは一般にコメントと呼ばれるもので共通する配慮ではあると思う。

      そのコメントはソースに書かれるべきか、コミットメッセージに書かれるべきか、プルリクエストのコメントに書かれるべきか。
      そのコメントは誰が見るもので、その彼は一体何を知らず、何を知りたいのか、難しいよね。

      • by Anonymous Coward

        C的には一箇所に書いておき たどればいい、でしょうが、
        経験的に全部に書くべきと考えます。

        まぁソースに書けばあとはコピペですが。

        あと誰が見るものか、は考えても無駄です。自分(未来の)に伝わるようにだけ
        悩みましょう。
        自分すらわからないものが人に伝わるはずありません。

    • by Anonymous Coward

      いや、あの……。
      くだんのプルリクエスト [github.com]は、「C言語にはlong longという型がある」ということを知らないトンチキ初学者によるもので、変更の必要性が*ない*ことが概要だけから伝わってくる、必要にして十分なものですよ?

      というか、これ、無理矢理理由を書くとしたら、

      (1)変更の概要 : "long long" を "long" に修正した
      (2)変更の理由 : "long" が重複していたから

      以上に書くことないでしょ。

      # long longの存在を知らないレベルの人が、どうしてドキュメントを修正しようと思ったのか、そこが最大の謎。

      • by Anonymous Coward

        >(2)変更の理由 : "long" が重複していたから
        重複しているのは「事実」であり、その正否を判断する「理由」では無い。

        • by Anonymous Coward on 2016年11月30日 8時52分 (#3122231)

          理由が書いてあれば、別の修正方法も考えることできますからね

          親コメント
        • by Anonymous Coward

          重複しているという「事実」なんて無いでしょ。
          連続と重複は全然ちがう。
          int **PPValue; を見て「*が重複してるのは事実」と言ってるようなもの。

          • by Anonymous Coward

            >「*が重複してるのは事実」
            これも事実でしょ。
            その状態にどのような意味があるかとは何ら関係無い。
            これを無意味な重複と判断したのか意味のある連続だが誤った動作と
            判断したのかを理由に書くべきだという話。

            (1)変更の概要 :フラグAが変更されないように修正しました。
            (2)変更の理由 :フラグAが変更されていたため。

            これが説明になってると思えるの?

            • > 判断したのかを理由に書くべきだという話。
              完全に同意する。

              そして同時に、今回のRedittの投稿が、プルリク(のキャプチャ)だけ見せて「これが理由だ」と言っているところが、
              まさに「こういう投稿があった」という「事実」を書いただけで「理由」を説明していない、同レベルの投稿になっていて、なんともモニョる。

              例えばもう一言、「このレベルの初学者を相手にするのは嫌気がさすだろう」とでも書けば理由の説明になるんだけど。

              親コメント
            • by Anonymous Coward

              long という文字列が「連続している」は判断を伴わない事実だけど、
              「重複している」というのは判断です。
              実際「long long」という記載が正しければ、それは重複ではないのが事実です。

        • by Anonymous Coward

          重複しているのは「事実」であり、その正否を判断する「理由」では無い。

          変更したいと思った理由が「重複しているから」と認識したいうことであって、それには正否もクソもないよ。 その「重複しているという認識」には正否はある。

      • by Anonymous Coward

        元コメはタイトルの典型例という文言からして、一般論の話として(2)が無いとマージする気が起こらんという話をしているのではなくて?

        それを(2)なんか決まっとるじゃないか、とか噛み付くのは愚かな反応かと。

  • million million (スコア:5, 参考になる)

    by taka2 (14791) on 2016年11月29日 21時55分 (#3122065) ホームページ 日記

    アイザック・アシモフが、科学エッセイで宇宙のスケールを語る際に、0が12個の意味で「million million」を使ったら、編集者に「million」と書き換えられてしまった、って話がエッセイで語られてました。小学生から(概算した上で)「この表現は桁がおかしいいんじゃないですか」という指摘の手紙が届いたとか。

    英語では口語的表現として強調の意味で同じ単語を2回繰り返してしまう場合がよくあり、文語で同じ単語の連続があったら校正でマメに1個に直してくものなんだとか。

    long long もそういうありがちなミスだと思い込んで、誤植を見つけたぞとばかりに pull request を投げたんでしょうねぇ。

    • by Anonymous Coward

      それにしても、long longの意味するところが分からないレベルの人がLinuxカーネルのリポジトリを直そうとしてることに驚き。

      # creat()システムコールなんかも、"create"のtypoだってpull requestが上がってきたりするのかなあ。

      • by ktmizugaki (46208) on 2016年11月30日 12時37分 (#3122402) 日記

        変更対象は、ソースファイルではなく、ドキュメントファイルなんですよね。
        Linuxカーネルは違いそうだけど、「コードが書けなくても、ドキュメントに貢献することはできますよ」的な事が書いてあるオープンソースプロジェクトは割とよくあるので、
        long long の人も、そのノリでプルリクエストを送ってきたのではないかと。
        つまり、初学者どころか、C なんて知らんて人の可能性も考えられます。

        --
        svn-init() {
          svnadmin create .svnrepo
          svn checkout file://$PWD/.svnrepo .
        }
        親コメント
        • by Anonymous Coward

          そういうタコを大切にするのがLinuxだったと思ってたんだが...
          積極性を褒めこそすれ、あげつらうのは良くないよ。BSDじゃないんだから(不適切発言)

          • by Anonymous Coward

            ああ、タコとか言ってましたねえ懐かしい。しかしそれって日本のユーザーコミュニティの話だったと思うんですが。
            どうもLinuxカーネルのコミュニティというと、おかしなことをやらかすと即座にLinusから暴言を投げつけられてシメられる、というイメージが(←偏見)。

            • by Anonymous Coward

              > 即座にLinusから暴言を投げつけられてシメられる
               
              確かに。そうなると高齢化一直線なんだよなぁ。

      • by Anonymous Coward

        もしかして: create [google.co.jp]

        # ググレカスおまえもか

      • by Anonymous Coward

        referer
        もひとつついでに有名どころ
        さすがにgoogleで「もしかして:」とか言われないが

    • by Anonymous Coward

      billion以上は英米で互換性がないという問題があるのよね。
      そんなあなたにSI記数法

  • by Anonymous Coward on 2016年11月29日 21時48分 (#3122063)

    「-」(ハイフン)が不足しているのを修正するPRを送ったのは4歳のょぅι゛ょだという。

    • by Anonymous Coward

      プルリクエストにあわせて、受け取ってコミットする側も幼女・少女というケースも増えていくはず。
      魔法少女がブラック職な昨今、これからはコミッター少女が流行るに違いありません。

      数年後、「パッチコミッターさくら」(略称: PCさくら)がアニメ化、全国放送される可能性もないとはいえないでしょう。
      パッチを回収・コミット、そしてリリースするのです。
      ちなみに、使い魔は自動テストやリリースをしてくれるbot。

  • by Anonymous Coward on 2016年11月30日 11時26分 (#3122353)

    GitHubでの”Merge pull request”の弊害 [postd.cc]
    この記事が参考になるかも。
    GitはLinusが作ったんだからそりゃ自分が使う機能を含めてるに決まってるよな。

  • sをつけただけのコミットでは?

    • by Anonymous Coward

      下の行にsをつけた結果足りなくなった「-」を補ったんだよ。

  • by Anonymous Coward on 2016年11月30日 0時36分 (#3122132)

    これを機会に int64 int64_t あたりが普及してくれる事を願います

    • by Anonymous Coward

      linux kernelからするとstdint.hを使わないといけなくなるデメリットしかないな

      • by Anonymous Coward

        Linuxカーネルのように様々な環境に移植されているもので移植性がメリットではないと?

        • by Anonymous Coward

          デメリットが1つしかないと言ってるだけで(だからやれるね、やろう)、
          メリットが無いなんて言ってないと思うんですが。

          自分で書いててあれだけど否定ばっかの文で、読みにくいな。

        • by Anonymous Coward

          kernelは独自定義してるので、stdint.hを使う必要はないし
          確実に定義される保証のないものを使うとかあり得ない

  • by Anonymous Coward on 2016年11月30日 9時15分 (#3122249)

    >diffが非実用的であるといった理由を述べている

    これってどういうことだろ?
    diffつかわんの?何で差分確認してるんだ?

    • by Anonymous Coward

      > >diffが非実用的であるといった理由を述べている
      >
      > これってどういうことだろ?
      > diffつかわんの?何で差分確認してるんだ?

      GitHubのdiffインタフェースが信頼できないということでしょう。

      • by Anonymous Coward

        ああ、ごめん、そういうことか

    • by Anonymous Coward

      原文はdiffではなくdiffstatと書いてある
      linusはdiffstatが気に入らないのでgitにdirstatを作った

      以下推測だが
      githubではdirstatを使えなくてlinusはそれが気に入らないのではないだろうか

typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...