現在Pythonの開発プロセス管理を担当しているBrett Cannon氏が，Pythonのcore workflowメーリングリストを通じて，GitHubへの移行を発表した。氏はInfoQのインタビューに応える中で，今回の決定に至った１年間に及ぶプロセスと，その中で検討された３つの提案について説明してくれた。
この中から最終的にGitHubが選択されたのには，主に３つの要因があった。
- GitHubとGitLabが機能面でほぼ同等であること。GitLabがオープンソースであることについては，それ自体を決め手だとは考えなかったと，Cannon氏は特に記している。
- コアな開発者や外部協力者の間に，GitHubに精通している開発者が多いこと。GitHubへの移行に反対を表明する開発者もいたが，コミュニティがそちらを選択した場合，その使用を拒否すると言うものは誰もいなかった。
- Guido van Rossum氏の意向。氏のコントリビューションは以前ほど頻繁ではないが，氏がプロジェクトから疎遠になることのリスクをCannon氏は考慮した。
Cannon氏はInfoQに，今回の決定について次のように説明した。
基本的に今回の決定は，私がこれまで行なった前２回の開発プロセス変更と同じような方法で実施しました。この問題について考えられるソリューションをPEP(Python Extension Proposal)として提案した上で，それらについて議論し(ご存知かも知れませんが，議論は非常に流動的でした。その中でPEPは，詳細な最新提案というよりも，議論の出発点として扱われる結果になっています)，テストインスタンスなどさまざまな期日を設定しました。決断を下す段階では，その時点で私の知り得るすべてのものに基づいた決定を行ないました。
PythonがGitHubを使用するのは，リポジトリのホスティング提供とコードレビューのサポートのみである点にも注意が必要だ。イシュートラッカとWikiについては従来と変わらない。
Cannon氏の発表は，Pythonのコア開発者の間に論議を引き起こした。 Stefan Krah氏は，事実としてメーリングリストの大半の開発者がGitLabを希望している，という自身の見解を述べている。これに対してCannon氏は，GitHubを選択した場合にコントリビューションを止める意思があるかという問いに関して，多くのコメントをメーリングリスト外のリプライとして受け取っていることを返答した。さらに氏は，自身の気持ちとして，GitHubへの移行に不満を覚える一部の人たちにGitHubのメリットを理解してもらう方が賢明な方法だということも付け加えている。
InfoQはBrett Cannon氏にインタビューして，今回の決定に対して期待できるメリットや，プロセスの次のステップなどを詳細に聞いた。
PythonとPythonコミュニティにとってGitHubへの移行にはどのようなメリットがあるのか，簡単に説明して頂けますか？
それについては，私が現在作成中のPEPドラフト(https://github.com/brettcannon/github-transition-pep/blob/master/pep-NNNN.rst)にも書いていますが，パッチレビューが早くなることや，コントリビューションが簡単になること(本当に重要なのは前者で，後者はおまけですか)などのメリットが期待できます。GitHubにある，あるいは開発可能なツーリングすべてを利用して，Python開発チームがこれまで行なってきた多くの手作業がすべて自動化できれば，パッチのレビューに要している時間を大幅な削減と，それによるスループット向上が実現できると期待しています(現在の私たちにとって最も大きな問題は，外部からのコントリビューション処理がイシュートラッカに大きな時間を取られるために，思うように集まっていないことなのです)。開発チーム，オープンソースコミュニティ全般のどちらもGitHubに慣れ親しんでいる点も加味すれば，関係者すべてのオペレーションがこれまでより早く，簡単に行なえるようになるのではないかと思います。
現在の状況と今後のステップについて教えてください。
状況としては，2016年1月1日にPython開発をGitHubにスイッチすることが決まったところです。現在は，さまざまなソースリポジトリの移行に必要なすべての手順を概説したPEPを作成しています(先程の質問で述べたPEPです)。core-workflowメーリングリストでの議論がまとまって，詳細な作業を網羅したPEPが出来上がったら，作業に着手する予定です(https://mail.python.org/mailman/listinfo/core-workflow)。
具体的な次のステップとしては，コードリポジトリ移行を妨げている重大な障害を解決したいと思っています。必要なツーリングに従ってリポジトリの移行順序を決めるために，まずは全体に関わる問題を解決して，その後，個々のリポジトリに関する問題に順次着手するつもりです。
今回の発表で，Pythonメーリングリストではいくつかの議論が起きていましたが，議論の結果には納得していますか？
今回の決定を発表した後，core-workflowメーリングリストで起きた議論のことだと思いますが，その結論については納得しています。オープンソース版があることから，GitLabを選択してはどうかという意見もありましたが，今回の選択については皆が理解していますし，私の置かれていたタフな立場も分かってくれています。この件についても肯定的な立場を保って，可能な限りプラットフォーム非依存な開発プロセスを維持し，将来的なプラットフォーム変更を容易にするための機会ととらえてくれています(そういったことも将来的にはあるでしょう – 私がコア開発者になってから今回で３回目ですし，Python自体，25年経った現在も強化が続けられています。数年後に再びプラットフォームを変更することも，あり得ないとは言えません)。
オープンソースプロジェクトのGitHubへのマイグレーションは，最近ではごく常識的なことになっていますが，一部の人たちのように，ひとつの企業があまりに強大な管理権を持つことに対して，不安に思うことはありませんか？Pyhonでこれが問題になったことはないのでしょうか？
プラットフォーム変更を議論する時になれば(いつかはそうなると思いますが)，そのような心配もあります。ですが今回は，GitリポジトリとコードレビューのホストとしてGitHubを利用するだけです。リポジトリの移動は簡単ですし，後者はプルリクエストをクローズするための一時的なものですから，履歴にも大した価値はありません。そうは言っても，コントリビューションを一度受け入れた以上，そのレビュー履歴にも意味がありますから，移転しなければならない場合に備えて，コードレビュー履歴のバックアップを計画しています。GitHubにデータアクセスのためのAPIがなくて，私たちのデータを閉ざされた場所に置くことになるのならば，最初から考慮に対象にはならなかったでしょう。さらにGitLabなどのプラットフォームには，プロジェクト – プルリクエストも含みます – をインポートするためのツールもありますから，急にGitHubを離れなくてはならない場合でも，時間以外に失うものは何もありません。イシュートラッカを移転しないことも，変更やコントロールを失う心配をしなくてはならない範囲を限定する上で有効になっています。
[最新情報 2016年1月15日]: このニュースを公開した後にBrett Cannon氏が，PythonのGitHub移行に関する意思決定プロセスの全履歴を文書にしたことを我々に教えてくれた。興味深い詳細や洞察が数多く記されている。