[Ffmpeg-devel] Re: Advocating periodic releases

[Roman Shaposhnik]

On Oct 10, 2006, at 2:50 AM, Michael Niedermayer wrote:
>>
>> I can't really comment on both. But one big difference between  
>> them is
>> that trac is a full project managment system, including source/ 
>> history
>> browsing, timeline/roadmap, wiki...
>
> sounds bloated ...

   I'm afraid it is. But I would welcome a comparison.

>
>> Roundup on the other hand is only and simply a bug tracker.
>>
>> Some real life roundup examples seems in order:
>> http://issues.bigasterisk.com/cuisine/
>> http://efod.se/python-tracker/
>>
>> And the feature set is probably worth a read:
>> http://roundup.sourceforge.net/doc-1.0/features.html
>
> could someone setup some roundup for testing and evaluation? (on mphq
> if admins agree and its easy and secure)
>
> as bug states (they can be configured i think) the following (from  
> some
> previous bugzilla flames) would be nice (comments welcome of course)
>
> newBug        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 a different bugreport which describes the same  
> bug
> wontFix       the bug is real but wont be fixed
> invalid       its the users fault (not reading manual, missuse of  
> something)
> needMoreInfo  further information is needed for reproducing the bug
>
> newPatch      initial state for new patches
> 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
>
> newRequest    initial state of new feature requests
> implemented   feature has been implemented
> wontImplement feature request is valid but wont be implemented
> invalidReq    unclear, or several unrelated things in one feature  
> request

   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 ? Do we have an initial evaluators for all of the
bugs, etc.

Thanks,
Roman.