[MPlayer-dev-eng] bugzilla states

[Diego Biurrun]

Hi!

OK, there seems to be quite a bit of confusion about how Bugzilla
works and/or is supposed to work.  If you haven't already, please
read:

http://bugzilla.mplayerhq.hu/bug_status.html

Background: I have worked quite a bit as Mozilla QA before joining
MPlayer and set up Bugzilla for work.

Michael Niedermayer writes:
> 
> <flame>
> IMHO the states we currently have in bugzilla.mplayerhq.hu are extremely sick 
> and non intuitive

They are far from perfect, but they make more sense once you get used
to them.

> assignment has nothing to do with the state, its independent, a bug in every 
> state could be assigned to someone or it could be unassigned

The status "ASSIGNED" is not to be confused with the "Assigned To:"
field.  Status "ASSIGNED" is supposed to mean that the person
mentioned in the "Assigned To:" field is working on the bug.

> the same is true for delaying a bug until after the next release

That's what target milestones are for.  ATM they are not switched on.

> a resolution is only meaningfull for closed bugs, IMHO theres no need to 
> separate resolution from the state

The difference between CLOSED, VERIFIED and RESOLVED is blurry.  In
the Mozilla project somebody resolves a bug and later on a QA verifies
that the resolution is correct.

> REOPENED is useless, this is mixing the state with the past state

No, if the resolution is deemed incorrect or if a fix did not work as
advertised/expected the bug is reopened.

> we have no QA so the states related to it should IMHO be sent to /dev/null

maybe

> i also dont understand what propose Severity AND Priority serve, IMHO we need 
> just one of them, and no i am not saying there are no obscure cases where 
> they would make sense together, just that they dont make sense in reality

Severity indicates if a bug is a crasher or a typo whereas priority is
there for devs to organize their work.

Probably it's confusing that Mosu renamed priorities from P1-P5 to
important etc, maybe we should change this back.

> IMHO, the states we need at minimum are:
> Bugs:
>    /<--------------------------\
> New -> Verified -> Analyzed -> Fixed (-> Fixed&Checked)
> ^\\\-> WorksForMe  | |     \-> WontFix
> | \--> Duplicate <-/ |
> v  --> Invalid <-----/
> NeedMoreInfo

UNCONFIRMED is what you describe as New, NEW is Verified.  We should
just make bugs start in the UNCONFIRMED state.

Analyzed and NeedMoreInfo might be interesting to add.

> Patches:
>    /<-(reverse)-\
> New -> Ok -> Applied (->Applied&Checked)
> ^  \-> Rejected
> |
> v
> NeedsChanges

Patches have a status field, you can label them "needs-work" and
"obsolete", an "Applied" field would be nice to have, I filed a
request for enhancement bug about this on the original Bugzilla long
ago and they might implement it someday.

Diego