Re: [Development] Migrating to Bugzilla

[Michael Tremer <michael.tremer@ipfire.org>]

[-- 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