CodeIgniter4の開発に参加する
(2022-12-31 追記) 古くなっていた内容を更新しました。
この記事は CodeIgniter Advent Calendar 2020 - Qiita の22日目です。まだ、空きがありますので、興味のある方は気軽に参加してください。
今日は CodeIgniter4 の開発に参加する方法、主に、PR を送る方法を書いておきます。
CodeIgniter4 のバグを見つけたり、ちょっと改良したいと思ったら、気軽に PR を送ることができます。
最も重要なこと
オープンソースソフトウェアの開発で最も重要なことはライセンスです。
PR を送るということは、そのソフトウェアを改変するということであり、その変更が法的に問題ないことが必要です。
CodeIgniter は MIT ライセンスなので、PR する変更が MIT ライセンスと矛盾しないことが必要です。
自分が著作権を持つ自分が100％書いたコードであれば、自分が MIT ライセンスにして寄贈するということになり、問題はありません。
CodeIgniter4 の開発では、Developer's Certificate of Origin 1.1 による宣誓が求められています。
Developer's Certificate of Origin (DCO) とは？
これは、簡単に言うと、提供するコードが CodeIgniter に取り込まれても法的に問題がないということを、コード提供者 (コントリビュータ) が宣誓するというものです。私の提供するコードは他人の知的財産権を侵害していません、と。
著作権的に問題となるコードが CodeIgniter に取り込まれるのを防ぐためのものです。
もともと Linux kernel の開発で採用された仕組みです。JF にその解説の文書がありますので引用しておきます。
http://sourceforge.jp/projects/linuxjf/wiki/SubmittingPatches/attach/SubmittingPatches.txt より。
12) Sign your work
12) パッチへの署名
To improve tracking of who did what, especially with patches that can
percolate to their final resting place in the kernel through several
layers of maintainers, we've introduced a "sign-off" procedure on
patches that are being emailed around.
誰が何をしたのかを追いかけやすくするために (特に、パッチが何人かの
メンテナを経て最終的に Linux カーネルに取り込まれる場合のために)、電子
メールでやり取りされるパッチに対して「 sign-off 」という手続きを導入し
ました。
The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as a open-source patch. The rules are pretty simple: if you
can certify the below:
「 sign-off 」とは、パッチがあなたの書いたものであるか、あるいは、
あなたがそのパッチをオープンソースとして提供する権利を保持している、
という証明をパッチの説明の末尾に一行記載するというものです。
ルールはとても単純です。以下の項目を確認して下さい。
Developer's Certificate of Origin 1.1
原作者の証明書( DCO ) 1.1
By making a contribution to this project, I certify that:
このプロジェクトに寄与するものとして、以下のことを証明する。
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(a) 本寄与は私が全体又は一部作成したものであり、私がそのファイ
ル中に明示されたオープンソースライセンスの下で公開する権利
を持っている。もしくは、
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(b) 本寄与は、私が知る限り、適切なオープンソースライセンスでカバ
ーされている既存の作品を元にしている。同時に、私はそのライセ
ンスの下で、私が全体又は一部作成した修正物を、ファイル中で示
される同一のオープンソースライセンスで(異なるライセンスの下で
投稿することが許可されている場合を除いて)投稿する権利を持って
いる。もしくは、
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(c) 本寄与は(a)、(b)、(c)を証明する第3者から私へ直接提供された
ものであり、私はそれに変更を加えていない。
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
私はこのプロジェクトと本寄与が公のものであることに理解及び同意す
る。同時に、関与した記録(投稿の際の全ての個人情報と sign-off を
含む)が無期限に保全されることと、当該プロジェクト又は関連する
オープンソースライセンスに沿った形で再配布されることに理解及び
同意する。
then you just add a line saying
もしこれに同意できるなら、以下のような1行を追加してください。
Signed-off-by: Random J Developer <random@developer.example.org>
using your real name (sorry, no pseudonyms or anonymous contributions.)
実名を使ってください。(残念ですが、偽名や匿名による寄与はできません。)
Some people also put extra tags at the end. They'll just be ignored for
now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
人によっては sign-off の近くに追加のタグを付加しています。それらは今のところ
無視されますが、あなたはそのタグを社内の手続きに利用したり、sign-off に特別
な情報を示したりすることができます。
CodeIgniter4 の開発では、これに同意することを示すため、Git の commit に GPG 署名 が求められています。
準備
PR を送るための準備をしましょう。
CodeIgniter4 リポジトリの fork
GitHub で CodeIgniter4 開発の公式リポジトリ を fork してください。
GnuPG のインストール＆設定
Git の commit に GPG 署名をする必要がありますので、GPG をインストールして Git を設定する必要があります。
上記に従い設定してください。
自分の CodeIgniter4 リポジトリの準備
fork した自分のリポジトリを clone します。
$ git clone git@github.com:{あなたのアカウント}/CodeIgniter4.git
本家リポジトリを upstream として追加します。
$ cd CodeIgniter4
$ git remote add upstream git://github.com/codeigniter4/CodeIgniter4.git
Composer パッケージのインストールも必要ですね。
$ composer install
貢献に関するドキュメントを読む
以下からたどれますが、結構たくさんあります。
上記と以下くらいは見ておくとよいかも知れません。
(2022-12-31 追記) なお、現在 CodeIgniter4 のコーディングスタイルは PSR-12 準拠になっています。
CodeIgniter4 の変更（修正）
準備が出来たら、コードを変更していきます。
ブランチの作成
PR のための新しいブランチを作成します。
(2022-12-31 追記)
現在、バグ修正の PR は develop ブランチに、機能追加の PR は 4.3 のような次のマイナーバージョンのブランチに送る必要があります。適切なブランチから新しいブランチを作成してください。
$ git checkout -b fix-foo
コードの変更
バグ修正や機能追加を行います。
ユーザガイドの変更
コードの変更に伴い、ユーザガイドの変更が発生する場合は、ユーザガイドも変更します。
ユーザガイドのビルド方法は以下を参照してください。
テストの実行
変更したファイルに対するテストを実行します。ない場合はテストを作成します。
$ vendor/bin/phpunit --no-coverage tests/system/API/ResponseTraitTest.php
PHPUnit 8.5.4 by Sebastian Bergmann and contributors.
............................ 28 / 28 (100%)
Time: 213 ms, Memory: 10.00 MB
OK (28 tests, 78 assertions)
変更のコミット
変更をコミットします。GPG署名を忘れずに。
コミットメッセージは、具体的に何を変更したかを英語で記述します。「Fixes #1234」のようなコミットメッセージはやめましょう。
GitHub への push
GitHub へ push します。
$ git push origin HEAD
PR の作成
ブラウザから GitHub の CodeIgniter4 開発の公式リポジトリ にアクセスし、PR を作成します。
PR のテンプレートは以下のようになっています。
**Description** 以下に変更の内容、理由を英語で説明します。
PR が既存の issue を修正する場合は、例えば、「Fixes #12345」のように参照を記載します。
完了できている項目は、**Checklist:** にチェックを入れます。
<!--
Each pull request should address a single issue and have a meaningful title.
- Pull requests must be in English.
- If a pull request fixes an issue, reference the issue with a suitable keyword (e.g., Fixes <issue number>).
- All bug fixes should be sent to the __"develop"__ branch, this is where the next bug fix version will be developed.
- PRs with any enhancement should be sent to the next minor version branch, e.g. __"4.3"__
-->
**Description**
Explain what you have changed, and why.
**Checklist:**
- [ ] Securely signed commits
- [ ] Component(s) with PHPDoc blocks, only if necessary or adds value
- [ ] Unit testing, with >80% coverage
- [ ] User guide updated
- [ ] Conforms to style guide
**Description** より上のコメントは必要ないので、読んだら削除します。
(2022-12-31 追記)
機能追加の PR の場合は、develop ではなく 4.3 のような次のマイナーバージョンのブランチに送る必要があります。
base ブランチを変更してください。
本家の開発が進みマージできなくなったら
PR を送ってもマージされる前に、本家の開発が進み conflict してしまうということもあり得ます。
その場合は、PR 用のブランチを rebase します。
まず、develop ブランチを最新にします。
(2022-12-31 追記)
機能追加の PR の場合は、develop ではなく 4.3 のような次のマイナーバージョンのブランチに送る必要があります。
適切なブランチに読み替えてください。
$ git checkout develop
$ git fetch upstream
$ git merge upstream/develop
$ git push origin HEAD
そして、PR 用のブランチを rebase します。
$ git checkout fix-foo
$ git rebase upstream/develop
conflict が発生したら解消してください。
GitHub の自分のリポジトリに強制 push します。
$ git push --force-with-lease origin HEAD
これで、PR が最新の develop から分岐したようになりました。
この記事は CodeIgniter Advent Calendar 2020 - Qiita の22日目です。まだ、空きがありますので、興味のある方は気軽に参加してください。
参考
Date: 2020/12/22
