git.sesse.net Git - ffmpeg/blob - doc/issue_tracker.txt

   1 FFmpeg's bug/patch/feature request tracker manual
   2 =================================================
   3
   4 NOTE: This is a draft.
   5
   6 Overview:
   7 ---------
   8 FFmpeg uses Trac for tracking issues, new issues and changes to
   9 existing issues can be done through a web interface.
  10 It is possible to subscribe to individual issues by adding yourself to the
  11 nosy list or to subscribe to the ffmpeg-issues mailing list which receives
  12 a mail for every change to every issue. Replies to such mails will also
  13 be properly added to the respective issue.
  14 (the above does all work already after light testing)
  15 The subscription URL for the ffmpeg-trac list is:
  16 http(s)://ffmpeg.org/mailman/listinfo/ffmpeg-trac
  17 The URL of the webinterface of the tracker is:
  18 http(s)://ffmpeg.org/trac/ffmpeg
  19
  20 NOTE: issue = (bug report || patch || feature request)
  21
  22 Type:
  23 -----
  24 bug
  25     An error, flaw, mistake, failure, or fault in FFmpeg or libav* that
  26     prevents it from behaving as intended.
  27
  28 feature request
  29     Request of support for encoding or decoding of a new codec, container
  30     or variant.
  31     Request of support for more, less or plain different output or behavior
  32     where the current implementation cannot be considered wrong.
  33
  34 patch
  35     A patch as generated by diff which conforms to the patch submission and
  36     development policy.
  37
  38
  39 Priority:
  40 ---------
  41 critical
  42     Bugs and patches which deal with data loss and security issues.
  43     No feature request can be critical.
  44
  45 important
  46     Bugs which make FFmpeg unusable for a significant number of users, and
  47     patches fixing them.
  48     Examples here might be completely broken MPEG-4 decoding or a build issue
  49     on Linux.
  50     While broken 4xm decoding or a broken OS/2 build would not be important,
  51     the separation to normal is somewhat fuzzy.
  52     For feature requests this priority would be used for things many people
  53     want.
  54
  55 normal
  56
  57
  58 minor
  59     Bugs and patches about things like spelling errors, "mp2" instead of
  60     "mp3" being shown and such.
  61     Feature requests about things few people want or which do not make a big
  62     difference.
  63
  64 wish
  65     Something that is desirable to have but that there is no urgency at
  66     all to implement, e.g. something completely cosmetic like a website
  67     restyle or a personalized doxy template or the FFmpeg logo.
  68     This priority is not valid for bugs.
  69
  70
  71 Status:
  72 -------
  73 new
  74     initial state
  75
  76 open
  77     intermediate states
  78
  79 closed
  80     final state
  81
  82
  83 Type/Status/Substatus:
  84 ----------
  85 */new/new
  86     Initial state of new bugs, patches and feature requests submitted by
  87     users.
  88
  89 */open/open
  90     Issues which have been briefly looked at and which did not look outright
  91     invalid.
  92     This implicates that no real more detailed state applies yet. Conversely,
  93     the more detailed states below implicate that the issue has been briefly
  94     looked at.
  95
  96 */closed/duplicate
  97     Bugs, patches or feature requests which are duplicates.
  98     Note that patches dealing with the same thing in a different way are not
  99     duplicates.
 100     Note, if you mark something as duplicate, do not forget setting the
 101     superseder so bug reports are properly linked.
 102
 103 */closed/invalid
 104     Bugs caused by user errors, random ineligible or otherwise nonsense stuff.
 105
 106 */closed/needs_more_info
 107     Issues for which some information has been requested by the developers,
 108     but which has not been provided by anyone within reasonable time.
 109
 110 bug/open/reproduced
 111     Bugs which have been reproduced.
 112
 113 bug/open/analyzed
 114     Bugs which have been analyzed and where it is understood what causes them
 115     and which exact chain of events triggers them. This analysis should be
 116     available as a message in the bug report.
 117     Note, do not change the status to analyzed without also providing a clear
 118     and understandable analysis.
 119     This state implicates that the bug either has been reproduced or that
 120     reproduction is not needed as the bug is already understood.
 121
 122 bug/open/needs_more_info
 123     Bug reports which are incomplete and or where more information is needed
 124     from the submitter or another person who can provide it.
 125     This state implicates that the bug has not been analyzed or reproduced.
 126     Note, the idea behind needs_more_info is to offload work from the
 127     developers to the users whenever possible.
 128
 129 bug/closed/fixed
 130     Bugs which have to the best of our knowledge been fixed.
 131
 132 bug/closed/wont_fix
 133     Bugs which we will not fix. Possible reasons include legality, high
 134     complexity for the sake of supporting obscure corner cases, speed loss
 135     for similarly esoteric purposes, et cetera.
 136     This also means that we would reject a patch.
 137     If we are just too lazy to fix a bug then the correct state is open
 138     and unassigned. Closed means that the case is closed which is not
 139     the case if we are just waiting for a patch.
 140
 141 bug/closed/works_for_me
 142     Bugs for which sufficient information was provided to reproduce but
 143     reproduction failed - that is the code seems to work correctly to the
 144     best of our knowledge.
 145
 146 patch/open/approved
 147     Patches which have been reviewed and approved by a developer.
 148     Such patches can be applied anytime by any other developer after some
 149     reasonable testing (compile + regression tests + does the patch do
 150     what the author claimed).
 151
 152 patch/open/needs_changes
 153     Patches which have been reviewed and need changes to be accepted.
 154
 155 patch/closed/applied
 156     Patches which have been applied.
 157
 158 patch/closed/rejected
 159     Patches which have been rejected.
 160
 161 feature_request/open/needs_more_info
 162     Feature requests where it is not clear what exactly is wanted
 163     (these also could be closed as invalid ...).
 164
 165 feature_request/closed/implemented
 166     Feature requests which have been implemented.
 167
 168 feature_request/closed/wont_implement
 169     Feature requests which will not be implemented. The reasons here could
 170     be legal, philosophical or others.
 171
 172 Note, please do not use type-status-substatus combinations other than the
 173 above without asking on ffmpeg-dev first!
 174
 175 Note2, if you provide the requested info do not forget to remove the
 176 needs_more_info substate.
 177
 178 Topic:
 179 ------
 180 A topic is a tag you should add to your issue in order to make grouping them
 181 easier.
 182
 183 avcodec
 184     issues in libavcodec/*
 185
 186 avformat
 187     issues in libavformat/*
 188
 189 avutil
 190     issues in libavutil/*
 191
 192 regression test
 193     issues in tests/*
 194
 195 ffmpeg
 196     issues in or related to ffmpeg.c
 197
 198 ffplay
 199     issues in or related to ffplay.c
 200
 201 ffserver
 202     issues in or related to ffserver.c
 203
 204 build system
 205     issues in or related to configure/Makefile
 206
 207 regression
 208     bugs which were working in a past revision
 209
 210 roundup
 211     issues related to our issue tracker