[MPlayer-dev-eng] bugzilla states

[Michael Niedermayer]

Hi

On Sunday 11 July 2004 12:14, Reimar Döffinger wrote:
[...]
> > 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...
if there is a large number of bugreports then IMHO its usefull to somehow 
seperate security bugs from bugs about typos

>
> > 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...
i disagree, bugreports are not patches, there is not a 1-1 relation between 
them, this is the same nonsense as making "assigned" a single state
for example there could be several patches to fix one bug, or one patch could 
fix several bugs, and often there will be bugs where the fix is commited 
straight without a patch or patches which do some other change which isnt a 
bugfix

> But what I dislike most is that you give a lot of names for states, but
> not what _exactly_ they are supposed to mean
New           initial state for new bugreports
verified      someone succeded in reproducing the bug
analyzed      it is understood why things dont work like they should
fixed         fix is in cvs
fixed&checked someone confirmed that the fix really fixed the bug
worksForMe    bug is not reproduceable
duplicate     theres another bugreport which describes the same bug
wontFix       the bug wont be fixed
invalid       its the users fault (not reading manual, missuse of something)
needMoreInfo  further information is needed for reproducing the bug

ok            patch is ok, should be applied ASAP
applied       patch has been applied to cvs
rejected      patch is fundamentally broken and should not be aplied
needChanges   changes are needed before the patch can be applied

> and when and by whom they 
> should be set. 
thats pretty obvious, isnt it? users submit new patches/bugs and and whoever 
has access rights & is changing things so that another state is more 
appropriate changes the state, so for example if the maintainer of some code 
looked at a patch and thinks its ok he changes the state to ok or if he 
applies the patch too then he changes it to applied
who should be allowed to change states? everyone who has cvs write access at 
least IMHO, but thats becoming a bit off topic as the disscussion is about 
states ...

> IMHO, the names themselves are really unimportant. 
i strongly disagree, names are very important, especially for people who are 
not mplayer devs but just want to submit a bugreport or help in fixing 
one, ...

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en