mirror of https://github.com/FFmpeg/FFmpeg.git
We have now switched to http://bugzilla.libav.org.pull/2/head
parent
8b84af7488
commit
fccab01807
1 changed files with 0 additions and 228 deletions
@ -1,228 +0,0 @@ |
||||
Libav's bug/patch/feature request tracker manual |
||||
================================================ |
||||
|
||||
NOTE: This is a draft. |
||||
|
||||
Overview: |
||||
--------- |
||||
Libav 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.libav.org/ |
||||
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 Libav 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 Libav 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 libav-devel 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 |
Loading…
Reference in new issue