進め方¶
トラッカー「バグ」は、報告者がある現象をバグだと考えて報告する場合に使われる。
基本的な流れとしては、
- コミッタが、それは仕様なのかバグなのか判断する（分類待ち）
- バグであると判断した場合、修正パッチを募集する（実装待ち）
- 修正パッチを試用し、レビューする（パッチ適用待ち、レビュー待ち）
- 適切なブランチにmergeする（マージ待ち）
というふうになる。
ステータス「分類待ち」の場合¶
この場合、モデレータがそれがバグなのか、または意図した挙動なのかを判断し返信する。
それがバグではないと判断できる場合¶
明らかに見当違いであったり、議論の末報告された問題はバグではなく、修正する必要がないと判断した場合はチケットを以下のように更新する。
- ステータス: 「却下」
他にも、以下のような場合は「却下」となる。
- Twitter関連のバグだったが、TwitterがAPIの提供を止めたなど、修正する意味が無くなった
- 提案には一理あるが、プログラムではなく当初の考え方に問題があり、どちらかといえば機能追加となってしまう場合（この場合は、パッチが添付されていればトラッカーを「提案」に変えることができる）
- 報告者以外誰も再現できておらず、その後報告者としばらく連絡が取れない場合
バグか仕様か判断できない場合¶
議論をしても報告された内容が仕様なのかバグなのか判断できない場合、チケットを以下のように更新する。
- ステータス: 「toshi_aの判断待ち」
この場合、 担当者を変更する必要はない 。
このステータスへの遷移は、モデレータの誰か一人でもtoshi_aが判断すべきと考えたら即座に行って良い。
修正パッチがある場合¶
しばしば、バグ報告にいきなり修正パッチがついている場合がある。この場合、ステータスは「パッチ適用待ち」にする。
この遷移は、報告された問題の存在さえ確認できていれば、パッチの良し悪しに関わらず行って良い。パッチ自体の品質については、あとで判断する。
この遷移を行う人がコミッタである場合、パッチを添付するのではなく、変更を新しいブランチとしてpushし、ブランチ名を書かなければならない。
パッチがない場合¶
報告者がパッチを添付しない場合は、モデレータはステータスを「実装待ち」にする。
ステータス「実装待ち」の場合¶
このステータスは、誰かが修正するのを待っている場合、又は修正方法を議論している場合。
コミッタ¶
コミッタは、このチケットの問題を解決するコミットをすることができる。
くわしいルールについては、 ブランチの起点について に従う。
このブランチをPushしたら、チケットのステータスを「レビュー待ち」に変更する。
この時、次のフィールドをそれぞれ以下のようにする。
コミッタ以外¶
コミッタでない人でも修正パッチを添付して注記を追加することができる。この場合は、同時にステータスを「パッチ適用待ち」にする。
ステータス「パッチ適用待ち」の場合¶
このステータスの時にやるべきことは、単にそのパッチをコミットすることである。したがって、このステータスのチケットはコミッタしか操作することができない。
パッチをコミットする¶
コミッタは、「パッチ適用待ち」のコミットを見たら、いつでもこのパッチをコミットできる。
詳細は リポジトリのブランチ名の規約 に従う。
ただし、コミットする時にはgitコマンドの--authorオプションを使って、パッチを作った人をAuthorにすること。
このブランチをPushしたら、チケットのステータスを「レビュー待ち」に変更する。
この時、次のフィールドをそれぞれ以下のようにする。
- ステータス: 「レビュー待ち」
- ブランチ名: コミットしたブランチ名を入れる。
- 担当者: （修正者）
ステータス「toshi_aの判断待ち」の場合¶
このステータスの場合、toshi_aが「パッチ適用待ち」または「却下」にする。
このステータスになっていても、他のユーザがこのチケットについて意見を注記に書いて良い。
ステータス「レビュー待ち」の場合¶
このステータスになる時、必ずカスタムフィールド「ブランチ名」に、修正がコミットされたブランチが書いてある。
チケットの担当者が設定されてる場合¶
この場合は、設定された担当者がそのブランチをチェックアウトして動作確認を行う。
動作確認した結果、何も疑問がない場合¶
このチケットで指摘されているバグが修正されたことが確認できたら、ステータスを「マージ待ち」にする。
- ステータス: 「マージ待ち」
それ以外の場合¶
修正に問題がある場合や、疑問点がある場合、チケットのフィールドを以下のように更新する。
- ステータス: 「まだダメ」
- 担当者: このチケットのステータスを「レビュー待ち」に変えた人
- 注記: どういった問題が発生しているかを具体的に説明する。UI関連ならスクリーンショットなどを貼ると良い。
この遷移をするのは次のような場合である:
- バグが直っていない
- 直ってはいるが、特定の値を入力すると微妙な挙動をするので、ちゃんと意図して実装したのか一応確認したい
チケットの担当者が設定されていない場合¶
修正者以外のモデレータがそのブランチをチェックアウトして動作確認を行う。
動作確認した結果、何も疑問がない場合¶
このチケットで指摘されているバグが修正されたことが確認できたら、ステータスを「マージ待ち」にする。
- ステータス: 「マージ待ち」
それ以外の場合¶
修正に問題がある場合や、疑問点がある場合、チケットのフィールドを以下のように更新する。
- ステータス: 「まだダメ」
- 担当者: このチケットのステータスを「レビュー待ち」に変えた人
- 注記: どういった問題が発生しているかを具体的に説明する。UI関連ならスクリーンショットなどを貼ると良い。
この遷移をするのは次のような場合である:
- バグが直っていない
- 直ってはいるが、特定の値を入力すると微妙な挙動をするので、ちゃんと意図して実装したのか一応確認したい
ステータス「マージ待ち」の場合¶
このステータスになったチケットは、全ての修正、確認が終わっている。したがってコミッタはすぐにこれをmergeしてよい。
ただし、mergeするブランチには注意すること。次のルールに従う。
- developブランチから派生したブランチ → developブランチにmergeする
- タグ又はmasterから派生したブランチ → masterブランチにmergeする
上記のルールに従ってmasterかdevelopにmergeしたら、チケットのフィールド「ブランチ名」のブランチは削除する。
その後、チケットのフィールドを以下のように更新する。
- ステータス: 「終了」
また、masterにmergeした場合は、そのmasterを更にdevelopにmergeしてもよい（see: リポジトリのブランチ名の規約）。逆の、developをmasterにmergeするのは、マイナーリリースを行う時なので、toshi_a以外が行ってはならない。
その他¶
ブランチの起点について¶
ブランチ名は topic/(チケット番号)-(適当な説明) という書式にする（例: topic/1234-fix-hogehoge）。
また、ブランチを始めるリビジョンも重要になってくる。以下のうちのどれかを選択する。可能な限り上のものを選択すること。
- そのチケットの対象バージョンがサポートされているバージョンなら、最新の版のタグ
- 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でそのコミットを開き、「関連するチケット」にそのチケット番号を追加すれば、手動で関連付けることができる。
toshi_a 初音 さんがほぼ3年前に更新 · 13件の履歴