[FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers

[Hendrik Leppkes]

On Sat, Aug 1, 2015 at 11:18 AM, Clément Bœsch <u at pkh.me> wrote:
> 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.
>

I agree with most your points and have barely anything to add, but for
the sake of clarity and support, I'll put it in my own words anyway!

I strongly agree that FFmpeg's features should not get "lost" by any
change/merge/etc., and the sheer number of them makes it very
impractical to start with anything but the FFmpeg code.
I do understand that this will be a point of contention, as there
certainly is a bunch of ugly among the features, and we can/should use
this opportunity to clean up a bit.
Considering I'm one who has complained about silly dupes before, I
would of course be willing to help in cleanup efforts, be it duplicate
features or what have you that we feel would be a good point to clean
up/remove.

I also agree on defining a revised and clear process on how
development should progress in the future. I'm open to discussion and
I've seen various approaches myself, both in Open Source and Corporate
work.
While "design by committee" is generally used as a negative term, a
single point of failure is probably not a much better idea. There is a
few basic principles that any process should include, but we can
outline those in the future, to try to avoid the problematic cases
from the get-go.

Its probably known by now that I'm one to advocate API change for the
better of the project, but I do realize that we need a stable
middleground where everyone can agree.
Keeping stale API for ever is an extreme, as is dropping/changing API
on a whim, so something in between should be found, agreed upon, and
then uphold (and clearly communicated to downstreams).
There are still areas where drastic API changes may be needed to get
the libraries into a position where we are happy with the API, and
where it can reflect all the needs for new and existing codecs and
external libraries.

I don't have a very strong opinion on the bug tracker, I've seen
better and worse systems than trac, but keeping the existing issues is
probably a good idea - even if a lot of them are user support
questions and not actual issues.
For the name of the follow-up project, FFmpeg is probably the name
with the most recognition and renaming may cause an extra bit of drama
- but if thats what it takes to make everyone happy, so be it.

- Hendrik