[Ffmpeg-devel] Re: Advocating periodic releases
Wed Oct 11 11:47:17 CEST 2006
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/
> >>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:
> >>And the feature set is probably worth a read:
> >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
> >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
> >wontFix the bug is real but wont be fixed
> >invalid its the users fault (not reading manual, missuse of
> >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
> 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 ...
New -> Verified -> Analyzed -> Fixed (-> Fixed&Checked)
^\\\-> WorksForMe | | \-> WontFix
| \--> Duplicate <-/ |
v --> Invalid <-----/
New -> Ok -> Applied (->Applied&Checked)
^ \-> Rejected
> 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
More information about the ffmpeg-devel