[Development] Migrating to Bugzilla

[Development] Migrating to Bugzilla

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 591 bytes --]

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

Re: [Development] Migrating to Bugzilla

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

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(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/development

Re: [Development] Migrating to Bugzilla

[Florian Ortmann]

[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]

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(a)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(a)lists.ipfire.org
>> http://lists.ipfire.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/development

Re: [Development] Migrating to Bugzilla

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3642 bytes --]

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(a)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(a)lists.ipfire.org
> >> http://lists.ipfire.org/mailman/listinfo/development
> > 
> > _______________________________________________
> > Development mailing list
> > Development(a)lists.ipfire.org
> > http://lists.ipfire.org/mailman/listinfo/development
> 
> _______________________________________________
> Development mailing list
> Development(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/development