[Ffmpeg-devel] Re: Advocating periodic releases
Roman Shaposhnik
rvs
Wed Oct 11 04:12:17 CEST 2006
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.
More information about the ffmpeg-devel
mailing list