systemdの CONTRIBUTING.md を訳してみた

systemdのリリース方針について知りたかったので[CONTRIBUTING.md](https://github.com/systemd/systemd/blob/master/docs/CONTRIBUTING.md)を訳してみた。
結論から言うと、「systemdは最新バージョンとその1個前のバージョン以外の古いバージョンの問題は、採用してるディストリビューションの側でパッチ当てたりしてね」ってこと以外、リリースに関することは何も書いてなかった。
自分用のメモとして残しておきます。なにか間違ってたら教えてください。

# Contributing - 貢献のガイドライン

> We welcome contributions from everyone. 

私たちは皆からの貢献を歓迎します。

> However, please follow the following guidelines when posting a GitHub Pull Request or filing a GitHub Issue on the systemd project:

ただし、GitHubプルリクエストを送信する場合や、systemdプロジェクトでGitHub issueを提出する場合は、次のガイドラインに従ってください。

## Filing Issues - Issueの提出

> * We use GitHub Issues **exclusively** for tracking **bugs** and **feature** **requests** of systemd. If you are looking for help, please contact our [mailing list](https://lists.freedesktop.org/mailman/listinfo/systemd-devel) instead.

私たちはGitHub Issuesをsystemdの**バグ**や**機能リクエスト**の追跡**専用**に使用しています。
ヘルプをお探しの場合は、代わりに[メーリングリスト](https://lists.freedesktop.org/mailman/listinfo/systemd-devel)にお問い合わせください。

> * We only track bugs in the **two** **most** **recently** **released** **versions** of systemd in the GitHub Issue tracker. If you are using an older version of systemd, please contact your distribution's bug tracker instead.

私達はGitHub Issue trackerで**最近リリースされた2つのバージョンの**systemdのバグだけを追跡します。
古いバージョンのsystemdを使用している場合は、代わりにディストリビューションのバグトラッカーに連絡してください。

> * When filing an issue, specify the **systemd** **version** you are experiencing the issue with. Also, indicate which **distribution** you are using.

問題を提出するときは、問題が発生している**systemdのバージョン**を明示してください。
また、どの**ディストリビューション**を使用しているかも明示してください。

> * Please include an explanation how to reproduce the issue you are pointing out.

あなたが指摘している問題を再現する方法を添えてください。


> Following these guidelines makes it easier for us to process your issue, and ensures we won't close your issue right-away for being misfiled.

下記に述べるガイドラインに従うと、私達はあなたのissueを処理するのがより簡単になり、誤った振り分けによってあなたのissueがただちにcloseされることを防ぐこともできます。

### Older downstream versions - 古いダウンストリームバージョン

> For older versions that are still supported by your distribution please use respective downstream tracker:

あなたのディストリビューションで引き続きサポートされている古いバージョンの場合は、それぞれのダウンストリームトラッカーを使用してください

> * **Fedora** - [bugzilla](https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=systemd)

> * **RHEL-7/CentOS-7** - [bugzilla](https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=systemd) or [systemd-rhel github](https://github.com/lnykryn/systemd-rhel/issues)

> * **Debian** - [bugs.debian.org](https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=systemd)

## Security vulnerability reports - セキュリティ脆弱性レポート

> If you discover a security vulnerability, we'd appreciate a non-public disclosure.

セキュリティ上の脆弱性を発見した場合は、非公開で報告していただけると助かります。

> The issue tracker and mailing list listed above are fully public.

上記の問題追跡ツールとメーリングリストは完全に公開されています。

> If you need to reach systemd developers in a non-public way, report the issue in one of the "big" distributions using systemd: [Fedora](https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=systemd) (be sure to check "Security Sensitive Bug" under "Show Advanced Fields"), [Ubuntu](https://launchpad.net/ubuntu/+source/systemd/+filebug) (be sure to change "This bug contains information that is" from "Public" to "Private Security"), or [Debian](mailto:security@debian.org).

あなたが非公開の方法でsystemd開発者に連絡する必要がある場合は、Fedora, Ubuntu, Debianなどの、systemdを使っている"大きな"ディストリビューションのどれかに問題を報告してください。

> Various systemd developers are active distribution maintainers and will propagate the information about the bug to other parties.

さまざまなsystemd開発者がアクティブなディストリビューションのメンテナであり、バグに関する情報を他のパーティに伝えます。


## Posting Pull Requests - プルリクエストを送る

> * Make sure to post PRs only relative to a very recent git master.

ごく最近のmasterレポジトリ（？）に関連するプルリクエストだけを投稿するようにしてください。

> * Follow our [Coding Style](CODING_STYLE.md) when contributing code. This is a requirement for all code we merge.

コードを提供する際には、[コーディングスタイル](CODING_STYLE.md)に従ってください。 これは、マージするすべてのコードの要件です。

> * Please make sure to test your change before submitting the PR. See the [Hacking guide](HACKING.md) for details on how to do this.

PRを提出する前に、変更をテストしてください。 これを行う方法の詳細については、[ハッキングガイド](HACKING.md)を参照してください。

> * Make sure to run the test suite locally, before posting your PR. We use a CI system, meaning we don't even look at your PR, if the build and tests don't pass.

PRを公開する前に、テストスイートをローカルで実行してください。
私たちはCIシステムを使用しています。つまり、ビルドとテストが合格しなければ、あなたのPRを見ていません。

> * If you need to update the code in an existing PR, force-push into the same branch, overriding old commits with new versions.

既存のPRのコードを更新する必要がある場合は、同じブランチに強制的にプッシュし、古いコミットを新しいバージョンで上書きしてください。

> * After you have pushed a new version, add a comment about the new version (no notification is sent just for the commits, so it's easy to miss the update without an explicit comment).

新しいバージョンをプッシュした後は、新しいバージョンについてのコメントを追加します（コミットだけでは通知は送られないので、明示的なコメントなしでは容易にアップデートを見逃します）。

> If you are a member of the systemd project on GitHub, remove the `reviewed/needs-rework` label.

もしあなたがGitHub上のsystemdプロジェクトのメンバーなら、`reviewed/needs-rework` ラベルを取り除いてください。

## Final Words - 最後に

> We'd like to apologize in advance if we are not able to process and reply to your issue or PR right-away. We have a lot of work to do, but we are trying our best!

あなたの問題やPRに即座に対応できない場合があることを、事前におことわりさせてください。 私たちには多くの仕事がありますが、最善を尽くしています！

> Thank you very much for your contributions!

貢献いただきありがとうございます！