[Ffmpeg-devel] Re: Advocating periodic releases

Dana Hudes dhudes
Fri Oct 13 20:22:28 CEST 2006


Michael Niedermayer wrote:
>>
>>   I think it'll be much easier to discuss whether this is a useful list
>> if we also provide a transition diagram between these states. IOW,
>> I think we should start from a model we, as a team, would like to
>> have in place in order to make our work with externally logged bugs
>> easier. E.g. when the bug gets logged and is assigned a newBug state
>> what is the next step ? 
>>     
>
> state diagram copy & pasted from an old bugzilla flame ...
> ----------
> Bugs:
>    /<--------------------------\
> New -> Verified -> Analyzed -> Fixed (-> Fixed&Checked)
> ^\\\-> WorksForMe  | |     \-> WontFix
> | \--> Duplicate <-/ |
> v  --> Invalid <-----/
> NeedMoreInfo
>
> Patches:
>    /<-(reverse)-\
> New -> Ok -> Applied (->Applied&Checked)
> ^  \-> Rejected
> |
> v
> NeedsChanges
>
> ----------
>
>   
>> Do we have an initial evaluators for all of the
>> bugs, etc.
>>     
>
> you mean someone who just looks at bugs but doesnt try to fix them? well
> depends its very possible that someone will go over newBugs and change
> them to invalid/duplicate/needsMoreInfo/worksForMe/Verified
> its also possible that someone looks at a new bug and changes it to
> fixed at once after fixing the bug ...
>
> or do you mean we should have an extra "ok" state which is assigned
> to all good new bugs? 
>
> [...]
>
>   
Yes, a "confirmed" state. Mantis has this. Also "duplicate" and "not a 
bug" are resolution states.







More information about the ffmpeg-devel mailing list