Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

日本語訳:hhvm/CONTRIBUTING.md #4

Open
akirakoyasu opened this issue Dec 28, 2015 · 4 comments
Open

日本語訳:hhvm/CONTRIBUTING.md #4

akirakoyasu opened this issue Dec 28, 2015 · 4 comments

Comments

@akirakoyasu
Copy link
Owner

https://github.com/facebook/hhvm/blob/master/CONTRIBUTING.md

Contributing to HHVM

We'd love to have your help in making HHVM better. Before jumping into the code, please familiarize yourself with our coding conventions. We're also working on a Hacker's Guide to HHVM. It's still very incomplete, but if there's a specific topic you'd like to see addressed sooner rather than later, let us know. For documentation and any other problems, please open an issue, or better yet, fork us and send a pull request. Join us on Freenode in #hhvm for general discussion, or #hhvm-dev for development-oriented discussion.

If you want to help but don't know where to start, try fixing some of the "probably easy" issues; add a test to hphp/test/slow/something_appropriate, and run it with hphp/test/run.

All the open issues tagged PHP5 incompatibility are real issues reported by the community in existing PHP code and frameworks that could use some attention.

Submitting Pull Requests

Before changes can be accepted a Contributor Licensing Agreement must be completed. You will be prompted to accept the CLA when you submit your first pull request. If you prefer a hard copy, you can print the pdf, sign it, scan it, and send it to cla@fb.com.

Please add appropriate test cases as you make changes, and make sure that they pass locally before submitting your pull request; see here for more information. All the tests are run via Phabricator, however testing locally greatly speeds up the process of accepting your changes.

Stable Version Updates

We maintain up to three stable branches at once (the current release plus two LTS branches). To get a fix into one of those branches, first get accepted into master, as described above. Fixes are merged into master and then merged backwards into stable releases as appropriate.

Then, submit another PR against the relevant stable branch(es) cherry-picking your change into that branch, with any changes needed to properly backport. Make sure to explain in the PR summary why the change should be considered for inclusion in the stable branch -- basically, make the case for why the issue the change is fixing is worse than the possible risk of what the change might break (and thus what we will be responsible for debugging, fixing, and maintaining).

Quick Links

@akirakoyasu
Copy link
Owner Author

Contributing to HHVM

We'd love to have your help in making HHVM better. Before jumping into the code, please familiarize yourself with our coding conventions. We're also working on a Hacker's Guide to HHVM. It's still very incomplete, but if there's a specific topic you'd like to see addressed sooner rather than later, let us know. For documentation and any other problems, please open an issue, or better yet, fork us and send a pull request. Join us on Freenode in #hhvm for general discussion, or #hhvm-dev for development-oriented discussion.

If you want to help but don't know where to start, try fixing some of the "probably easy" issues; add a test to hphp/test/slow/something_appropriate, and run it with hphp/test/run.

All the open issues tagged PHP5 incompatibility are real issues reported by the community in existing PHP code and frameworks that could use some attention.

HHVMに貢献する

HHVMをより良くするための手助けを強く求めています。コードに飛び込む前に、私たちのコード規約に習熟してください。また、私たちはHacker's Guide to HHVMに基づいて作業しています。それはまだ完成されていませんが、後でではなくすぐに詳しく参照したいトピックがあれば、私たちに知らせてください。文書化やその他のあらゆる問題について、課題を登録するか、いっそフォークしてプルリクエストを送ってください。一般的な議論にはFreenodeの#hhvmで、あるいは開発にまつわる議論には#hhvm-devで参加してください。

手助けしたいけれどもどこから始めたらよいか分からない場合は、"probably easy"の課題の修正を試してください。hphp/test/slow/something_appropriateにテストを追加してhphp/test/runで実行してください。

"PHP5 incompatibility"のタグが付いた全ての未解決課題は、コミュニティから報告された既存のPHPコードとフレームワークでの実際の課題ですので、注意して取り扱ってください。

@akirakoyasu
Copy link
Owner Author

Submitting Pull Requests

Before changes can be accepted a Contributor Licensing Agreement must be completed. You will be prompted to accept the CLA when you submit your first pull request. If you prefer a hard copy, you can print the pdf, sign it, scan it, and send it to cla@fb.com.

Please add appropriate test cases as you make changes, and make sure that they pass locally before submitting your pull request; see here for more information. All the tests are run via Phabricator, however testing locally greatly speeds up the process of accepting your changes.

プルリクエストを送信する

変更が取り込まれる前に、Contributor Licensing Agreementを完成しなければなりません。最初のプルリクエストを送信する際に、CLAを受諾するよう促されるはずです。ハードコピーが欲しい場合はpdfを印刷し、署名してスキャンしてcla@fb.com宛に送信することもできます。

変更のためには、適切なテストケースを追加して、プルリクエストを送信する前にそれがローカルでパスすることを確認してください。hphp/test/README.mdでより詳しい情報を参照してください。テストは全てPhabricatorで実行されますが、ローカルでテストすることが変更の取り込みプロセスを大いに早めます。

@akirakoyasu
Copy link
Owner Author

Stable Version Updates

We maintain up to three stable branches at once (the current release plus two LTS branches). To get a fix into one of those branches, first get accepted into master, as described above. Fixes are merged into master and then merged backwards into stable releases as appropriate.

Then, submit another PR against the relevant stable branch(es) cherry-picking your change into that branch, with any changes needed to properly backport. Make sure to explain in the PR summary why the change should be considered for inclusion in the stable branch -- basically, make the case for why the issue the change is fixing is worse than the possible risk of what the change might break (and thus what we will be responsible for debugging, fixing, and maintaining).

安定したバージョン更新

私たちは一度に3つまでのstableブランチ(現在のリリースブランチと、LTSブランチ2つ)を保守します。これらのブランチに修正を取り込むために、最初は上記で説明しているようにmasterブランチに取り込みます。修正はmasterブランチにマージされた後、stableブランチに適切に後方マージされていきます。

そして、その変更をcherry-pickして、別のプルリクエストを妥当なstableブランチへ送信してください。適切にバックポートするために必要な変更とともに、です。そのプルリクエストの概要で、その変更をstableブランチに含めるべきだと考えた理由について説明すること忘れないで下さい。 -- 基本的には、その変更が破壊するかもしれないもの(つまり"私たちが"デバッグし、修正し、保守する責任をもつことになる)の潜在的なリスクより、その変更が修正する問題の方に価値がある理由について論証してください。

@akirakoyasu
Copy link
Owner Author

Quick Links

クイックリンク

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant