* [gentoo-portage-dev] Bugzilla workflow
@ 2014-01-05 22:05 99% Sebastian Luther
0 siblings, 0 replies; 1+ results
From: Sebastian Luther @ 2014-01-05 22:05 UTC (permalink / raw
To: gentoo-portage-dev
Hi all,
since we're at documenting things, I wonder if we want to discuss and
document the bugzilla workflow.
For now I tried to handle bugs like Zac did. That is:
There always exists a tracker bug, named:
"[Tracker] sys-apps/portage-<next version>".
This bug is renamed from X.Y.Z to X.Y.Z+1 after a release, until it gets
closed when Y changes and a new one is opened.
Whenever a commit for a specific bug is made to the git repo, the
corresponding bug gets changed in the following ways:
* InVCS is added to Keywords
* The bug is marked as blocking the tracker for the next version
* A comment is added saying: This is fixed in git: <url to commit>
(note that the bug stays open)
After a release all open bugs blocking the tracker are closed with the
comment "This is fixed in <version>.".
I like this workflow because it makes it easy to see what has been fixed
since the last release. The only thing I have no use for, is this InVCS
keyword. I do not know what Zac used it for. Does anyone have a use for it?
Another topic is the bug status for open bugs, i.e. CONFIRMED,
UNCONFIRMED, IN_PROGRESS. I've never bothered with changing them and
haven't found them useful, but Brian suggested to use IN_PROGRESS at
times. What are your thoughts?
Did I miss something? Any suggestions?
Sebastian
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-01-05 22:05 99% [gentoo-portage-dev] Bugzilla workflow Sebastian Luther
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox