バグチケットの進め方 » 履歴 » バージョン 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でそのコミットを開き、「関連するチケット」にそのチケット番号を追加すれば、手動で関連付けることができる。 |