We will review all submitted patches, but sometimes we are quite busy so
especially for large patches this can take several weeks.
-When resubmitting patches, if their size grew or during the review different
-issues arisen please split the patch so each issue has a specific patch.
+If you feel that the review process is too slow and you are willing to try to
+take over maintainership of the area of code you change then just clone
+git master and maintain the area of code there. We will merge each area from
+where its best maintained.
+
+When resubmitting patches, please do not make any significant changes
+not related to the comments received during review. Such patches will
+be rejected. Instead, submit significant changes or new features as
+separate patches.
+
+@anchor{Regression tests}
+@section Regression tests
-@anchor{Regression Tests}
-@section Regression Tests
+Before submitting a patch (or committing to the repository), you should at least
+test that you did not break anything.
-Before submitting a patch (or committing to the repository), you should at
-least make sure that it does not break anything.
+Running 'make fate' accomplishes this, please see @url{fate.html} for details.
-If the code changed has already a test present in FATE you should run it,
-otherwise it is advised to add it.
+[Of course, some patches may change the results of the regression tests. In
+this case, the reference results of the regression tests shall be modified
+accordingly].
-Improvements to codec or demuxer might change the FATE results. Make sure
-to commit the update reference with the change and to explain in the comment
-why the expected result changed.
+@subsection Adding files to the fate-suite dataset
+
+When there is no muxer or encoder available to generate test media for a
+specific test then the media has to be inlcuded in the fate-suite.
+First please make sure that the sample file is as small as possible to test the
+respective decoder or demuxer sufficiently. Large files increase network
+bandwidth and disk space requirements.
+Once you have a working fate test and fate sample, provide in the commit
+message or introductionary message for the patch series that you post to
+the ffmpeg-devel mailing list, a direct link to download the sample media.
-Please refer to @url{fate.html}.
-Libav maintains a set of @strong{release branches}, which are the
+ @anchor{Release process}
+ @section Release process
+
-Linux distributions, etc.). At irregular times, a @strong{release
++FFmpeg maintains a set of @strong{release branches}, which are the
+ recommended deliverable for system integrators and distributors (such as
-@url{http://libav.org} website.
++Linux distributions, etc.). At regular times, a @strong{release
+ manager} prepares, tests and publishes tarballs on the
-Note that we promise to our users that shared libraries from any Libav
++@url{http://ffmpeg.org} website.
+
+ There are two kinds of releases:
+
+ @enumerate
+ @item
+ @strong{Major releases} always include the latest and greatest
+ features and functionality.
+ @item
+ @strong{Point releases} are cut from @strong{release} branches,
+ which are named @code{release/X}, with @code{X} being the release
+ version number.
+ @end enumerate
+
-on the @strong{libav-devel} mailing list in time to allow forward planning.
++Note that we promise to our users that shared libraries from any FFmpeg
+ release never break programs that have been @strong{compiled} against
+ previous versions of @strong{the same release series} in any case!
+
+ However, from time to time, we do make API changes that require adaptations
+ in applications. Such changes are only allowed in (new) major releases and
+ require further steps such as bumping library version numbers and/or
+ adjustments to the symbol versioning file. Please discuss such changes
- Fixes a documented bug in @url{http://bugzilla.libav.org}.
++on the @strong{ffmpeg-devel} mailing list in time to allow forward planning.
+
+ @anchor{Criteria for Point Releases}
+ @subsection Criteria for Point Releases
+
+ Changes that match the following criteria are valid candidates for
+ inclusion into a point release:
+
+ @enumerate
+ @item
+ Fixes a security issue, preferably identified by a @strong{CVE
+ number} issued by @url{http://cve.mitre.org/}.
+ @item
-All Libav developers are welcome to nominate commits that they push to
-@code{master} by mailing the @strong{libav-stable} mailing list. The
-easiest way to do so is to include @code{CC: libav-stable@@libav.org} in
-the commit message.
-
++ Fixes a documented bug in @url{https://ffmpeg.org/trac/ffmpeg}.
+ @item
+ Improves the included documentation.
+ @item
+ Retains both source code and binary compatibility with previous
+ point releases of the same release branch.
+ @end enumerate
+
+ The order for checking the rules is (1 OR 2 OR 3) AND 4.
+
- File a release tracking bug in @url{http://bugzilla.libav.org}. Make
- sure that the bug has an alias named @code{ReleaseX.Y} for the
- @code{X.Y} release.
+
+ @subsection Release Checklist
+
+ The release process involves the following steps:
+
+ @enumerate
+ @item
+ Ensure that the @file{RELEASE} file contains the version number for
+ the upcoming release.
+ @item
- Reassign unresolved blocking bugs from previous release
- tracking bugs to the new bug.
-@item
- Review patch nominations that reach the @strong{libav-stable}
- mailing list, and push patches that fulfill the stable release
- criteria to the release branch.
-@item
++ Add the release at @url{https://ffmpeg.org/trac/ffmpeg/admin/ticket/versions}.
+ @item
+ Announce the intent to do a release to the mailing list.
+ @item
- Prepare the release tarballs in @code{xz} and @code{gz} formats, and
- supplementing files that contain @code{md5} and @code{sha1}
- checksums.
+ Ensure that the FATE regression suite still passes in the release
+ branch on at least @strong{i386} and @strong{amd64}
+ (cf. @ref{Regression Tests}).
+ @item
- Publish the tarballs at @url{http://libav.org/releases}. Create and
- push an annotated tag in the form @code{vX}, with @code{X}
++ Prepare the release tarballs in @code{bz2} and @code{gz} formats, and
++ supplementing files that contain @code{gpg} signatures
+ @item
- Build the tarballs with the Windows binaries, and publish them at
- @url{http://win32.libav.org/releases}.
-@item
- Propose and send a patch to the @strong{libav-devel} mailing list
++ Publish the tarballs at @url{http://ffmpeg.org/releases}. Create and
++ push an annotated tag in the form @code{nX}, with @code{X}
+ containing the version number.
+ @item
++ Propose and send a patch to the @strong{ffmpeg-devel} mailing list
+ with a news entry for the website.
+ @item
+ Publish the news entry.
+ @item
+ Send announcement to the mailing list.
+ @end enumerate
+
@bye
OSDN Git Service
