| 1 |
Here's a new version of the workflow that tries to incorporate |
| 2 |
all the comments. |
| 3 |
|
| 4 |
This should go into the DEVELOPING file once everyone agrees. |
| 5 |
|
| 6 |
Bugzilla |
| 7 |
-------- |
| 8 |
|
| 9 |
There always exists a tracker bug, named: |
| 10 |
"[Tracker] sys-apps/portage-<next version>". |
| 11 |
|
| 12 |
This bug is renamed from X.Y.Z to X.Y.Z+1 after a release, until |
| 13 |
it gets closed when Y changes and a new one is opened. |
| 14 |
|
| 15 |
Whenever a commit for a specific bug is made to the git repo, |
| 16 |
the corresponding bug gets changed in the following ways: |
| 17 |
* InVCS is added to Keywords |
| 18 |
* The bug is marked as blocking the tracker for the next version |
| 19 |
* A comment is added saying: This is fixed in git: <url to commit> |
| 20 |
(note that the bug stays open) |
| 21 |
|
| 22 |
After a release all open bugs blocking the tracker are closed |
| 23 |
with the comment "This is fixed in <version>.". |
| 24 |
|
| 25 |
For individual open bugs it is encouraged to set UNCONFIRMED, |
| 26 |
CONFIRMED or IN_PROGESS as appropriate. |
| 27 |
|
| 28 |
There are a number of bugs named "[TRACKER] *" that collect bugs |
| 29 |
for specific topics. Confirmed bugs should be marked as blocking |
| 30 |
these tracker bugs if appropriate. |
| 31 |
|
| 32 |
It is encouraged to set the alias field for frequently used bugs. |
Archives