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