ffmpegs bug/patch/feature request tracker manual

Originally committed as revision 9415 to svn://svn.ffmpeg.org/ffmpeg/trunk

doc/issue_tracker.txt

@@ -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
+a mail for every change to every issue. Replies to such mails will also
+properly be added to the respective issue.
+(the above does all work already after light testing)
+
+note: issue = (bug report || patch || feature request)
+
+Type:
+-----
+bug
+    An error, flaw, mistake, failure, or fault in ffmpeg or libav* that
+    prevents it from behaving as intended.
+
+feature request
+    Request of support for encoding or decoding of a new codec, container
+    or variant.
+    Request of support for more, less or plain different output or behavior.
+    Where the current behavior cannot be considered wrong.
+
+patch
+    A patch as generated by diff which conforms to the patch submission and
+    Development Policy.
+
+
+Priority:
+---------
+critical
+    Bugs and patches which deal with data loss and security issues
+    no feature request can be critical.
+
+important
+    Bugs which makes ffmpeg unuseable for a significant number of users, and
+    patches fixing them.
+    examples here might be completly broken mpeg4 decoding or a build issue
+    on linux
+    while broken 4xm decoding or broken os2 build would not be important, the
+    seperation to normal is somewhat fuzzy ...
+    For feature requests this priority would be used for things many people
+    want.
+
+normal
+
+
+minor
+    Bugs and patches about things like spelling errors, "mp2" instead of
+    "mp3" being shown and such
+    Feature requests about things few people want or which dont make a big
+    difference.
+
+wish
+    [FIXME can a bug be priority wish?]
+
+
+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!