From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2011-October/008995.html | 145 ++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 zarb-ml/mageia-dev/2011-October/008995.html (limited to 'zarb-ml/mageia-dev/2011-October/008995.html') diff --git a/zarb-ml/mageia-dev/2011-October/008995.html b/zarb-ml/mageia-dev/2011-October/008995.html new file mode 100644 index 000000000..d2b02f50a --- /dev/null +++ b/zarb-ml/mageia-dev/2011-October/008995.html @@ -0,0 +1,145 @@ + + + + [Mageia-dev] Proposal for bug statuses and workflow + + + + + + + + + +

[Mageia-dev] Proposal for bug statuses and workflow

+ Samuel Verschelde + stormi at laposte.net +
+ Wed Oct 19 23:30:05 CEST 2011 +

+
+ +
Here is a workflow proposal for bug reports in bugzilla.
+
+See the flowchart (link below) and the explanations below. Not all statuses 
+will be used in every bug report, but the flowchart more or less gives the 
+standard flow for bugs reported against a stable release of Mageia.
+
+http://stormi.lautre.net/fichiers/mageia/triage.png
+
+NEW: as currently, bugs are set to this status when created
+
+NEW (+ NEEDINFO keyword): more input needed
+
+NEW (+ Triaged keyword): bug report has been triaged by a triager or 
+maintainer, and should have been assigned to the right maintainer (when 
+there's one), but there's no guarantee about this.
+
+ACCEPTED must be set by the maintainer, or a packager who decides to fix the 
+bug for the maintainer. It doesn't mean that the packager is actively working 
+on the fix, but shows that he/she is willing to whenever possible. Setting a 
+bug report to accepted acknowledges that the triager assigned to the right 
+person AND that this person saw that the bug report was assigned to him/her. 
+In case of a bug assigned to a maintainer group (when there will be), setting 
+the status to ACCEPTED means that the group is OK to handle the bug report, 
+but it does not mean that someone from the group is already working on it. See 
+the next status for that.
+
+IN_PROGRESS can be set by the packager who is working on the bug. It is not 
+mandatory, this status can be skipped. However, it is advised to use it to 
+give better feedback to both triagers and bug reporters.
+
+TESTING is set when assigning to QA Team (ideally bugzilla would automatically 
+assign to QA when someone puts the TESTING status in a stable release).
+
+VALIDATED is set by QA team once testing ends. It means that the update can be 
+pushed (replaces the validated_update keyword)
+
+CLOSED replaces RESOLVED, because I think it's nicer for the bug reporter if 
+we "close" bugs rather than consider them "resolved" when the reason for 
+closing is WONT-FIX, DUPLICATE, OLD, etc., statuses that obviously don't match 
+the meaning of "RESOLVED".
+
+ASSIGNED status disappears, because it was ambiguous. UNCONFIRMED disappears, 
+it was unused already.
+
+Here are the proposed Resolutions:
+FIXED
+NOT_A_BUG (replaces INVALID with a more neutral term)
+INSUFFICIENT_DATA (new resolution for bugs closed due to lack of data)
+CANT_FIX (it's too difficult to fix it, or there's a reason why we can't fix it)
+WONT_FIX (we don't *want* to fix it)
+DUPLICATE
+WORKS_FOR_ME
+
+Best regards
+
+Samuel Verschelde
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1