Hi folks, Since Michael decided to step down as a leader, the question of reunification with Libav came up once more naturally. Before negotiations start again, I think it's important if we can all individually start thinking about what are our conditions or expectations from a potential reunification, and what we are willing to concede in the process.
The purpose of the operation is to start a debate with a very good overview for everyone about what is still going wrong and what are the priorities in solving the matter. The Libav project has been encouraged to do the same by Jean-Baptiste Kempf and myself, and at least some of the developers seem to be willing to play the game. The VDD are coming soon¹, and while I personally hate these real life meetings more than probably most of the people here on this mailing list, I think with recent the events (Michael leadership, but also stuff like FFmpeg being back as default in all the distributions) and the help of this "mental preparation" (or whatever you want to call it), we finally have a great opportunity to put an end to this extremely toxic environment for our common users and developers from both projects. So I'd call for everyone to come, even though I have many doubts about this. In order to illustrate what I'm selfishly expecting from this operation, I'll start here with my own list. Keep in mind that it's not so much for discussing it right now, and certain points are meant to be very personal and in disagreement with probably a number of current FFmpeg developers. We are just setting up pieces on the board for a future discussion. Highest: - Using the current FFmpeg source code as the code base for the common project. This is the most important point. There are many arguments toward this, but I think the main one is that we do not want to loose anything of the last years of development from many FFmpeg developers. The amount of work done by everyone is surreal, and it would be a huge mistake to think that we can re-do all of this based on a old code base or on Libav code without losing code history, gaining regressions, and losing people because they won't work on an incomplete codebase for a very long time. Which leads me to my next point: - After we come to an agreement, both FFmpeg and Libav must freeze their respective repository. That way, everyone is forced to work on a common project, or has to fork properly in case of a disagreement (by changing not only the project name but also the library names etc). This will prevent losing something from the past years for both projects. Medium: - While I have no real opinion on whether a leader is needed, I think it really helps when you don't have a process that prevent any development dead lock. The decision machine must not stop. Since we all agree there is no one currently that can take the position of a leader in FFmpeg, and there isn't really any on Libav, creating a working development process looks like a priority to me. I do not believe at all in review blocking in the current Libav state for several reasons, and I don't think FFmpeg is perfect in that regard, especially with no more decision maker. So there is room for discussion here. A middle ground between the two would involve talking about maintainership areas, and common sense about trust and power on these areas. Typically, I would like to avoid having to wait for a meaningless review on a patch for code only I know. Again, I'm fine doing concessions here but I think the terms need to be discussed. - 2011 is our Godwin point. It needs to stop being mentioned for the sanity of everyone, so developers of the new project would need to stand against other developers and users to stop the discussion ASAP when it appears. - One of the main collateral damage for the FFmpeg codebase is the duplicated features (prores, avr/swr, and more), and I'm willing to make this a priority on my TODO list for the sake of the new project, but I would like to see more people standing here, especially when they are concerned by these areas. - Redefine how we make evolution on the API: while there are indeed very different approaches to how API evolve in both projects, I think it is really mainly a consequence of politics (for compatibility FFmpeg had many trouble engaging in API evolution for instance), and I think we can come up with new methods and how to deal with that. So basically, this is a touchy topic, but it is because even our users disagree with this (some want to trash many stuff, and some want to keep them forever) more than a disagreement between FFmpeg and Libav developers. I'm looking forward many benefits in this reunification, such as finally being able to end my long struggle with the subtitles API that I couldn't really change for years. - We should probably keep our bug tracker since it reflects bugs on the FFmpeg code base. Processing every bugs from the Libav tracker and importing them might require some work, but I think Carl has done most of that already. I'm fine if we migrate to something else than Trac as long as the current DB is properly imported (I don't really like bugzilla but I'm fine with it). Lowest: - I think keeping the FFmpeg name is important from at least a "marketting" PoV, but in all honestly if it is renamed to FFmpegAndLibav, FFmpeg-NG, or MultimediaDrama I don't really care as long as the communication around the new project is done properly and 2nd point of my highest expectations is met. But note that while I think "FFmpeg" as a name is fine, I don't think using "Libav" name is going to do any good due to bad image and butthurt developers. Anyway, this is a call for other FFmpeg developers, please share your own feelings about this. Best regards, [1]: http://www.videolan.org/videolan/events/vdd15/ -- Clément B.
pgpgtrTTzBRzT.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
