| FFmpeg's bug/patch/feature request tracker manual |
| ================================================= |
| |
| NOTE: This is a draft. |
| |
| Overview: |
| --------- |
| FFmpeg uses Roundup for tracking issues, new issues and changes to |
| existing issues can be done through a web interface and through email. |
| It is possible to subscribe to individual issues by adding yourself to the |
| nosy list or to subscribe to the ffmpeg-issues mailing list which receives |
| a mail for every change to every issue. Replies to such mails will also |
| be properly added to the respective issue. |
| (the above does all work already after light testing) |
| The subscription URL for the ffmpeg-issues list is: |
| http://live.polito/mailman/listinfo/ffmpeg-issues |
| The URL of the webinterface of the tracker is: |
| http(s)://roundup.ffmpeg/roundup/ffmpeg/ |
| Note the URLs in this document are obfuscated, you must append the top level |
| domain for non-profit organizations to the tracker, and of Italy to the |
| mailing list. |
| |
| Email Interface: |
| ---------------- |
| There is a mailing list to which all new issues and changes to existing issues |
| are sent. You can subscribe through |
| http://live.polito/mailman/listinfo/ffmpeg-issues |
| Replies to messages there will have their text added to the specific issues. |
| Attachments will be added as if they had been uploaded via the web interface. |
| You can change the status, substatus, topic, ... by changing the subject in |
| your reply like: |
| Re: [issue94] register_avcodec and allcodecs.h [type=patch;status=open;substatus=approved] |
| Roundup will then change things as you requested and remove the [...] from |
| the subject before forwarding the mail to the mailing list. |
| |
| |
| 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 implementation 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 make FFmpeg unusable for a significant number of users, and |
| patches fixing them. |
| Examples here might be completely broken MPEG-4 decoding or a build issue |
| on Linux. |
| While broken 4xm decoding or a broken OS/2 build would not be important, |
| the separation 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 do not make a big |
| difference. |
| |
| wish |
| Something that is desirable 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 is not 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 did not look outright |
| invalid. |
| This implicates that no real more detailed state applies yet. Conversely, |
| the more detailed states below implicate that the issue has been briefly |
| looked at. |
| |
| */closed/duplicate |
| Bugs, patches or feature requests which are duplicates. |
| Note that patches dealing with the same thing in a different way are not |
| duplicates. |
| Note, if you mark something as duplicate, do not forget setting the |
| superseder so bug reports are properly linked. |
| |
| */closed/invalid |
| Bugs caused by user errors, random ineligible or otherwise nonsense stuff. |
| |
| */closed/needs_more_info |
| Issues for which some information has been requested by the developers, |
| but which has not been provided by anyone within reasonable time. |
| |
| 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 analysis should be |
| available as a message in the bug report. |
| 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 already understood. |
| |
| bug/open/needs_more_info |
| Bug reports which are incomplete and or where more information is needed |
| from the submitter or another person who can provide it. |
| This state implicates that the bug has not been analyzed or reproduced. |
| Note, the idea behind needs_more_info is to offload work from the |
| developers to the users whenever possible. |
| |
| bug/closed/fixed |
| Bugs which have to the best of our knowledge been fixed. |
| |
| bug/closed/wont_fix |
| Bugs which we will not fix. Possible reasons include legality, high |
| complexity for the sake of supporting obscure corner cases, speed loss |
| for similarly esoteric purposes, et cetera. |
| This also means that we would reject a patch. |
| If we are just too lazy to fix a bug then the correct state is open |
| and unassigned. Closed means that the case is closed which is not |
| the case if we are just waiting for a patch. |
| |
| 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 knowledge. |
| |
| 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 it is 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 requests 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! |
| |
| Note2, if you provide the requested info do not forget to remove the |
| needs_more_info substate. |
| |
| Topic: |
| ------ |
| A topic is a tag you should add to your issue in order to make grouping them |
| easier. |
| |
| avcodec |
| issues in libavcodec/* |
| |
| avformat |
| issues in libavformat/* |
| |
| avutil |
| issues in libavutil/* |
| |
| regression test |
| issues in tests/* |
| |
| ffmpeg |
| issues in or related to ffmpeg.c |
| |
| ffplay |
| issues in or related to ffplay.c |
| |
| ffserver |
| issues in or related to ffserver.c |
| |
| build system |
| issues in or related to configure/Makefile |
| |
| regression |
| bugs which were working in a past revision |
| |
| roundup |
| issues related to our issue tracker |