[FFmpeg-devel] Gathering opinions from FFmpeg developers about a reunification with Libav developers
george at nsup.org
Sun Sep 6 11:27:08 CEST 2015
Le quartidi 14 thermidor, an CCXXIII, Clement Boesch a écrit :
> 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.
Speaking for myself, I think a reunification would be a great relief.
> - Using the current FFmpeg source code as the code base for the common
Losing four years of work would be absurd.
> - After we come to an agreement, both FFmpeg and Libav must freeze their
> respective repository.
Why freeze? Merging them and keeping them in sync seems like a better
solution, at least for a time.
> - 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 believe a leader (or small leading committee) is necessary, and I think
the recent discussions, from requiring pkg-config to the ABI compatibility
question, illustrates the lack of thereof.
It is not possible to have everybody happy with every decision, but
everybody will be happier if the decision was made by a process they respect
rather than being bogged down by whoever has more time to argue.
> 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.
What you write has merit, but I find merit in libav's enforced review.
Several times, I have marked a patch in my inbox to comment when time
permits, only to find that by the time I can come back to it, it has been
approved by someone else and pushed.
With Git as our main working tool, waiting to push a commit is not really a
problem. If this really a patch for code only you know, then you can push
now or in two months, it makes no difference since nobody else will create
conflicts. And if there are conflicts, that means someone else is changing
the same part of the code, their comments would have value.
There is probably a technical help possible for that issue. Libav uses an
online tool called patchwork, IIRC, maybe it has merits for managing
commits. Imagine: incoming patches go in an automated queue, developers can
approve patches in the queue, or put them on hold to comment them; when a
patch is approved, it undergoes a round of automated testing, including the
annoying ones (proprietary toolchains) and the long ones (valgrind) and is
then pushed to the final repository.
> - 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.
I agree that the FFmpeg name has gravitas and must be kept. But just keeping
the name may give the impression that we "won", and go down badly with some
libav developers. Since libraries are almost all called libavsomething,
calling the project "FFmpeg/libav" or "libav/FFmpeg" or something would make
sense; and of course, like "Debian GNU/Linux", people will eventually call
it whatever they want.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel