On Fri, Aug 29, 2014 at 1:17 PM, Michael Niedermayer <michae...@gmx.at> 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. Regards, Vittorio _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
