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.
signature.asc
Description: Digital signature
