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

[Ganesh Ajjanagadde]

On Sun, Sep 6, 2015 at 2:27 AM, Nicolas George <george at nsup.org> wrote:
> 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.
>
>> Highest:
>>
>> - Using the current FFmpeg source code as the code base for the common
>>   project.
>
> 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.

I may be completely off here; but I got the impression that a lot of
the burden of the project leader was unnecessary and simply stressful.
I think that if we remove some of those "de-facto" responsibilities of
project leadership, more people (perhaps even Michael) might be
willing to become part of such a leadership committee. Here are some
ideas:
1. Merging from the fork should be handled by someone else willing to
take it up.
2. Security issues should be handled by respective maintainers
promptly, failing which someone in charge of security should do this.
The leader should rarely need to step in unless it is something with
project wide implications.

Please modify/add suggestions; the points above are meant to be minimal.

>
>>   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.
>
>> 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.
>
> 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.
>
> Regards,
>
> --
>   Nicolas George
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>