mirror of https://git.ffmpeg.org/ffmpeg.git
doc: Remove outdated information about our issue tracker
We have now switched to http://bugzilla.libav.org.
This commit is contained in:
Reinhard Tartler
parent
8b84af7488
commit
fccab01807
|
|
@ -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