Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?= <u <at> pkh.me>
Subject: [PATCH] doc: add Libav merge document
Newsgroups: gmane.comp.video.ffmpeg.devel
Date: Thursday 23rd June 2016 14:27:59 UTC (about 1 year ago)
From: Clément Bœsch 

---
Very incomplete, maybe splittable (split out the 3 first sections somewhere
as
an announce on the website)

Comments from other people who have done merges in the past very welcome,
notably on the last 2 sections.
---
 doc/libav-merge.txt | 109
++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 109 insertions(+)
 create mode 100644 doc/libav-merge.txt

diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt
new file mode 100644
index 0000000..2ae22b1
--- /dev/null
+++ b/doc/libav-merge.txt
@@ -0,0 +1,109 @@
+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 \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)
-- 
2.9.0

_______________________________________________
ffmpeg-devel mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 
CD: 3ms