~medibuntu-maintainers/mplayer/medibuntu.precise

« back to all changes in this revision

Viewing changes to ffmpeg/doc/issue_tracker.txt

  • Committer: Gauvain Pocentek
  • Date: 2012-03-06 11:59:12 UTC
  • mfrom: (66.1.15 precise)
  • Revision ID: gauvain@pocentek.net-20120306115912-h9d6kt9j0l532oo5
* Merge from Ubuntu:
  - put back faac support
  - recommends apport-hooks-medibuntu
  - change Maintainer, Uploaders & Vcs-* fields.
* New upstream snapshot
* upload to unstable
* Build against external libmpeg2
* drop 51_FTBFS_arm.patch again
* no longer build depend on libcdparanoia-dev on the Hurd
* Fix FTBFS on the hurd.
  Thanks to Samuel Thibault <sthibault@debian.org> (Closes: #654974)
* Fix FTBFS on arm
* New upstream snapshot, Closes: #650339, #643621, #481807
* Imported Upstream version 1.0~rc4+svn34492
* Bump standards version
* Bump dependency on libav >= 4:0.8~, Closes: #653887
* Fix build-indep
* Build mplayer-gui again, Closes: #568514
* Drop debian/all-lang-config-mak.sh, no longer needed
* include .dfsg1 in version number
* remove get-orig-source target
* no longer prune compiler flags from the environment
* No longer advertise nor build 3fdx, mga and dxr3 backends,
  Closes: #496106, #442181, #533546
* beautify mplayer version identification string
* Brown paperbag upload.
* Next try to fix build failure on sparce after recent binutils change.
* Brown paperbag upload.
* Really fix build failure on sparc after recent binutils change.
* Properly set Replaces/Conflicts on mplayer2{,-dbg} to avoid
  file overwrite errors.
* Adjust versioning of mplayer listed in the mplayer-dbg's Depends field.
* Fix build failure on sparc after recent binutils change.
* Urgency medium bumped because of RC-level bugfix
  and speeding up x264 transition.
* Update to my @debian.org email.
* Upload to unstable
* Enable joystick support on Linux only, Closes: #638408
* Rebuild fixes toolchain issue on arm, Closes: #637077
* New upstream snapshot
* following the discussion started by Diego Biurrun <diego@biurrun.de>
  in debian-devel, I have prepared a new packaging of 'mplayer'
  (with code that comes from CVS)
* the upstream tar.bz cannot be distributed by Debian, since it contains
   CSS code; so I am repackaging it 
* I have tried my best to address all known issues:
  - the package contains the detailed Copyright made by Diego Biurrun 
  - the package does not contain CSS code, or  AFAIK other code on which 
     there is active patent enforcement
  - there is a script  debian/cvs-changelog.sh  that shows all changes
     done to files included in this source.
    This should comply with GPLv2 sec 2.a  (in spirit if not in letter)
    For this reason, the source code contains CVS directories.
* needs   make (>= 3.80) for 'html-chunked-$(1)' in DOCS/xml/Makefile

* some corrections, as suggested Diego Biurrun
  - binary codecs should go into /usr/lib/codecs (upstream default)
  - better template 'mplayer/install_codecs'
  - an empty 'font=' in mplayer.conf breaks mplayer: postinst corrected
* correction in 'mplayer/cfgnote'
* better mplayer.postinst and mplayer.config

* New upstream release
* better debian/copyright file
* do not ship a skin
* New upstream release
* changed DEB_BUILD_OPTIONS to DEB_BUILD_CONFIGURE ,
  DEB_BUILD_OPTIONS is used as in debian policy
* use gcc-3.4
* changed xlibs-dev to a long list of dependencies, for Debian/etch
* try to adhere to  http://www.mplayerhq.hu/DOCS/tech/binary-packaging.txt
  (see README.Debian for details)
* removed dependency on xlibmesa-dev, disabled opengl
* New upstream release
* Simon McVittie <hacks@pseudorandom.co.uk> wonderful work:
- Work around Debian bug #267442 (glibc's sys/uio.h and gcc's altivec.h have
  conflicting uses for __vector) by re-ordering #includes
- Fix potential symlink attack in ./configure
- Disable support for binary codecs on platforms for which those codecs
  aren't available; also disable the corresponding Debconf note when it's
  inappropriate
- Changed Build-Depends: so it works in pbuilder
- Explicitly build-depend on libjpeg62-dev, libfontconfig1-dev,
  libungif4-dev 
- Tweak debian/rules to avoid certain errors being ignored
- Use --language=all
* provide a target  'debian/rules get-orig-source' 
  that recreates the orig.tar.gz ; then use the above orig.tar.gz
* rewrote some parts of debian/rules
* don't clean and recompile docs if upstream ships them
* mplayer-doc was shipping too much stuff
* translated man pages where not installed properly
* compile with libdv4-dev
* correct README.Debian
* Forgot build-dep on libtheora
* Must not depend on libxvidcore
* New upstream release
* new release.
* rc1 to become 0.90
* new pre-release
* new pre-release
* gtk bug fixed.
* new release.
* version bumped
* 0.60 pre2 release
* 0.60 pre-release.

Show diffs side-by-side

added added

removed removed

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