1 |
Hi all, |
2 |
|
3 |
since we're at documenting things, I wonder if we want to discuss and |
4 |
document the bugzilla workflow. |
5 |
|
6 |
For now I tried to handle bugs like Zac did. That is: |
7 |
|
8 |
There always exists a tracker bug, named: |
9 |
"[Tracker] sys-apps/portage-<next version>". |
10 |
|
11 |
This bug is renamed from X.Y.Z to X.Y.Z+1 after a release, until it gets |
12 |
closed when Y changes and a new one is opened. |
13 |
|
14 |
Whenever a commit for a specific bug is made to the git repo, the |
15 |
corresponding bug gets changed in the following ways: |
16 |
* InVCS is added to Keywords |
17 |
* The bug is marked as blocking the tracker for the next version |
18 |
* A comment is added saying: This is fixed in git: <url to commit> |
19 |
(note that the bug stays open) |
20 |
|
21 |
After a release all open bugs blocking the tracker are closed with the |
22 |
comment "This is fixed in <version>.". |
23 |
|
24 |
I like this workflow because it makes it easy to see what has been fixed |
25 |
since the last release. The only thing I have no use for, is this InVCS |
26 |
keyword. I do not know what Zac used it for. Does anyone have a use for it? |
27 |
|
28 |
Another topic is the bug status for open bugs, i.e. CONFIRMED, |
29 |
UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them and |
30 |
haven't found them useful, but Brian suggested to use IN_PROGRESS at |
31 |
times. What are your thoughts? |
32 |
|
33 |
Did I miss something? Any suggestions? |
34 |
|
35 |
Sebastian |