mirror of
https://github.com/xenia-project/FFmpeg.git
synced 2024-11-28 05:50:43 +00:00
160 lines
5.2 KiB
Plaintext
160 lines
5.2 KiB
Plaintext
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
|
|
Something that is desiderable to have but that there is no urgency at
|
|
all to implement, e.g.: something completely cosmetic like a
|
|
website restyle or a personalized doxy template or the ffmpeg logo.
|
|
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!
|