Hi,
in the process of migrating to Bugzilla, I now disabled all of the old ones.
There has been mantis running but with no data on it and I am not sure if we want to keep that what has been there as a kind of history or just throw it away? Redmine has been disabled as well (some days ago).
All domains redirect to bugzilla, but of course not to any bug reports. Additionally, I created the following URLs that redirect to bugzilla as well because they seem intuitive or just shorter to type.
http://bugs.ipfire.org http://bugz.ipfire.org http://bugtracker.ipfire.org
- Michael
A new status update:
I created a draft for the bug workflow for Bugzilla. You can see it over here http://wiki.ipfire.org/devel/bugzilla/workflow. Please read carefully and see if you understand every state, flag and keyword. If not, we maybe need to enhance the description.
Reasons for that: I was very unhappy with the RESOLVED state, which was very weird in our case. When you have got a bug, hack on it, check in the code, the bug was normally set to RESOLVED which is NOT intuitive for the reporter. Although the code was altered, the fix is not available to test and testing is a part of the development cycle. So a bug is not considered resolved when a developer made a change and is certain this will fix the problem. We need proof.
Instead of changing a bug to RESOLVED, the state is MODIFIED which means that a modification was checked into the source repository. Only if the change gets into the mainline repository, a new package is created by PBS and pushed out to testing repositories for QA. As you can see on that wiki page, the QA process is done and after that a bug is getting into CLOSED state (I cut out the intermediate steps here). Only if a bug reached the CLOSED state, we can be certain that no more action is needed.
I would like to get some feedback from you about the document on the wiki. Maybe someone from the doc team could review the text for spelling errors and stuff like that and the developers read the text carefully.
- Michael
On Thu, 2012-02-02 at 20:27 +0100, Michael Tremer wrote:
Hi,
in the process of migrating to Bugzilla, I now disabled all of the old ones.
There has been mantis running but with no data on it and I am not sure if we want to keep that what has been there as a kind of history or just throw it away? Redmine has been disabled as well (some days ago).
All domains redirect to bugzilla, but of course not to any bug reports. Additionally, I created the following URLs that redirect to bugzilla as well because they seem intuitive or just shorter to type.
http://bugs.ipfire.org http://bugz.ipfire.org http://bugtracker.ipfire.org
- Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Hi Micha, I read above your wiki article. It's easy to understand and you wrote it very good. I think there should be no questions about the status of a bug. I've checked a bit the spelling and changed some words. All in all it's a very good and understanding article.
Greets Florian
On Fri, 03 Feb 2012 17:53:22 +0100, Michael Tremer michael.tremer@ipfire.org wrote:
A new status update:
I created a draft for the bug workflow for Bugzilla. You can see it over here http://wiki.ipfire.org/devel/bugzilla/workflow. Please read carefully and see if you understand every state, flag and keyword. If not, we maybe need to enhance the description.
Reasons for that: I was very unhappy with the RESOLVED state, which was very weird in our case. When you have got a bug, hack on it, check in the code, the bug was normally set to RESOLVED which is NOT intuitive for the reporter. Although the code was altered, the fix is not available to test and testing is a part of the development cycle. So a bug is not considered resolved when a developer made a change and is certain this will fix the problem. We need proof.
Instead of changing a bug to RESOLVED, the state is MODIFIED which means that a modification was checked into the source repository. Only if the change gets into the mainline repository, a new package is created by PBS and pushed out to testing repositories for QA. As you can see on that wiki page, the QA process is done and after that a bug is getting into CLOSED state (I cut out the intermediate steps here). Only if a bug reached the CLOSED state, we can be certain that no more action is needed.
I would like to get some feedback from you about the document on the wiki. Maybe someone from the doc team could review the text for spelling errors and stuff like that and the developers read the text carefully.
- Michael
On Thu, 2012-02-02 at 20:27 +0100, Michael Tremer wrote:
Hi,
in the process of migrating to Bugzilla, I now disabled all of the old ones.
There has been mantis running but with no data on it and I am not sure if we want to keep that what has been there as a kind of history or just throw it away? Redmine has been disabled as well (some days ago).
All domains redirect to bugzilla, but of course not to any bug reports. Additionally, I created the following URLs that redirect to bugzilla as well because they seem intuitive or just shorter to type.
http://bugs.ipfire.org http://bugz.ipfire.org http://bugtracker.ipfire.org
- Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Another update:
I finally imported all components of IPFire 3 to Bugzilla.
I want you to check all of the default assignees and check if you are the default assignee for the components you are maintaining.
The list can be found over here: https://bugzilla.ipfire.org/describecomponents.cgi?product=IPFire
Michael
On Fri, 2012-02-03 at 18:50 +0100, Florian Ortmann wrote:
Hi Micha, I read above your wiki article. It's easy to understand and you wrote it very good. I think there should be no questions about the status of a bug. I've checked a bit the spelling and changed some words. All in all it's a very good and understanding article.
Greets Florian
On Fri, 03 Feb 2012 17:53:22 +0100, Michael Tremer michael.tremer@ipfire.org wrote:
A new status update:
I created a draft for the bug workflow for Bugzilla. You can see it over here http://wiki.ipfire.org/devel/bugzilla/workflow. Please read carefully and see if you understand every state, flag and keyword. If not, we maybe need to enhance the description.
Reasons for that: I was very unhappy with the RESOLVED state, which was very weird in our case. When you have got a bug, hack on it, check in the code, the bug was normally set to RESOLVED which is NOT intuitive for the reporter. Although the code was altered, the fix is not available to test and testing is a part of the development cycle. So a bug is not considered resolved when a developer made a change and is certain this will fix the problem. We need proof.
Instead of changing a bug to RESOLVED, the state is MODIFIED which means that a modification was checked into the source repository. Only if the change gets into the mainline repository, a new package is created by PBS and pushed out to testing repositories for QA. As you can see on that wiki page, the QA process is done and after that a bug is getting into CLOSED state (I cut out the intermediate steps here). Only if a bug reached the CLOSED state, we can be certain that no more action is needed.
I would like to get some feedback from you about the document on the wiki. Maybe someone from the doc team could review the text for spelling errors and stuff like that and the developers read the text carefully.
- Michael
On Thu, 2012-02-02 at 20:27 +0100, Michael Tremer wrote:
Hi,
in the process of migrating to Bugzilla, I now disabled all of the old ones.
There has been mantis running but with no data on it and I am not sure if we want to keep that what has been there as a kind of history or just throw it away? Redmine has been disabled as well (some days ago).
All domains redirect to bugzilla, but of course not to any bug reports. Additionally, I created the following URLs that redirect to bugzilla as well because they seem intuitive or just shorter to type.
http://bugs.ipfire.org http://bugz.ipfire.org http://bugtracker.ipfire.org
- Michael
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
Development mailing list Development@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/development
-
Florian Ortmann -
Michael Tremer