diff options
author | Clément Bœsch <clement@stupeflix.com> | 2016-06-23 16:25:24 +0200 |
---|---|---|
committer | Clément Bœsch <clement@stupeflix.com> | 2016-08-17 15:31:38 +0200 |
commit | 2477775bf837798696c283a854d17a1d2c60b923 (patch) | |
tree | b1a7c096b9a8bbe0f255d25ee36213cf3d0bcba8 | |
parent | d299defbba301ca85367a71d0332e69da0893e6f (diff) | |
download | ffmpeg-2477775bf837798696c283a854d17a1d2c60b923.tar.gz |
doc: add Libav merge document
-rw-r--r-- | doc/libav-merge.txt | 110 |
1 files changed, 110 insertions, 0 deletions
diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt new file mode 100644 index 0000000000..60c953a49f --- /dev/null +++ b/doc/libav-merge.txt @@ -0,0 +1,110 @@ +CONTEXT +======= + +The FFmpeg project merges all the changes from the Libav project +(https://libav.org) since the origin of the fork (around 2011). + +With the exceptions of some commits due to technical/political disagreements or +issues, the changes are merged on a more or less regular schedule (daily for +years thanks to Michael, but more sparse nowadays). + +WHY +=== + +The majority of the active developers believe the project needs to keep this +policy for various reasons. + +The most important one is that we don't want our users to have to choose +between two distributors of libraries of the exact same name in order to have a +different set of features and bugfixes. By taking the responsibility of +unifying the two codebases, we allow users to benefit from the changes from the +two teams. + +Today, FFmpeg has a much larger user database (we are distributed by every +major distribution), so we consider this mission a priority. + +A different approach to the merge could have been to pick the changes we are +interested in and drop most of the cosmetics and other less important changes. +Unfortunately, this makes the following picks much harder, especially since the +Libav project is involved in various deep API changes. As a result, we decide +to virtually take everything done there. + +Any Libav developer is of course welcome anytime to contribute directly to the +FFmpeg tree. Of course, we fully understand and are forced to accept that very +few Libav developers are interested in doing so, but we still want to recognize +their work. This leads us to create merge commits for every single one from +Libav. The original commit appears totally unchanged with full authorship in +our history (and the conflict are solved in the merge one). That way, not a +single thing from Libav will be lost in the future in case some reunification +happens, or that project disappears one way or another. + +DOWNSIDES +========= + +Of course, there are many downsides to this approach. + +- It causes a non negligible merge commits pollution. We make sure there are + not several level of merges entangled (we do a 1:1 merge/commit), but it's + still a non-linear history. + +- Many duplicated work. For instance, we added libavresample in our tree to + keep compatibility with Libav when our libswresample was already covering the + exact same purpose. The same thing happened for various elements such as the + ProRes support (but differences in features, bugs, licenses, ...). There are + many work to do to unify them, and any help is very much welcome. + +- So much manpower from both FFmpeg and Libav is lost because of this mess. We + know it, and we don't know how to fix it. It takes incredible time to do + these merges, so we have even less time to work on things we personally care + about. The bad vibes also do not help with keeping our developers motivated. + +- There is a growing technical risk factor with the merges due to the codebase + differing more and more. + +MERGE GUIDELINES +================ + +The following gives developer guidelines on how to proceed when merging Libav commits. + +Before starting, you can reduce the risk of errors on merge conflicts by using +a different merge conflict style: + + $ git config --global merge.conflictstyle diff3 + +Here is a script to help merging the next commit in the queue: + + #!/bin/sh + + if [ "$1" != "merge" -a "$1" != "noop" ]; then + printf "Usage: $0 <merge|noop [REF_HASH]>\n" + exit 0 + fi + + [ "$1" = "noop" ] && merge_opts="-s ours" + + nextrev=$(git rev-list libav/master --not master --no-merges | tail -n1) + if [ -z "$nextrev" ]; then + printf "Nothing to merge..\n" + exit 0 + fi + printf "Merging $(git log -n 1 --oneline $nextrev)\n" + git merge --no-commit $merge_opts --no-ff --log $nextrev + + if [ "$1" = "noop" -a -n "$2" ]; then + printf "\nThis commit is a noop, see $2\n" >> .git/MERGE_MSG + fi + + printf "\nMerged-by: $(git config --get user.name) <$(git config --get user.email)>\n" >> .git/MERGE_MSG + + +The script assumes a remote named libav. + +It has two modes: merge, and noop. The noop mode creates a merge with no change +to the HEAD. You can pass a hash as extra argument to reference a justification +(it is common that we already have the change done in FFmpeg). + +TODO/FIXME/UNMERGED +=================== + +- HEVC DSP and x86 MC SIMD improvements from Libav (see http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/204917) +- Porting ffmpeg*.c to codecpar (see bbf5ef9dac9475d8ed22da23acc2eb63a2640784) |