doc: Remove outdated information about our issue tracker

We have now switched to http://bugzilla.libav.org.

doc/issue_tracker.txt

@@ -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