プロジェクト

全般

プロフィール

バグチケットの進め方 » 履歴 » バージョン 3

toshi_a 初音, 2018-06-30 21:14

1 1 toshi_a 初音
{{>toc}}
2
3
h1. 進め方
4
5 2 toshi_a 初音
トラッカー「バグ」は、[[ロール#報告者|報告者]]がある現象をバグだと考えて報告する場合に使われる。
6 1 toshi_a 初音
7
基本的な流れとしては、
8
9 2 toshi_a 初音
# [[ロール#コミッタ|コミッタ]]が、それは仕様なのかバグなのか判断する(分類待ち)
10 1 toshi_a 初音
# バグであると判断した場合、修正パッチを募集する(実装待ち)
11
# 修正パッチを試用し、レビューする(パッチ適用待ち、レビュー待ち)
12
# 適切なブランチにmergeする(マージ待ち)
13
14
というふうになる。
15
16
h2. ステータス「分類待ち」の場合
17
18 2 toshi_a 初音
この場合、[[ロール#モデレータ|モデレータ]]がそれがバグなのか、または意図した挙動なのかを判断し返信する。
19 1 toshi_a 初音
20
意図した挙動であればその理由を説明し、ステータスを「却下」に変更する。
21 2 toshi_a 初音
[[ロール#モデレータ|モデレータ]]が実際にバグであると判断すれば、以下の条件に従って次に進める。
22 1 toshi_a 初音
23
h3. 別にバグじゃない場合
24
25
明らかに見当違いであったり、議論の末報告された問題はバグではなく、修正する必要がないと判断した場合はステータスを「却下」にする。
26
27
他にも、以下のような場合は「却下」となる。
28
29
* Twitter関連のバグだったが、TwitterがAPIの提供を止めたなど、修正する意味が無くなった
30
* 提案には一理あるが、プログラムではなく当初の考え方に問題があり、どちらかといえば機能追加となってしまう場合(この場合はトラッカーを「機能」に変えることもある)
31 2 toshi_a 初音
* [[ロール#報告者|報告者]]以外誰も再現できておらず、その後[[ロール#報告者|報告者]]としばらく連絡が取れない場合
32 1 toshi_a 初音
33
h3. 修正パッチがある場合
34
35
しばしば、バグ報告にいきなり修正パッチがついている場合がある。この場合、ステータスは「パッチ適用待ち」にする。
36
37
この遷移は、報告された問題の存在さえ確認できていれば、パッチの良し悪しに関わらず行って良い。パッチ自体の品質については、あとで判断する。
38
39
h3. パッチがない場合
40
41 2 toshi_a 初音
[[ロール#報告者|報告者]]がパッチを添付しない場合は、[[ロール#モデレータ|モデレータ]]はステータスを「実装待ち」にする。
42 1 toshi_a 初音
43
h2. ステータス「実装待ち」の場合
44
45
このステータスは、誰かが修正するのを待っている場合、又は修正方法を議論している場合。
46
47
h3. コミッタ
48
49 2 toshi_a 初音
[[ロール#コミッタ|コミッタ]]は、このチケットの問題を解決するコミットをすることができる。
50 1 toshi_a 初音
51 2 toshi_a 初音
くわしいルールについては、 [[ロール#ブランチの起点について|ブランチの起点について]] に従う。
52 1 toshi_a 初音
53
このブランチをPushしたら、チケットのステータスを「レビュー待ち」に変更する。
54
55
この時、次のフィールドをそれぞれ以下のようにする。
56
57
* *ステータス*: 「レビュー待ち」
58
* *ブランチ名*: コミットしたブランチ名を入れる。
59 2 toshi_a 初音
* *担当者*: ([[ロール#報告者|報告者]])。この更新をしている本人が[[ロール#報告者|報告者]]だった場合は担当なしにする。
60 1 toshi_a 初音
61
h3. コミッタ以外
62
63 2 toshi_a 初音
[[ロール#コミッタ|コミッタ]]でない人でも修正パッチを添付して注記を追加することができる。この場合は、同時にステータスを「パッチ適用待ち」にする。
64 1 toshi_a 初音
65
h2. ステータス「パッチ適用待ち」の場合
66
67 2 toshi_a 初音
このステータスの時にやるべきことは、単にそのパッチをコミットすることである。したがって、このステータスのチケットは[[ロール#コミッタ|コミッタ]]しか操作することができない。
68 1 toshi_a 初音
69
h3. パッチをコミットする
70
71 2 toshi_a 初音
[[ロール#コミッタ|コミッタ]]は、「パッチ適用待ち」のコミットを見たら、いつでもこのパッチをコミットできる。
72 1 toshi_a 初音
73 2 toshi_a 初音
詳細は [[ロール#ブランチの起点について|ブランチの起点について]] に従う。
74 1 toshi_a 初音
75
ただし、コミットする時にはgitコマンドの--authorオプションを使って、パッチを作った人をAuthorにすること。
76
77
このブランチをPushしたら、チケットのステータスを「レビュー待ち」に変更する。
78
79
この時、次のフィールドをそれぞれ以下のようにする。
80
81
- *ステータス*: 「レビュー待ち」
82
- *ブランチ名*: コミットしたブランチ名を入れる。
83 2 toshi_a 初音
- *担当者*: ([[ロール#修正者|修正者]])
84 1 toshi_a 初音
85
h2. ステータス「レビュー待ち」の場合
86
87
このステータスになる時、必ずカスタムフィールド「ブランチ名」に、修正がコミットされたブランチが書いてある。
88
89
h3. チケットの担当者が設定されてる場合
90
91
この場合は、設定された担当者がそのブランチをチェックアウトして動作確認を行う。
92
93
結果、このチケットで指摘されているバグが修正されたことが確認できたら、ステータスを「マージ待ち」にする。
94
95
* *ステータス*: 「マージ待ち」
96
* *担当者*: 担当者なし
97
98
稀に、正しく意図が伝わっていなかったり別のバグが発生していることもある。そういう時にはチケットのフィールドを以下のように更新する。
99
100
* *ステータス*: 「まだダメ」
101
* *担当者*: このチケットのステータスを「レビュー待ち」に変えた人
102
* *注記*: どういった不具合が発生しているかを詳細に説明する。UI関連ならスクリーンショットなどを貼ると良い。
103
104
h2. ステータス「マージ待ち」の場合
105
106 2 toshi_a 初音
このステータスになったチケットは、全ての修正、確認が終わっている。したがって[[ロール#コミッタ|コミッタ]]はすぐにこれをmergeしてよい。
107 1 toshi_a 初音
108
ただし、mergeするブランチには注意すること。次のルールに従う。
109
110
* *developブランチから派生したブランチ* → developブランチにmergeする
111
* *タグ又はmasterから派生したブランチ* → masterブランチにmergeする
112
113
上記のルールに従ってmasterかdevelopにmergeしたら、チケットのフィールド「ブランチ名」のブランチは削除する。
114
115
その後、チケットのフィールドを以下のように更新する。
116
117
* *ステータス*: 「終了」
118
119
また、masterにmergeした場合は、そのmasterを更にdevelopにmergeしてもよい(see: [[リポジトリのブランチ名の規約]])。逆の、masterをdevelopにmergeするのは、マイナーリリースを行う時なので、toshi_a以外が行ってはならない。
120
121
h1. その他
122
123
h2. ブランチの起点について
124
125
ブランチ名は @topic/(チケット番号)-(適当な説明)@ という書式にする(例: <code>topic/1234-fix-hogehoge</code>)。
126
127
また、ブランチを始めるリビジョンも重要になってくる。以下のうちのどれかを選択する。可能な限り上のものを選択すること。
128
129
* そのチケットの対象バージョンがサポートされているバージョンなら、最新の版のタグ
130
* masterのHEAD
131
* developのHEAD
132
133
例えば最新バージョンが1.1.4で、1.2を開発中だとすると:
134
135
* チケットの対象バージョンが1.1だった場合、タグ「1.1.4」からブランチを作る。
136
* 開発終了した1.0が対象バージョンだった場合、タグ「1.1.4」からブランチを作る。
137
* そのバグが未リリース(まだタグを打たれていないmasterブランチ)の場合、masterブランチのHEADからブランチを作る。
138
* チケットの対象バージョンが1.2だった場合、developブランチのHEADからブランチを作る。
139
140
となる。
141
142
また、コミットの一行目の末尾には、「refs #(チケット番号)」を必ず入れること。これによって自動的にチケットとコミットが関連付けられる。
143
144
もしPushしてからrefsの入れ忘れに気づいてしまった場合は、Redmineでそのコミットを開き、「関連するチケット」にそのチケット番号を追加すれば、手動で関連付けることができる。