進め方¶
トラッカー「提案」は、報告者が、新機能の提案や、バグではない軽微な変更をパッチを送る場合に使われる。
このトラッカーはパッチを必ず添付しなければならない。 パッチの無い機能要望などは、mikutterでは受け付けていない 。
基本的な流れとしては、
- モデレータが、その提案をmikutterにマージすべきか判断する（分類待ち）
- マージすべきと判断した場合（パッチ適用待ち）
- 修正パッチを試用し、レビューする（レビュー待ち）
- 適切なブランチにmergeする（マージ待ち）
というふうになる。
ステータス「分類待ち」の場合¶
この場合、モデレータがその提案が妥当なものなのか判断し返信する。
パッチを取り込むべきではない場合¶
妥当でないならばその理由を説明し、ステータスを「却下」に変更する。
パッチを取り込むべきか判断できない場合¶
議論をしてもacceptするかrejectするか判断できない場合、または議論の余地がなく、toshi_aがどうするか判断するしかないと考えられる場合、チケットを以下のように更新する。
- ステータス: 「toshi_aの判断待ち」
この場合、 担当者を変更する必要はない 。
このステータスへの遷移は、モデレータの誰か一人でもtoshi_aが判断すべきと考えたら即座に行って良い。
取り込むべきと判断できる場合¶
モデレータがそれを取り込むべきと判断すれば、チケットを以下のように更新する。
- ステータス: 「パッチ適用待ち」
ステータス「パッチ適用待ち」の場合¶
このステータスの時にやるべきことは、単にそのパッチをコミットすることである。したがって、このステータスのチケットはコミッタしか操作することができない。
パッチをコミットする¶
コミッタは、「パッチ適用待ち」のコミットを見たら、いつでもこのパッチをコミットできる。
詳細は ブランチの起点について に従う。
ただし、コミットする時には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
また、コミットの一行目の末尾には、「refs #（チケット番号）」を必ず入れること。これによって自動的にチケットとコミットが関連付けられる。
もしPushしてからrefsの入れ忘れに気づいてしまった場合は、Redmineでそのコミットを開き、「関連するチケット」にそのチケット番号を追加すれば、手動で関連付けることができる。
toshi_a 初音 さんがほぼ3年前に更新 · 12件の履歴