[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