Bugzilla - New Default Status Workflow

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bugzilla - New Default Status Workflow

Christian Ruppert-2
Hey guys,

in bugzilla-4.x they did change the "Status Workflow"[1].

<snip>
This will convert the status of all bugs using the following
system:

  "NEW" will become "CONFIRMED"
  "ASSIGNED" will become "IN_PROGRESS"
  "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
removed)
  "CLOSED" will become "VERIFIED" (and the "CLOSED" status will be removed)

This change will be immediate. The history of each bug will also be changed
so that it appears that these statuses were always in existence.

Emails will not be sent for the change.
</snip>

We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org.
So, do we want the new workflow or do we want to keep the old?

[1]
http://www.bugzilla.org/releases/4.0/release-notes.html#v40_feat_workflow

--
Regards,
Christian Ruppert
Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure
member
Fingerprint: EEB1 C341 7C84 B274 6C59  F243 5EAB 0C62 B427 ABC8


signature.asc (566 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Petteri Räty-2
On 03/06/2011 02:22 PM, Christian Ruppert wrote:
> Hey guys,
>
> in bugzilla-4.x they did change the "Status Workflow"[1].
>
> <snip>
> This will convert the status of all bugs using the following
> system:
>

>   "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
> removed)

We would be loosing information here (at least you would need to go
looking at bug history to find it). Would it be possible to have the new
workflow + REOPENED? Would other statuses continue to exist like before?

Regards,
Petteri


signature.asc (918 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Nirbheek Chauhan-2
In reply to this post by Christian Ruppert-2
On Sun, Mar 6, 2011 at 5:52 PM, Christian Ruppert <[hidden email]> wrote:
> Hey guys,
>
> in bugzilla-4.x they did change the "Status Workflow"[1].
>
[snip]
>
> We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org.
> So, do we want the new workflow or do we want to keep the old?
>

I'm not attached to the names we use for the various bug statuses. I
would suggest that we follow the path that makes things easiest for
future maintenance and upgrades.

As for the removal of REOPENED, I guess that information will still be
visible via the "bug history" button? It shouldn't be a problem then.

--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Brian Harring-2
In reply to this post by Christian Ruppert-2
On Sun, Mar 06, 2011 at 01:22:09PM +0100, Christian Ruppert wrote:
> Hey guys,
>
> in bugzilla-4.x they did change the "Status Workflow"[1].
>
> <snip>
> This will convert the status of all bugs using the following
> system:
>
>   "NEW" will become "CONFIRMED"

This seems mildly insane; sure you didn't mean UNCONFIRMED?


>   "ASSIGNED" will become "IN_PROGRESS"
>   "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
> removed)

Similarly weird.


>   "CLOSED" will become "VERIFIED" (and the "CLOSED" status will be removed)

VERIFIED != CLOSED; CLOSED means "this issue should be fixed",
VERIFIED means "this issue is confirmed fixed by whatever qa/testing
in use"- specifically beyond the developer's testing.


> We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org.
> So, do we want the new workflow or do we want to keep the old?

The new is more orientated towards bugzilla workflow's that have
actual secondary validation of a change- developer fixes it, closes
it, QA marks it verified, that sort of thing.

That doesn't really fit our flow all that much, as such we really
shouldn't be taking their defaults without tweaking it a bit.

~brian

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Christian Ruppert-2
In reply to this post by Petteri Räty-2
On 03/06/2011 01:45 PM, Petteri Räty wrote:

> On 03/06/2011 02:22 PM, Christian Ruppert wrote:
>> Hey guys,
>>
>> in bugzilla-4.x they did change the "Status Workflow"[1].
>>
>> <snip>
>> This will convert the status of all bugs using the following
>> system:
>>
>
>>   "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will be
>> removed)
>
> We would be loosing information here (at least you would need to go
> looking at bug history to find it). Would it be possible to have the new
> workflow + REOPENED? Would other statuses continue to exist like before?
>
> Regards,
> Petteri
>
Yes. Yes.

--
Regards,
Christian Ruppert
Role: Gentoo Linux developer, Bugzilla administrator and Infrastructure
member
Fingerprint: EEB1 C341 7C84 B274 6C59  F243 5EAB 0C62 B427 ABC8


signature.asc (566 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Christian Faulhammer-6
In reply to this post by Christian Ruppert-2
Hi,

Christian Ruppert <[hidden email]>:
> We're almost done with the preparation of bugzilla-4.x for
> bugs.gentoo.org. So, do we want the new workflow or do we want to
> keep the old?

 New one, reopened is a bit pointless information on first glance.
 History tells enough.

V-Li

--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Ulrich Mueller-2
In reply to this post by Christian Ruppert-2
>>>>> On Sun, 6 Mar 2011, Christian Ruppert wrote:

> This will convert the status of all bugs using the following
> system:

>   "NEW" will become "CONFIRMED"

Weird. How can a newly added bug be "CONFIRMED", unless someone has
taken some action to confirm it?

> This change will be immediate. The history of each bug will also be
> changed so that it appears that these statuses were always in
> existence.

So all bugs currently marked as "NEW" or "REOPENED" will change their
status to "CONFIRMED"? That doesn't look right to me. Would that
status change be visible in the bug's history?

> So, do we want the new workflow or do we want to keep the old?

If the new workflow implies such status changes on existing bugs, then
keep the old one please.

Ulrich

Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Nirbheek Chauhan-2
On Sun, Mar 6, 2011 at 7:09 PM, Ulrich Mueller <[hidden email]> wrote:

>>>>>> On Sun, 6 Mar 2011, Christian Ruppert wrote:
>
>> This will convert the status of all bugs using the following
>> system:
>
>>   "NEW" will become "CONFIRMED"
>
> Weird. How can a newly added bug be "CONFIRMED", unless someone has
> taken some action to confirm it?
>
>> This change will be immediate. The history of each bug will also be
>> changed so that it appears that these statuses were always in
>> existence.
>
> So all bugs currently marked as "NEW" or "REOPENED" will change their
> status to "CONFIRMED"? That doesn't look right to me. Would that
> status change be visible in the bug's history?
>
>> So, do we want the new workflow or do we want to keep the old?
>
> If the new workflow implies such status changes on existing bugs, then
> keep the old one please.
>

The link to the docs which idl0r gave says that it's optional to
convert existing status changes. They gave a perl script to do the
conversion.


--
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Paweł Hajdan, Jr.
In reply to this post by Christian Ruppert-2
On 3/6/11 1:22 PM, Christian Ruppert wrote:
> We're almost done with the preparation of bugzilla-4.x for bugs.gentoo.org.
> So, do we want the new workflow or do we want to keep the old?

I like the new workflow more, mostly because of simplicity. This is also
closer to what code.google.com uses, and my experience with it was very
positive.

Before we start arguing for and against various details, let's ask one
simple question - are we actually using all those CLOSED and VERIFIED
statuses, and what does it change that a bug is REOPENED vs. NEW.

Now one of the issues I can indeed understand is the CONFIRMED status
vs. UNCONFIRMED. Still, I'm not sure whether we use UNCONFIRMED so much.
Anyway, it should be possible to add UNCONFIRMED on top of the new
workflow, right?

Paweł Hajdan, Jr.


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Paweł Hajdan, Jr.
In reply to this post by Brian Harring-2
On 3/6/11 1:50 PM, Brian Harring wrote:
>>   "NEW" will become "CONFIRMED"
>
> This seems mildly insane; sure you didn't mean UNCONFIRMED?

I don't understand that concern. There is UNCONFIRMED and NEW, now you'd
get UNCONFIRMED and CONFIRMED. It seems to me it's just NEW with a
different name, and UNCONFIRMED would still be there:

<http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/>

I'm in favor of the new workflow.

Paweł Hajdan, Jr.


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Michał Górny-5
In reply to this post by Christian Ruppert-2
On Sun, 06 Mar 2011 13:22:09 +0100
Christian Ruppert <[hidden email]> wrote:

>   "NEW" will become "CONFIRMED"
>   "REOPENED" will become "CONFIRMED" (and the "REOPENED" status will
> be removed)

I'd say, both to UNCONFIRMED. Before, we used to set 'NEW' for newly-
added bugs and didn't use UNCONFIRMED often. Right now, it seems
logical to use UNCONFIRMED for the new bugs and let devs (re-)confirm
them as necessary.

I think it might be even a good idea to limit the possibility
of setting 'CONFIRMED' to devs. Otherwise, I see users bumping each
of their bugs to 'CONFIRMED' immediately.

> We're almost done with the preparation of bugzilla-4.x for
> bugs.gentoo.org. So, do we want the new workflow or do we want to
> keep the old?

New one. Simpler is better.

--
Best regards,
Michał Górny

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Brian Harring-2
In reply to this post by Paweł Hajdan, Jr.
On Mon, Mar 07, 2011 at 08:24:46AM +0100, "Paweee Hajdan, Jr." wrote:

> On 3/6/11 1:50 PM, Brian Harring wrote:
> >>   "NEW" will become "CONFIRMED"
> >
> > This seems mildly insane; sure you didn't mean UNCONFIRMED?
>
> I don't understand that concern. There is UNCONFIRMED and NEW, now you'd
> get UNCONFIRMED and CONFIRMED. It seems to me it's just NEW with a
> different name, and UNCONFIRMED would still be there:
>
> <http://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/>
Re-read what he stated- it'll convert all existing NEW bugs to
CONFIRMED upon migration.  There's a fair number of bugs that are in a
NEW state, decent number that have sat for a long while too.  Those
bugs aren't 'confirmed'- just like with the new work flow where the
dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip
the current bugs from UNCONFIRMED to CONFIRMED rather than just
marking everything as CONFIRMED.

~harring

attachment0 (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Duncan-42
In reply to this post by Michał Górny-5
Michał Górny posted on Mon, 07 Mar 2011 09:34:55 +0100 as excerpted:

> I'd say, both to UNCONFIRMED. Before, we used to set 'NEW' for newly-
> added bugs and didn't use UNCONFIRMED often. Right now, it seems logical
> to use UNCONFIRMED for the new bugs and let devs (re-)confirm them as
> necessary.

I've wondered about that choice in the past, but tended to simply leave it
at the default (new), figuring (while having my doubts about viability) if
they were both available and new was the default, unconfirmed must be an
intentional downgrade available for users who weren't sure yet, and were
going to follow up later after further tests.

> I think it might be even a good idea to limit the possibility of setting
> 'CONFIRMED' to devs. Otherwise, I see users bumping each of their bugs
> to 'CONFIRMED' immediately.

Is it possible to leave that option for users, but block it such that the
original filer can't flip it?  If so, IMO that would be best, as a second
user could then "confirm" it.

If it's not possible to block, unconfirmed could at least be made the
default and the wranglers could complain about (and change) bugs filed as
"confirmed" as they assign them.  The message should eventually get out,
and having a second user confirm the bug could actually be quite useful
for busy devs trying to prioritize their bugs.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply | Threaded
Open this post in threaded view
|

Re: Re: Bugzilla - New Default Status Workflow

Jeroen Roovers-3
In reply to this post by Christian Faulhammer-6
On Sun, 6 Mar 2011 14:17:37 +0100
Christian Faulhammer <[hidden email]> wrote:

> Hi,
>
> Christian Ruppert <[hidden email]>:
> > We're almost done with the preparation of bugzilla-4.x for
> > bugs.gentoo.org. So, do we want the new workflow or do we want to
> > keep the old?
>
>  New one, reopened is a bit pointless information on first glance.
>  History tells enough.

It's an important flag for a bug wrangler.


     jer

Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Paweł Hajdan, Jr.
In reply to this post by Brian Harring-2
On 3/7/11 11:13 AM, Brian Harring wrote:
> Re-read what he stated- it'll convert all existing NEW bugs to
> CONFIRMED upon migration.  There's a fair number of bugs that are in a
> NEW state, decent number that have sat for a long while too.  Those
> bugs aren't 'confirmed'- just like with the new work flow where the
> dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip
> the current bugs from UNCONFIRMED to CONFIRMED rather than just
> marking everything as CONFIRMED.

Maybe I'm misunderstanding something, but it seems we have both
UNCONFIRMED and NEW in the "old" workflow. My understanding is that
CONFIRMED is the new name for NEW, which makes sense.


signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Markos Chandras-2
On Thu, Mar 10, 2011 at 12:10:14PM +0100, "Paweł Hajdan, Jr." wrote:

> On 3/7/11 11:13 AM, Brian Harring wrote:
> > Re-read what he stated- it'll convert all existing NEW bugs to
> > CONFIRMED upon migration.  There's a fair number of bugs that are in a
> > NEW state, decent number that have sat for a long while too.  Those
> > bugs aren't 'confirmed'- just like with the new work flow where the
> > dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip
> > the current bugs from UNCONFIRMED to CONFIRMED rather than just
> > marking everything as CONFIRMED.
>
> Maybe I'm misunderstanding something, but it seems we have both
> UNCONFIRMED and NEW in the "old" workflow. My understanding is that
> CONFIRMED is the new name for NEW, which makes sense.
>
Sorry but no. NEW means "Ok I think this is a bug. Can you please take a
look?". CONFIRMED is "ok this is definitely a bug. I am able to
reproduce etc and will look into fixing it". The meaning is slightly
different but it is important to distinguish valid from invalid bugs.


Regards,
--
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

attachment0 (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Mike Gilbert
On Thu, Mar 10, 2011 at 6:15 AM, Markos Chandras <[hidden email]> wrote:

> On Thu, Mar 10, 2011 at 12:10:14PM +0100, "Paweł Hajdan, Jr." wrote:
>> On 3/7/11 11:13 AM, Brian Harring wrote:
>> > Re-read what he stated- it'll convert all existing NEW bugs to
>> > CONFIRMED upon migration.  There's a fair number of bugs that are in a
>> > NEW state, decent number that have sat for a long while too.  Those
>> > bugs aren't 'confirmed'- just like with the new work flow where the
>> > dev flips it from UNCONFIRMED to CONFIRMED, leave it to devs to flip
>> > the current bugs from UNCONFIRMED to CONFIRMED rather than just
>> > marking everything as CONFIRMED.
>>
>> Maybe I'm misunderstanding something, but it seems we have both
>> UNCONFIRMED and NEW in the "old" workflow. My understanding is that
>> CONFIRMED is the new name for NEW, which makes sense.
>>
> Sorry but no. NEW means "Ok I think this is a bug. Can you please take a
> look?". CONFIRMED is "ok this is definitely a bug. I am able to
> reproduce etc and will look into fixing it". The meaning is slightly
> different but it is important to distinguish valid from invalid bugs.
>
>
> Regards,
> --
> Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
>

If we were to switch to the new workflow, it probably would make sense
to switch the default new bug status to UNCONFIRMED. I'm not sure how
we would handle the existing bugs in NEW status.

Here are the workflow diagrams for our old Bugzilla and the new one. I
find pictures are a bit easier to follow.

Bugzilla 2.22:
http://www.bugzilla.org/docs/2.22/html/lifecycle.html

Bugzilla 4.0:
http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html

Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Jeroen Roovers-3
On Thu, 10 Mar 2011 11:04:19 -0500
Mike Gilbert <[hidden email]> wrote:

> If we were to switch to the new workflow, it probably would make sense
> to switch the default new bug status to UNCONFIRMED. I'm not sure how
> we would handle the existing bugs in NEW status.

I agree that new should now automatically be set to UNCONFIRMED when they are
not assigned yet (i.e. have been automatically assigned to
bug-wranglers) but to CONFIRMED when they are being assigned directly to their
respective maintainers.

For existing bugs, then, NEW bugs should be changed to UNCONFIRMED when they
are assigned to bug-wranglers, and to CONFIRMED when they have already
been assigned to their maintainers (irrespective of whether they are
actually confirmed or not or whether they are deemed to be actual bugs).

Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED
Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED

> Here are the workflow diagrams for our old Bugzilla and the new one. I
> find pictures are a bit easier to follow.

Thanks, those really helped.

(The only problem I have with the new workflow is that bugs assigned to
bug-wranglers can usually be dealt with more quickly when it is obvious
that new information has been added, which is the case when a bug has
been closed as RESOLVED, NEEDINFO, after which reopening it will set it
to REOPENED. If we're going to lose that, then the b-w assigned list
loses some definition. But maybe bugzilla 4's support of the Changed
column can help there.)


     jer

Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

aidecoe
Excerpts from Jeroen Roovers's message of Thu Mar 10 20:42:29 +0100 2011:
> For existing bugs, then, NEW bugs should be changed to UNCONFIRMED
> when they are assigned to bug-wranglers, and to CONFIRMED when they
> have already been assigned to their maintainers (irrespective of
> whether they are actually confirmed or not or whether they are deemed
> to be actual bugs).
>
> Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED
> Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED

Who confirms the bug?  I would expect that CONFIRMED is set by the
package maintainer and the one who assigns bugs leaves the status.
--
Amadeusz Żołnowski

PGP key fpr: C700 CEDE 0C18 212E 49DA  4653 F013 4531 E1DB FAB5

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Bugzilla - New Default Status Workflow

Jeroen Roovers-3
On Thu, 10 Mar 2011 21:06:54 +0100
Amadeusz Żołnowski <[hidden email]> wrote:

> > Status = NEW && Assignee = bug-wranglers -> Status = UNCONFIRMED
> > Status = NEW && Assignee = [maintainer] -> Status = CONFIRMED
>
> Who confirms the bug?  I would expect that CONFIRMED is set by the
> package maintainer and the one who assigns bugs leaves the status.

I was referring to existing bug reports, not new ones. New ones should
come in as UNCONFIRMED and would be changed to CONFIRMED when assigned
- bug wrangling does have this element of validation, you know.
Apparently when maintainers accept the bug, it changes to IN PROGRESS,
and when [s]he doesn't it should be resolved as invalid or duplicate
or whatever, but heck, maybe the flow chart should speak for itself.

Here is the URL again:

http://www.bugzilla.org/docs/4.0/en/html/lifecycle.html


     jer

12