プロジェクト

全般

プロフィール

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

Yuto Tokunaga, 2019-09-30 23:51

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