[MPlayer-dev-eng] bugzilla states

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Sun Jul 11 12:14:49 CEST 2004


Hi,

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

delaying a bug ;-). I wished that was possible (sorry, I just had to say 
something stupid here).

> a resolution is only meaningfull for closed bugs, IMHO theres no need to 
> separate resolution from the state
> 
> REOPENED is useless, this is mixing the state with the past state
> 
> we have no QA so the states related to it should IMHO be sent to /dev/null
> 
> 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

I have strong doubts that either of them will be really used...

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

I'm not sure if the states for bugs and patches should be seperated. 
Usually a bugreport will result in a patch, and the other way around a 
patch would be bugreport that got into bugzilla after being mostly fixed...
But what I dislike most is that you give a lot of names for states, but 
not what _exactly_ they are supposed to mean and when and by whom they 
should be set. IMHO, the names themselves are really unimportant.

Greetings,
Reimar Döffinger




More information about the MPlayer-dev-eng mailing list