Linus Torvalds 氏の理想の git 運用と GitHub

It is imperative that all code contributed to the kernel be legitimately free software. For that reason, code from anonymous (or pseudonymous) contributors will not be accepted. All contributors are required to “sign off” on their code, stating that the code can be distributed with the kernel under the GPL.

Google 翻訳 による翻訳:

カーネルに貢献するすべてのコードは、合法的にフリー ソフトウェアである必要があります。 そのため、匿名 (または仮名) の貢献者からのコードは受け入れられません。 すべての貢献者は、GPL の下でカーネルと共にコードを配布できることを宣言して、コードを「承認」する必要があります。

I know about digital signatures etc, and that is not what this is about. This is not about proving authorship - it’s about documenting the process. This does not replace or preclude things like PGP-signed emails, this is documenting how we work, so that we can show people who don’t understand the open source process.

Google 翻訳 による翻訳:

私はデジタル署名などについて知っていますが、それはこれに関するものではあり ません。 これは著者であることを証明することではなく、プロセスを 文書化 することです。 これは、PGP 署名付き電子メールのようなものを置き換えたり、排除したりするものではありません。これは、オープン ソース プロセスを理解していない人々に見せることができるように、私たちの作業方法を文書化したものです。

These days, most of the patches in the kernel don’t actually get sent directly to me. That not just wouldn’t scale, but the fact is, there’s a lot of subsystems I have no clue about, and thus no way of judging how good the patch is.

Google 翻訳 による翻訳（一部修正）:

最近では、カーネル内のほとんどのパッチは私へ直接送信されません。 それは単にスケールしないだけでなく、実際問題私が手がかりを持たない多くのサブシステムがあり、したがってパッチがどれほど良いかを判断する方法がありません。

So I end up seeing mostly the maintainers of the subsystem, and when a bug happens, what I want to see is the maintainer name, not a random developer who I don’t even know if he is active any more. So at least for me, the chain is actually mostly more important than the actual originator.

There is also another issue, namely the fact than when I (or anybody else, for that matter) get an emailed patch, the only thing I can see directly is the sender information, and that’s the part I trust. When Andrew sends me a patch, I trust it because it comes from him - even if the original author may be somebody I don’t know. So the path the patch came in through actually documents that chain of trust - we all tend to know the "next hop", but we do not necessarily have direct knowledge of the full chain.

DeepL 翻訳（一部修正）:

バグが発生したときに見たいのは、もう活動しているかどうかもわからないランダムな開発者ではなく、
メンテナの名前なんです。ですから、少なくとも私にとっては、実際の発案者よりも チェーン の方が重要なのです。

また、もうひとつの問題があります。それは、私（あるいは他の人）が電子メールでパッチを受け取るとき、
直接見ることができるのは送信者の情報だけであり、それは私が信頼する部分でもあります。
アンドリューからパッチが送られてくると、たとえ元の作者が知らない人であっても、それは彼から送られてきたものだから信用できる。
つまり、パッチが送られてきた 経路 は、信頼の連鎖を実際に文書化したものなのです - 私たちは皆、
「次のホップ」を知っている傾向にありますが、必ずしも完全な連鎖を直接知っているわけではありません。

So the github commit UI should have

• separate "shortlog" one-liner text window, so that people cannot screw that up.

• some way to actually do sane word-wrap at the standard 72-column mark.

• reminders about sign-offs etc that some projects need for project-specific or even legal reasons.

筆者訳:

なので github のコミットUIは 以下を備えるべきだ。

• 分離したワンライナー "shortlog" テキストウィンドウ。これにより、人々がコミットを台無しなものにできなくなる。

• 標準的な 72 カラム地点のマークによって適切なワードラップを実際にさせる手段。

• プロジェクト特有の理由あるいは法的な理由によって必要される sign-off 等のためのリマインダ。

For github accounts (or really, anything but kernel.org where I can just trust the account management), I really want the pull request to be a signed tag, not just a plain branch.

意訳:

github アカウント（実際にはアカウントが信頼できる kernel.org 以外のもの）では、 プルリクエストはプレーンなブランチではなく署名付きタグであってほしいです。

In a perfect world, it would be a PGP signature that I can trace directly to you through the chain of trust, but I’ve never actually required that.

意訳:

理想の世界では、PGP 署名が信頼のチェーンを通して直接追跡できる術（すべ）になると思いますが、実際それを要求したことはありません。

So while I prefer to see a full chain of trust, I realize that isn’t always easy to set up, and so at least I want to see an "identity" that stays constant so that I can see that pulls come from the same consistent source that controls that key.

意訳:

完全な信頼のチェーンを見たいと思う一方で、それが簡単に用意できるものではないことを理解しています。 だからせめて不変な「身元」を確認することで、その pull が、署名鍵を管理する一貫性のあるソースからのものであることを確認したいのです。

.. because I think github does some things very well.

So sure, you may think I hate github. I don’t. I hate very specific parts of github that I think are done badly.

But other parts are done really really well.

I think github does a stellar job at the actual hosting part. I really do. There is no question in my mind that github is one of the absolute best places to host a project. It’s fast, it’s efficient, it works, and it’s available to anybody.

That’s wonderful. I think github is absolutely lovely in many respects.

And that then makes me really annoyed at the places where I think github does a subpar job: pull requests and committing changes using the web interface.

DeepL 翻訳:

…​というのも、githubはいくつかの点で非常によくできていると思うからです。

だから確かに、あなたは私がgithubを嫌っていると思うかもしれません。そうではありません。githubの特定の部分、悪いと思う部分は嫌いです。

しかし、他の部分は本当によくできています。

githubは実際のホスティングの部分では素晴らしい仕事をしていると思います。本当にそう思います。githubは、ホスティングを行う場所としてプロジェクトのホスティングに最適な場所のひとつです。速いし、効率的だし、ちゃんと動くし、誰でも使えるし。

それは素晴らしいことです。githubは多くの点で本当にすばらしいと思います。

そのため、githubが劣悪な仕事をしていると思う場所、つまりプルリクエストやウェブインターフェイスを使った変更のコミットには、本当にイライラさせられます。