Re: Reintroducing FFmpeg to Debian
On Fri, Aug 29, 2014 at 1:17 PM, Michael Niedermayer <email@example.com> wrote:
> also please dont remove ffmpeg-devel from the CC
> I had missed that you removed it so my reply went just to debian-devel
> full quote left below for ffmpeg-devel, no further inline comments
Sorry about that. Last time I tried having a serious conversation on
unified projects in that mailing list, I got emails whining about
personal things or mentioning that I should stop "wasting anyone's
time and go back to cherry-picking". Interestingly enough, three
months later someone is now trying to set up a shared channel of
communication between projects, think about timing!
Anyway, I left all lists in CC, let's hope this time goes better.
>> However there are other more practical problems. For example, FFmpeg
>> merges patches daily and this over time has created a somewhat
>> difficult to navigate git tree, it's enough to go back one year that
>> you start having 4 or 5 layers of branching and bisecting is more
>> complex than it needs it to be.
> The true history is "complex", theres not a single linear chain of
> changes after the fork.
> The history is not a single linear chain of commits, the only way by
> which one can make it into one is by rebasing commits and making the
> actual (non linear) history harder to access
> And no this is not a neccesary thing to happen for a combined
> FFmpeg+Libav project
Well it is linear in Libav's tree and when accessing ffmpeg history
(with or without bisect) having to visually skip all the "Merge commit
<hash>" messages might be somewhat difficult to do, in my personal
opinion. Also not having rebased changes means that you can never ever
pick a random patch and know if it will apply as you have no way of
knowing if it comes from a branch or master.
Finally, I believe having a linear history is quite a strong
requirement from Libav side and there is absolutely no gain in
allowing merges. I didn't want propose to use Libav tree because it
sounded biased, but I see no other option if you'd prefer not to
recreate the tree from scratch.
>> I don't think anyone would object to that, but there are of course
>> many more problems to unwind. This might be quite long (and perhaps
>> tedious) to discuss by email, so I would think that the best place
>> to talk about a possible merge would be at the upcoming VDD in
>> Dublin, where the whole group could meet, discuss problems, outline
>> the new project policies and design goal and similar topics.
> git log | grep '^Author:' | tr '[:upper:]' '[:lower:]' | sed 's/<.*>//'| sort | uniq -c | wc
> gives 1155
> now some of these are duplicates and some have just 1 commit in
> FFmpeg/Libav but still the maybe 10-20 or so FFmpeg&Libav developers
> who might be at VDD are quite far from the "whole group" and while i
> think discussing the Libav-FFmpeg split and ways to resolve it at VDD
> makes a lot of sense, quite litterally more than 90% of the developers
> wont be there. I also wont be there
This is a nice but misleading statistics. Everyone knows that you, as
"ffmpeg leader", are the only one able to modify development polices
and set design goals of the project you are actually leading. It's a
pity you are not able to come, as if you had decided otherwise, we'd
have had 100% of the people necessary for the reunification to happen
(or at least to start).
> also iam quite confident that if theres a will to undo the split
> then the type of communication channel used is quite irrelevant and
> we can and will find a solution to reunify the projects.
Perhaps, however the same could be said from the opposite end, if you
are really interested in reunifying the split, you could just this
once actively attend to a face to face meeting with a relevant
percentage of the development team. Also I am not sure that email is
the best medium to discuss such delicate topics, and do not forget
that there is the bad precedent of the events of three years ago,
which all took place with email as medium.
So allow me to insist, please do come to VDD and let's discuss to find
a way to make things right for everybody.