Trac：code reviewプラグイン

Question

tracのインストールのためにコードレビュープラグインを探しています。

私は、これら二つはグーグル

• PeerCodeReview
• CodeReview

の "trac code review" クエリの最上位の結果として、私はPeerCodeReviewプラグインに傾いていました。

私たちのtracのインストール用のプラグインを選択するのに役立つように、これらのプラグインに関する入力をSOコミュニティに要求します。

他のプラグインについて知っていれば、それらについても教えてください。 :)

私はプラグイン

• でのコメント付きコードに注釈を付けるための方法を探しています何。
• 承認/承認外です。そのコードを変更する必要があることを知らせるボタンのようなものです。おそらくバグが作成されます。
• コードレビュー "タスク"を人に割り当てる方法。

最初の機能が必要です（これはすべての点です）。その他はオプションです。私はそのワークフローにぴったり一致するものを得るためにtracをハックすることができます。うまくいけば！ ;）

Answer 1

を見てください。最後に、Review BoardをTracと並行してインストールすることを選択しました。これはTracプラグインではありませんが、優れたツールです。これまでは非常に満足しています。

これには基本的なTracサポートも含まれています。たとえば、バグ修正を見直すと、Tracチケットへの自動リンクが得られます。

Answer 2

私の会社では、TracHacksの "peerreview"プラグインを簡単に見て、とても失望しました。

コードレビュープラグインは、Subversionコミット全体をコードレビューする必要があると仮定するのが当然です。残念ながら、peerreviewプラグインを使用すると、レビューするコード行を手動で特定する必要があります。特定のコミットで行が変更されている可能性があるというヒントも与えられません。つまり、注意深く変更された行を入力しないと、同じ行のコードを何度も再見直すことになります。

他のプラグイン（CodeReviewPlugin）を詳細に確認する機会はありませんでした。

Answer 3

私はPeerCodeReviewがあなたの望むものに適していると思います。

前のポスターは正しいですが、ソースリポジトリを参照して、レビューするコードを選択して注釈を付ける必要があります。チェンジセットについては何も知らない。

これは、コードを積極的に見て問題のあるものを特定している（建築家や鉛のような）人がいれば問題ありません。

変更に関連するすべてのコードを確認したい場合は、うまく機能しません。

あなたがコミットして関連付け、差分を処理し、何かを探しているなら、我々は同じような状況にあったReviewBoard (a DJango app):

Answer 4

私はPeerCodeReviewにも失望しています。特定のリビジョンにコメントを結びつけ、新しいリビジョンをレビュー用に「再提出」すると、古いレビューを閉じて新しいリビジョンを開くことになりますが、すべてのコメントは古いレビューにのみ留まります。したがって、それに対処する新しいソースとともにコメントを表示する簡単な方法はありません。コミット/差分のレビューをサポートしていないため、PeerCodeReviewは私には不適切です。

CodeReviewプラグインはいいです（実際に試していない）が、私はまだ特定の行にコメントする機能が欠けています。

私の使用例は、古典的な "コードレビュー"ではなく、単一のLaTeXドキュメントのレビューではないはずです。これには異なる要件があります。

• コミットが必要でない前に確認します。逆に、「パイプライン」ワークフロー は、審査担当者が空き時間（ ）を持っているときに作成され、ライターがそれらに到着したときに頻繁に後でコミットされます。

• テキストのどの部分がどのリビジョンでレビューされたのかを確認するといいでしょう。
  レビューは通常一度に1つのセクションで行われるため、これは重要ではありません。手動で十分に で十分です。

• 小さな独立したコメントがたくさんあります。各コメントは個別に を追跡する必要があり、コミットのための単一の「承認/拒否」解決策です。

• ほとんどのコメントは、ファイルによく局在しているので、私は、ファイル内の特定の場所に それらを取り付けることができますし、ファイルを編集 あるとき、彼らはその場所を維持する必要が流れをしたいです。このため

右流れに対処するときにコミットフックでそれらを閉じ、各コメントのチケットを開くことであろう。唯一の問題は、ファイル内の特定の行にチケットを結びつける簡単な方法がないため、かなり面倒です。私はソース/差分行にチケットを結びつける最小限のプラグインを書こうと思っています。誰もそのような獣が好きですか？

私が実際にやっているのは、ソース内にTODOのコメントを置いて、それにファンシーなTracインターフェースを使わないことです。バージョン管理では、コメントが編集内容のどこに残っているかを確認します。私はこの後には、それが行った方法を報告して編集します[LaTeXのは、具体的には、私はおそらく視覚的な差分のためにきれいにコメントを表示し、多分latexdiffしtodonotesおよび/またはfixmeパッケージを使用します。のために]

...

ところで、このアプローチはドキュメントに限定されていません。私は集中的なアジャイル開発中にコードをレビューするために多くのチームを使用していました。彼らはレビュープロセスを「パイプライン化」する同様の要望を持っていました。開発を続ける必要がありますが、リリースを行う前にすべての変更をレビューする必要があります。最も難しい部分は、「クリーンな」リビジョンにタグを付けることによってレビューされた、またはレビューされなかったものを追跡することでした。振り返ってみると、が「見直された」ブランチを持っていて、チェリーピッキングがうまくいくでしょう。 （もちろん、ローカライズされていない、建築的な質問はTracのチケットに入れられるか、またはTODOのコメントとして開始され、チケットに移行されます）