[Ffmpeg-devel] Re: Advocating periodic releases

[Michael Niedermayer]

Hi

On Tue, Oct 10, 2006 at 07:12:17PM -0700, Roman Shaposhnik wrote:
> 
> 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 ? 

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? 

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is