[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