「Tezos開発への貢献方法」の版間の差分

提供: tezos-wiki
移動先: 案内検索
(ページの作成:「= How to contribute = == Introduction == The purpose of this document is to help contributors get started with the Tezos OCaml codebase. == First steps == First, make...」)
 
 
1行目: 1行目:
= How to contribute =
+
=貢献する方法=
  
== Introduction ==
+
==はじめに==
  
The purpose of this document is to help contributors get started with the Tezos OCaml codebase.
+
このドキュメントの目的は、貢献者がTezos OCamlコードベースを使い始めるのを支援することです。
  
== First steps ==
+
==最初のステップ==
  
First, make sure that you are proficient enough in OCaml. The community Website http://www.ocaml.org below gives a few pointer for that. In particular, we use a lot of functors, and a few GADTs in the codebase, so you may want to make sure that you master these advanced concepts.
+
まず、OCamlで十分に熟達していることを確認してください。以下のコミュニティウェブサイトhttp://www.ocaml.orgは、そのためのいくつかの指針を示しています。特に、私たちは多くのファンクタとコードベースのいくつかのGADTを使用していますので、これらの高度な概念をマスターすることをお勧めします。
  
Then, if you don’t know well about the Lwt library, that’s what you want to learn. This library is used extensively throughout the code base, as that’s the one we use to handle concurrency, and Tezos is a very concurrent system. You can use the <code>online documentation &lt;https://ocsigen.org/lwt/3.2.1/manual/manual&gt;</code>'''. The chapter on concurrency of <code>Real World OCaml &lt;https://github.com/dkim/rwo-lwt&gt;</code>''' has also been ported to Lwt.
+
あなたがLwtライブラリについてよく知らないのなら、それはあなたが学びたいものです。このライブラリは、コードベース全体で広く使用されています。これは同時実行性を処理するために使用されるもので、Tezosは非常に並行したシステムです。 <code>オンラインドキュメント<https://ocsigen.org/lwt/3.2.1/manual/manual&gt; </code> '' 'を使用できます。 <code> Real World OCaml <https://github.com/dkim/rwo-lwt&gt; </code> '' 'の並行性に関する章もLwtに移植されています。
  
After that, it is a good idea to read the tutorials for :ref:<code>error_monad&lt;error_monad&gt;</code> and :ref:<code>data_encoding &lt;data_encoding&gt;</code>, two homegrown libraries that we use pervasively.
+
その後、私たちが使用している2つの自家製ライブラリ:ref:<code> error_monad <error_monad> </code>と:ref:<code> data_encoding&lt; data_encoding&gt; </code>のチュートリアルを読むことは、普及する。
  
== Where to start ==
+
==どこから始めるか==
  
While you familiarize yourself with the basics as suggested above, you can have a look at the :ref:<code>software architecture &lt;software_architecture&gt;</code> of Tezos. It will give you the main components and their interactions, and links to the documentations for the various parts.
+
上に示唆したように基本を熟知している間に、Tezosの:ref:<code>ソフトウェアアーキテクチャー&lt; software_architecture&gt; </code>を見ることができます。主なコンポーネントとその相互作用、そしてさまざまなパーツのドキュメントへのリンクを提供します。
  
== Our git workflow ==
+
==私たちのgitワークフロー==
  
First, the repository is https://gitlab.com/tezos/tezos, the github one is just a clone that exists for historical reasons. So if you want to contribute, simply create an account there.
+
まず、リポジトリはhttps://gitlab.com/tezos/tezosです.githubは歴史的な理由から存在するクローンです。だから貢献したいのであれば、アカウントを作成するだけです。
  
Then, there are many ways to use Git, here is ours.
+
次に、Gitを使用する方法はたくさんありますが、ここでは私たちがあります。
  
We use almost only merge requests to push into master. Meaning, nobody should push directly into master. Once a merge request is ready, it is reviewed and approved, we merge it using the <code>--fast-forward</code> option of Git, in order to maintain a linear history without merge patches.
+
ほとんどの場合、マージ要求を使用してマスターにプッシュします。意味は、誰も直接マスターにプッシュする必要はありません。マージリクエストが準備完了したら、それを見直して承認します.Gitの<code> - fast-forward </code>オプションを使ってマージします。マージパッチなしで線形履歴を維持します。
  
For that to work, it means that merge requests must be direct suffixes of the master branch. So whenever <code>origin/master</code> changes, you have to rebase your branch on it, so that you patches always sit on top of master. When that happens, you may have to edit your patches during the rebase, and then use <code>push -f</code> in your branch to rewrite the history.
+
これが機能するには、マージリクエストがマスターブランチの直接サフィックスでなければならないということです。したがって、<code> origin / master </code>が変更されたときはいつでも、ブランチをブランチにリベースして、パッチが常にマスターの上に置かれるようにする必要があります。これが起こると、リベース中にパッチを編集し、ブランチの<code> push -f </code>を使って履歴を書き直す必要があります。
  
We also enforce a few hygiene rules, so make sure your MR respects them:
+
また、いくつかの衛生ルールを適用していますので、MRがそれらを尊重していることを確認してください:
  
* Prefer small atomic commits over a large one that do many things.
+
*小さな原子は、多くのことをする大きな原子よりも優先します。
* Don’t mix refactoring and new features.
+
*リファクタリングと新機能を混在させないでください。
* Never mix reindentation, whitespace deletion, or other style changes with actual code changes.
+
*再インデント、空白の削除、または他のスタイルの変更を実際のコード変更と混同しないでください。
* Try as much as possible to make every patch compile, not only the last.
+
*最後のパッチだけでなく、すべてのパッチをコンパイルするために可能な限り試してください。
* If you add new functions into a documented interface, don’t forget to extend the documentation for your addition.
+
*ドキュメント化されたインターフェイスに新しい機能を追加する場合は、ドキュメントを拡張することを忘れないでください。
* For parts whose specification is in the repository (e.g.?Michelson), make sure to keep it in sync with the implementation.
+
*仕様がリポジトリにある部品(たとえば、Michelson)の場合は、実装と同期させてください。
* Try and mimic the style of commit messages, and for non trivial commits, add an extended commit message.
+
*コミットメッセージのスタイルを模倣してみてください。単純なコミットでは、拡張コミットメッセージを追加してください。
  
As per the hygiene of MRs themselves:
+
MR自身の衛生状態に応じて:
  
* Give appropriate titles to the MRs, and when non trivial add a detailed motivated explanation.
+
* MRに適切なタイトルをつけてください。自明ではない場合、詳細な動機付けされた説明を追加してください。
* Give meaningful and consistent names to branches.
+
*ブランチに意味のある一貫した名前を付ける。
* Don’t forget to put a <code>WIP:</code> flag when it is a work in progress
+
*進行中の作業中に<code> WIP:</code>フラグを置くことを忘れないでください
  
Some extra CI tests are only done on demand for branches other that master. You can (should) activate these tests by including keywords in the branch name.
+
いくつかの追加のCIテストは、マスタ以外のブランチに対してオンデマンドでのみ実行されます。ブランチ名にキーワードを含めることで、これらのテストをアクティブにすることができます。
 
+
* MRがOPAMのパッケージングに影響する場合は、支店名に<code> opam </code>を使用してください。
* If your MR impacts OPAM packaging, use <code>opam</code> in the branch name.
+
* MRがドキュメントを更新する場合は、ブランチ名に<code> doc </code>を使用してください。
* If your MR updates documentation, use <code>doc</code> in the branch name.
 

2018年5月30日 (水) 23:58時点における最新版

貢献する方法[編集]

はじめに[編集]

このドキュメントの目的は、貢献者がTezos OCamlコードベースを使い始めるのを支援することです。

最初のステップ[編集]

まず、OCamlで十分に熟達していることを確認してください。以下のコミュニティウェブサイトhttp://www.ocaml.orgは、そのためのいくつかの指針を示しています。特に、私たちは多くのファンクタとコードベースのいくつかのGADTを使用していますので、これらの高度な概念をマスターすることをお勧めします。

あなたがLwtライブラリについてよく知らないのなら、それはあなたが学びたいものです。このライブラリは、コードベース全体で広く使用されています。これは同時実行性を処理するために使用されるもので、Tezosは非常に並行したシステムです。 オンラインドキュメント<https://ocsigen.org/lwt/3.2.1/manual/manual> 'を使用できます。 Real World OCaml <https://github.com/dkim/rwo-lwt> 'の並行性に関する章もLwtに移植されています。

その後、私たちが使用している2つの自家製ライブラリ:ref: error_monad <error_monad> と:ref: data_encoding&lt; data_encoding&gt; のチュートリアルを読むことは、普及する。

どこから始めるか[編集]

上に示唆したように基本を熟知している間に、Tezosの:ref:ソフトウェアアーキテクチャー&lt; software_architecture&gt; を見ることができます。主なコンポーネントとその相互作用、そしてさまざまなパーツのドキュメントへのリンクを提供します。

私たちのgitワークフロー[編集]

まず、リポジトリはhttps://gitlab.com/tezos/tezosです.githubは歴史的な理由から存在するクローンです。だから貢献したいのであれば、アカウントを作成するだけです。

次に、Gitを使用する方法はたくさんありますが、ここでは私たちがあります。

ほとんどの場合、マージ要求を使用してマスターにプッシュします。意味は、誰も直接マスターにプッシュする必要はありません。マージリクエストが準備完了したら、それを見直して承認します.Gitの - fast-forward オプションを使ってマージします。マージパッチなしで線形履歴を維持します。

これが機能するには、マージリクエストがマスターブランチの直接サフィックスでなければならないということです。したがって、 origin / master が変更されたときはいつでも、ブランチをブランチにリベースして、パッチが常にマスターの上に置かれるようにする必要があります。これが起こると、リベース中にパッチを編集し、ブランチの push -f を使って履歴を書き直す必要があります。

また、いくつかの衛生ルールを適用していますので、MRがそれらを尊重していることを確認してください:

  • 小さな原子は、多くのことをする大きな原子よりも優先します。
  • リファクタリングと新機能を混在させないでください。
  • 再インデント、空白の削除、または他のスタイルの変更を実際のコード変更と混同しないでください。
  • 最後のパッチだけでなく、すべてのパッチをコンパイルするために可能な限り試してください。
  • ドキュメント化されたインターフェイスに新しい機能を追加する場合は、ドキュメントを拡張することを忘れないでください。
  • 仕様がリポジトリにある部品(たとえば、Michelson)の場合は、実装と同期させてください。
  • コミットメッセージのスタイルを模倣してみてください。単純なコミットでは、拡張コミットメッセージを追加してください。

MR自身の衛生状態に応じて:

  • MRに適切なタイトルをつけてください。自明ではない場合、詳細な動機付けされた説明を追加してください。
  • ブランチに意味のある一貫した名前を付ける。
  • 進行中の作業中に WIP:フラグを置くことを忘れないでください

いくつかの追加のCIテストは、マスタ以外のブランチに対してオンデマンドでのみ実行されます。ブランチ名にキーワードを含めることで、これらのテストをアクティブにすることができます。

  • MRがOPAMのパッケージングに影響する場合は、支店名に opam を使用してください。
  • MRがドキュメントを更新する場合は、ブランチ名に doc を使用してください。