[MPlayer-dev-eng] bugzilla states

[Ivan Kalvachev]

I wasn't able to find a weak point in Michael proposial.
I find the states and their names intuitive.
I think the only thing missing is feature requests.)


So let's do it.

Wish You Best
   Ivan Kalvachev
  iive



Michael Niedermayer said:
> Hi
>
> On Sunday 11 July 2004 12:14, Reimar Döffinger wrote:
> [...]
>> > i also dont understand what propose Severity AND Priority serve, IMHO we

Fully agree. I think it would be good to rename Severity to Priority and to
remove the original Priority


>> 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