diff --git a/doc/issue_tracker.txt b/doc/issue_tracker.txt deleted file mode 100644 index e5733ec9d5..0000000000 --- a/doc/issue_tracker.txt +++ /dev/null @@ -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