[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reintroducing FFmpeg to Debian

Hi Vittorio

On Thu, Aug 28, 2014 at 12:45:42AM -0400, Vittorio Giovara wrote:
> On 12/08/2014 18:30, Michael Niedermayer wrote:
> >Also ive offered my resignation in the past. I do still offer to
> >resign from the FFmpeg leader position, if it resolves this split
> >between FFmpeg and Libav and make everyone work together again.
> Hi Michael,
> sorry to come late to the party, but I just wanted to say that I am
> very glad that you think in this way. I do not fully understand why
> this could not have happened three years ago, but let bygones be
> bygones. For what is worth, in my personal opinion, you could even
> stay appointed as "the leader", after all noone better than you
> represents the ffmpeg way of thinking, and you've got some PR skills
> which are rare to find in technical people.

> 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.
But thats no problem for git bisect, git bisect has actually
no problem with that at all.
As someone who uses git bisect i can say it works very well, also i
know from carl, who does more bisecting in FFmpeg than i do, that
git bisect nowadays works very well in pratice with the tree.

> I am not saying that the theoretical
> merged project should use Libav tree either, but would you cooperate
> in the creation of a single linear history where merges are not
> allowed?

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

Right now, you can bisect in ffmpeg git and the bisect can identify
if a bug came from a commit in libav, one from ffmpeg or from a
merge (unless some checkout cannot be tested), this will not work
with a single linear chain of commits.

also it would break everyones checkout, it would break every fork of
FFmpeg and Libav on github, every developers private git tree and
every reference to a git checkout in bug reports or mailing lists.
And no this is not a neccesary thing to happen for a combined
FFmpeg+Libav project

If you just checkout libav and do a "git merge ffmpeg/master" you
would effectively change libavs checkout to match ffmpeg and
nothing would break. You still could Change anything in that
checkout you like, like for example to rename all FFmpeg to Libav
or revert any hunks that the merge brougt in which you dont like.

and rewriting 3 years of history of 2 active projects to somehow
interleave their commits could easily (depending on how its done)
turn commits/checkouts that once worked and where tested into no
longer working ones. Which would render debuging and bisecting a
quite unpleasant thing to do.

So to awnser your question, I think noone should spend time on
creating such linear history, It could be alot of work to do and
cause more work once done. Time could be spend much better in
improving code and fixing bugs.
That is i think we (FFmpeg and Libav) should not go this direction.
But if we do go this direction, sure ill walk with the community.

Also history drifts away, assuming the projects would reunify. In a
few years noone would even notice in daily work that there where 2
forks in the past. Like noone notices how messy commits where 10
years ago by todays standards

> Other problem might be the name of this shared project, it's clear
> that the ffmpeg of the past ended with the split and the "mpeg" term
> is a company trademark anyway. I think /ffav/ would not sound that
> bad and would represent the new spirit of this collaboration, where
> everyone is treated as equals and respect each other work (and
> person).
> >The part i insist on though is that everyone must be able to work
> >on their code without people uninvolved in that specific parts
> >maintaince or authorship being able to block their work.

> 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

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.



Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

Attachment: signature.asc
Description: Digital signature

Reply to: