プロジェクト

全般

プロフィール

提案チケットの進め方 » 履歴 » バージョン 9

Yuto Tokunaga, 2019-09-30 23:49

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