[FFmpeg-devel] Reintroducing FFmpeg to Debian

[Michael Niedermayer]

Hi Vittorio

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
below

Thanks

On Fri, Aug 29, 2014 at 07:17:55PM +0200, Michael Niedermayer wrote:
> 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.
> 
> Thanks
> 
> [...]
> 
> -- 
> 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 ..."



-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140829/aa8ae107/attachment.asc>