[FFmpeg-cvslog] r9415 - trunk/doc/issue_tracker.txt
Sun Jun 24 23:01:31 CEST 2007
Date: Sun Jun 24 23:01:30 2007
New Revision: 9415
ffmpegs bug/patch/feature request tracker manual
--- (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
+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)
+ An error, flaw, mistake, failure, or fault in ffmpeg or libav* that
+ prevents it from behaving as intended.
+ 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.
+ A patch as generated by diff which conforms to the patch submission and
+ Development Policy.
+ Bugs and patches which deal with data loss and security issues
+ no feature request can be critical.
+ 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
+ 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
+ [FIXME can a bug be priority wish?]
+ initial state
+ intermediate states
+ Final state
+ Initial state of new bugs, patches and feature requests submitted by
+ Issues which have been briefly looked at and which didnt look outright
+ 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.
+ Bugs, patches or feature requests which are duplicate of some other.
+ Note patches dealing with the same thing but differently are not duplicate.
+ Bugs caused by user errors, random ineligible or otherwise nonsense stuff
+ Bugs which have been reproduced
+ 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.
+ 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
+ Bugs which have to the best of our knowledge been fixed.
+ Bugs which we will not fix, the reasons here could be legal, philosophical
+ or others
+ 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.
+ 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)
+ Patches which have been reviewed and need changes to be accepted
+ Patches which have been applied
+ Patches which have been rejected
+ Feature requests where its not clear what exactly is wanted
+ (these also could be closed as invalid ...)
+ Feature requests which have been implemented.
+ 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!
More information about the ffmpeg-cvslog