Re: [FFmpeg-devel] [PATCH] doc: add Libav merge document

[Clément Bœsch]

On Tue, Aug 02, 2016 at 09:23:04AM -0700, Timothy Gu wrote:
> I've put this document onto the wiki so that it's easier to edit:
> https://trac.ffmpeg.org/wiki/LibavMerge
> 

I actually think it belongs in FFmpeg repository as it's partly a
political document so you don't want anyone to be able to edit it at will
without review.

Patch applied with an additional entry at the end of the document.

You should probably drop that wiki page (after merging the eventual
changes back into the file in the repository)

Regards,

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: add Libav merge document

[Timothy Gu]

I've put this document onto the wiki so that it's easier to edit:
https://trac.ffmpeg.org/wiki/LibavMerge

Timothy

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc: add Libav merge document

[Michael Niedermayer]

On Thu, Jun 23, 2016 at 04:27:59PM +0200, Clément Bœsch wrote:
> 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.

ill probably post some patches/suggestions to extend this once its
applied


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc: add Libav merge document

[Clément Bœsch]

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 000..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