[FFmpeg-cvslog] r9415 - trunk/doc/issue_tracker.txt

Luca Barbato lu_zero
Mon Jun 25 11:18:45 CEST 2007


michael wrote:
> Author: michael
> Date: Sun Jun 24 23:01:30 2007
> New Revision: 9415
> 
> Log:
> ffmpegs bug/patch/feature request tracker manual
> 
> 
> Added:
>    trunk/doc/issue_tracker.txt
> 
> Added: trunk/doc/issue_tracker.txt
> ==============================================================================
> --- (empty file)
> +++ trunk/doc/issue_tracker.txt	Sun Jun 24 23:01:30 2007
> @@ -0,0 +1,156 @@
> +ffmpegs bug/patch/feature request tracker manual
> +================================================
> +
> +NOTE, this is a draft, its not yet recommanded to send real bugrepors to the
> +tracker but rather use the mailinglists
> +though if you are brave and dont mind that your bugreport might disapear or
> +that you might be mailbombed due to a missconiguration you can surely try
> +to enter a real bugreport
> +
> +Overview:
> +---------
> +FFmpeg uses roundup for tracking issues, new issues and changes to
> +existing issues can be done through a web interface and through email.
> +Its possible to subscribe to individual issues by adding yourself to the
> +nosy list or to subscribe to the ffmpeg_issues mailinglist which receives

ffmpeg-issues -> the mailing list
ffmpeg_issues -> the roundup mail

Maybe I should use tracker for one of those two...

> +wish
Something that is desiderable to have but that there is no urgency at
all to fix/implement/add, e.g.: something completely cosmetic like the
website restyle or a personalized doxy template or the ffmpeg logo
proposals. this priority isn't valid for bugs.


> +Status:
> +-------
> +new
> +    initial state
> +
> +open
> +    intermediate states
> +
> +closed
> +    Final state
> +
> +
> +Type/Status/Substatus:
> +----------
> +*/new/new
> +    Initial state of new bugs, patches and feature requests submitted by
> +    users
> +
> +*/open/open
> +    Issues which have been briefly looked at and which didnt look outright
> +    invalid
> +    This implicates that no real more detailed state applies yet. And the
> +    more detailed states below implicate that the issue has been briefly
> +    looked at.
> +
> +*/closed/duplicate
> +    Bugs, patches or feature requests which are duplicate of some other.
> +    Note patches dealing with the same thing but differently are not duplicate.
> +
> +*/closed/invalid
> +    Bugs caused by user errors, random ineligible or otherwise nonsense stuff
> +
> +bug/open/reproduced
> +    Bugs which have been reproduced
> +
> +bug/open/analyzed
> +    Bugs which have been analyzed and where it is understood what causes them
> +    and which exact chain of events triggers them. This analyzis should be
> +    available as a message in the bugreport
> +    Note, do not change the status to analyzed without also providing a clear
> +    and understandable analysis.
> +    This state implicates that the bug either has been reproduced or that
> +    reproduction is not needed as the bug is understood already anyway.
> +
> +bug/open/needs_more_info
> +    Bugreports which are incomplete and or where more information is needed
> +    from the submitter or another person who can provide the info.
> +    This state implicates that the bug has not been analyzed or reproduced
> +
> +bug/closed/fixed
> +    Bugs which have to the best of our knowledge been fixed.
> +
> +bug/closed/wont_fix
> +    Bugs which we will not fix, the reasons here could be legal, philosophical
> +    or others
> +
> +bug/closed/works_for_me
> +    Bugs for which sufficient information was provided to reproduce but
> +    reproduction failed that is the code seems to work correctly to the
> +    best of our knowledgde.
> +
> +patch/open/approved
> +    Patches which have been reviewed and approved by a developer.
> +    Such patches can be applied anytime by any other developer after some
> +    reasonable testing (compile + regression tests + does the patch do
> +    what the author claimed)
> +
> +patch/open/needs_changes
> +    Patches which have been reviewed and need changes to be accepted
> +
> +patch/closed/applied
> +    Patches which have been applied
> +
> +patch/closed/rejected
> +    Patches which have been rejected
> +
> +feature_request/open/needs_more_info
> +    Feature requests where its not clear what exactly is wanted
> +    (these also could be closed as invalid ...)
> +
> +feature_request/closed/implemented
> +    Feature requests which have been implemented.
> +
> +feature_request/closed/wont_implement
> +    Feature reuests which will not be implemented. The reasons here could
> +    be legal, philosophical or others.
> +
> +Note, please do not use type-status-substatus combinations other than the
> +above without asking on ffmpeg-dev first!

I'll try to write a reactor to error out if the combination doesn't make
sense...

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero




More information about the ffmpeg-cvslog mailing list