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

[Clément Bœsch]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150801/2f0b7707/attachment.sig>