mikutter

{{>toc}}

h1. 用語

h2. 報告者

バグを発見し、そのことについてRedmineのチケットに起票した人。

Redmineに登録している全ての人が報告者になりうる。

h2. コミッタ

コミット権限を持っていて、mikutterリポジトリに直接変更を加えられる人。

[[ロール#報告者|報告者]]と同一人物である可能性もあるが、クロスチェックの意味合いも込めて、原則別の人間が行うようにしたほうがいい。

h2. 修正者

バグを修正した人。

原則[[ロール#コミッタ|コミッタ]]のことだが、[[ロール#報告者|報告者]]や第三者が修正パッチを提供していて、それを単純に当てた場合はこの限りではない。

h2. モデレータ

チケットの是非を判断する権限を持った人。[[ロール#コミッタ|コミッタ]]ほど権限は与えられていないが、一般の[[ロール#報告者|報告者]]より高い権限が与えられている。

全ての[[ロール#コミッタ|コミッタ]]はモデレータでもある。

h1. 進め方

トラッカー「バグ」は、[[ロール#報告者|報告者]]がある現象をバグだと考えて報告する場合に使われる。

基本的な流れとしては、

# [[ロール#コミッタ|コミッタ]]が、それは仕様なのかバグなのか判断する（分類待ち）

# バグであると判断した場合、修正パッチを募集する（実装待ち）

# 修正パッチを試用し、レビューする（パッチ適用待ち、レビュー待ち）

# 適切なブランチにmergeする（マージ待ち）

というふうになる。

h2. ステータス「分類待ち」の場合

この場合、[[ロール#モデレータ|モデレータ]]がそれがバグなのか、または意図した挙動なのかを判断し返信する。

意図した挙動であればその理由を説明し、ステータスを「却下」に変更する。

[[ロール#モデレータ|モデレータ]]が実際にバグであると判断すれば、以下の条件に従って次に進める。

h3. 別にバグじゃない場合

明らかに見当違いであったり、議論の末報告された問題はバグではなく、修正する必要がないと判断した場合はステータスを「却下」にする。

他にも、以下のような場合は「却下」となる。

* Twitter関連のバグだったが、TwitterがAPIの提供を止めたなど、修正する意味が無くなった

* 提案には一理あるが、プログラムではなく当初の考え方に問題があり、どちらかといえば機能追加となってしまう場合（この場合はトラッカーを「機能」に変えることもある）

* [[ロール#報告者|報告者]]以外誰も再現できておらず、その後[[ロール#報告者|報告者]]としばらく連絡が取れない場合

h3. 修正パッチがある場合

しばしば、バグ報告にいきなり修正パッチがついている場合がある。この場合、ステータスは「パッチ適用待ち」にする。

この遷移は、報告された問題の存在さえ確認できていれば、パッチの良し悪しに関わらず行って良い。パッチ自体の品質については、あとで判断する。

h3. パッチがない場合

[[ロール#報告者|報告者]]がパッチを添付しない場合は、[[ロール#モデレータ|モデレータ]]はステータスを「実装待ち」にする。

h2. ステータス「実装待ち」の場合

このステータスは、誰かが修正するのを待っている場合、又は修正方法を議論している場合。

h3. コミッタ

[[ロール#コミッタ|コミッタ]]は、このチケットの問題を解決するコミットをすることができる。

くわしいルールについては、 [[ロール#ブランチの起点について|ブランチの起点について]] に従う。

このブランチをPushしたら、チケットのステータスを「レビュー待ち」に変更する。

この時、次のフィールドをそれぞれ以下のようにする。

* *ステータス*: 「レビュー待ち」

* *ブランチ名*: コミットしたブランチ名を入れる。

* *担当者*: （[[ロール#報告者|報告者]]）。この更新をしている本人が[[ロール#報告者|報告者]]だった場合は担当なしにする。

h3. コミッタ以外

[[ロール#コミッタ|コミッタ]]でない人でも修正パッチを添付して注記を追加することができる。この場合は、同時にステータスを「パッチ適用待ち」にする。

h2. ステータス「パッチ適用待ち」の場合

このステータスの時にやるべきことは、単にそのパッチをコミットすることである。したがって、このステータスのチケットは[[ロール#コミッタ|コミッタ]]しか操作することができない。

h3. パッチをコミットする

[[ロール#コミッタ|コミッタ]]は、「パッチ適用待ち」のコミットを見たら、いつでもこのパッチをコミットできる。

詳細は [[ロール#ブランチの起点について|ブランチの起点について]] に従う。

ただし、コミットする時にはgitコマンドの--authorオプションを使って、パッチを作った人をAuthorにすること。

このブランチをPushしたら、チケットのステータスを「レビュー待ち」に変更する。

この時、次のフィールドをそれぞれ以下のようにする。

- *ステータス*: 「レビュー待ち」

- *ブランチ名*: コミットしたブランチ名を入れる。

- *担当者*: （[[ロール#修正者|修正者]]）

h2. ステータス「レビュー待ち」の場合

このステータスになる時、必ずカスタムフィールド「ブランチ名」に、修正がコミットされたブランチが書いてある。

h3. チケットの担当者が設定されてる場合

この場合は、設定された担当者がそのブランチをチェックアウトして動作確認を行う。

結果、このチケットで指摘されているバグが修正されたことが確認できたら、ステータスを「マージ待ち」にする。

* *ステータス*: 「マージ待ち」

* *担当者*: 担当者なし

稀に、正しく意図が伝わっていなかったり別のバグが発生していることもある。そういう時にはチケットのフィールドを以下のように更新する。

* *ステータス*: 「まだダメ」

* *担当者*: このチケットのステータスを「レビュー待ち」に変えた人

* *注記*: どういった不具合が発生しているかを詳細に説明する。UI関連ならスクリーンショットなどを貼ると良い。

h2. ステータス「マージ待ち」の場合

このステータスになったチケットは、全ての修正、確認が終わっている。したがって[[ロール#コミッタ|コミッタ]]はすぐにこれをmergeしてよい。

ただし、mergeするブランチには注意すること。次のルールに従う。

* *developブランチから派生したブランチ* → developブランチにmergeする

* *タグ又はmasterから派生したブランチ* → masterブランチにmergeする

上記のルールに従ってmasterかdevelopにmergeしたら、チケットのフィールド「ブランチ名」のブランチは削除する。

その後、チケットのフィールドを以下のように更新する。

* *ステータス*: 「終了」

また、masterにmergeした場合は、そのmasterを更にdevelopにmergeしてもよい（see: [[リポジトリのブランチ名の規約]]）。逆の、masterをdevelopにmergeするのは、マイナーリリースを行う時なので、toshi_a以外が行ってはならない。

h1. その他

h2. ブランチの起点について

ブランチ名は @topic/(チケット番号)-(適当な説明)@ という書式にする（例: <code>topic/1234-fix-hogehoge</code>）。

また、ブランチを始めるリビジョンも重要になってくる。以下のうちのどれかを選択する。可能な限り上のものを選択すること。

* そのチケットの対象バージョンがサポートされているバージョンなら、最新の版のタグ

* masterのHEAD

* developのHEAD

例えば最新バージョンが1.1.4で、1.2を開発中だとすると:

* チケットの対象バージョンが1.1だった場合、タグ「1.1.4」からブランチを作る。

* 開発終了した1.0が対象バージョンだった場合、タグ「1.1.4」からブランチを作る。

* そのバグが未リリース（まだタグを打たれていないmasterブランチ）の場合、masterブランチのHEADからブランチを作る。

* チケットの対象バージョンが1.2だった場合、developブランチのHEADからブランチを作る。

となる。

また、コミットの一行目の末尾には、「refs #（チケット番号）」を必ず入れること。これによって自動的にチケットとコミットが関連付けられる。

もしPushしてからrefsの入れ忘れに気づいてしまった場合は、Redmineでそのコミットを開き、「関連するチケット」にそのチケット番号を追加すれば、手動で関連付けることができる。