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

[Stefano Sabatini]

On date Saturday 2015-08-01 11:18:34 +0200, Clément Bœsch encoded:
> 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.
[...]
> Anyway, this is a call for other FFmpeg developers, please share your own
> feelings about this.

I agree with keeping the FFmpeg codebase as the master of the new
reunified project (which I think is the only really viable solution
and the only strong condition "FFmpeg" should set).

Keeping also the name "FFmpeg" would be a good point since it will
reinforce the old and renokwn brand.

Commit policies and decision process can be discussed, and the FFmpeg
maintership model can be amended in order to accomodate the needs of
developers coming from Libav if they want to come back. I don't think
there is a real need for a freeze at this point.

BTW I'm going to summon an IRC meeting this Saturday, so these things
can be discussed online before the real-life meeting at VDD.
-- 
FFmpeg = Fanciful and Foolish Meaningful Practical Earthshaking God
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Nicolas George]

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.

>   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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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  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
>
> 

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

[Alex Beregszaszi]

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

I haven't been active on FFmpeg for many years now, yet I still follow
the discussions as my time allows.

I would question the whole merge:
1) To me it seems that libav has a smaller contributor and code base.

2) My gut feeling is that many of the new contributors come to libav
because they have found it in their distribution. As of now Debian and
Gentoo has switched back to FFmpeg. I would believe this source of
contributors would see a decline in libav.

3) Given Michael is stepping down, that should be an incentive for
those who are not contributing to FFmpeg directly because of him (if
such contributors exist) to reconsider their choice.

4) Do you want to have the same rules in FFmpeg as in libav? If not,
my gut feeling is that the original libav authors won't switch back,
i.e. libav would continue to be developed separately.

Long story short: my point is that it might not be needed to do an
official freeze and merge. Invite and welcome developers from the
other side.

Best,
Alex
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Carl Eugen Hoyos]

Clément Bœsch u at pkh.me writes:

 - 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 do not have access to all samples, so there may 
be a handful of bugzilla entries that are 
reproducible with FFmpeg but missing in trac.

 Lowest:
 
 - I think keeping the FFmpeg name is important

I also think that this is important and therefore 
not lowest priority.
=-)

I agree with what you have written at least to a 
large degree. The reason it feels difficult to be 
more specific for me is that most things sound 
quite hypothetical here.

Thank you for the effort, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Michael Niedermayer]

On Sat, Aug 01, 2015 at 07:05:21AM -0400, Ronald S. Bultje wrote:
 Hi,
 
 On Sat, Aug 1, 2015 at 5:18 AM, Clément Bœsch u...@pkh.me wrote:
 
  - 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.
 
 
 I've worked on both, so I can find some time and merge each, when a
 reunification happens based on our codebase. The outcome will be one prores
 enc/dec and one resampling library, which is a superset (in terms of
 features and performance) of the individual components. The alternates will
 exist under an ifdef for a while, while they undergo the deprecation
 process as is usual. Eventually they disappear.

If people want, i can help with merging duplicated features
i did the j2k/jpeg2000 decoder merge which IIRC also found its way
into Libav
But i am also happy to stay out of this if people think that would be
better

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Alexander Strasser]

On 2015-08-01 11:48 +0200, Hendrik Leppkes wrote:
[...]
 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.

  Just curious. Why do you think that many of the issues are
user support?

  I am following all changes to the bug tracker and I do not
have that impression. More the opposite, clear support questions
are closed quickly and the reporter is pointed at the -user ML.

  Having said that, I think we should always give the reporter
the benefit of doubt. That's how it is done mostly. Usually
reporters are asked if doing X resolves their problem and if 
yes the issue is closed. Often in the progress bugs and usability
issues are found and fixed. I think it's very important after all.

  Anyway, this is really getting off-topic, so maybe a new
thread should be started if you have serious concerns.

[...]

  Alexander


pgp36SKgZrBkP.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi,

On Sat, Aug 1, 2015 at 5:18 AM, Clément Bœsch u...@pkh.me wrote:

 - 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.


I've worked on both, so I can find some time and merge each, when a
reunification happens based on our codebase. The outcome will be one prores
enc/dec and one resampling library, which is a superset (in terms of
features and performance) of the individual components. The alternates will
exist under an ifdef for a while, while they undergo the deprecation
process as is usual. Eventually they disappear.

If the point of deduplication or merging of the two codebases overall comes
up (basically similar to the above, comparing the two codebases for various
modules and deciding if features/sections need (re-)merging), I'm happy to
be one of the people involved in the process. An example could be
re-splitting ffvp9 in multiple source files.

As for merge conditions, I'm open-minded and think it'll benefit both
projects, as well as our end users. I'll write down more details sometime
later. I'm willing to add sweeteners (like: set aside time to write
particular features) as a bonus if a merge happens based on our codebase.
An examples would be to merge all openhevc optimizations (properly
rewritten in yasm) in ffhevc, or something like that. This is a huge
project (ask James/Christophe), so don't take this lightly. :)

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[James Almer]

On 01/08/15 1:03 PM, Michael Niedermayer wrote:
 On Sat, Aug 01, 2015 at 07:05:21AM -0400, Ronald S. Bultje wrote:
 Hi,

 On Sat, Aug 1, 2015 at 5:18 AM, Clément Bœsch u...@pkh.me wrote:

 - 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.


 I've worked on both, so I can find some time and merge each, when a
 reunification happens based on our codebase. The outcome will be one prores
 enc/dec and one resampling library, which is a superset (in terms of
 features and performance) of the individual components. The alternates will
 exist under an ifdef for a while, while they undergo the deprecation
 process as is usual. Eventually they disappear.
 
 If people want, i can help with merging duplicated features
 i did the j2k/jpeg2000 decoder merge which IIRC also found its way
 into Libav

I doubt anyone would reject your help, really. Your work with bug fixing has 
been
outstanding, and I'm sure you enjoy working on things like j2k, swr, h264, hevc
and such much more than doing daily merges.

 But i am also happy to stay out of this if people think that would be
 better

I want to believe that wouldn't be necessary. One would hope stepping down from
the leader position should be enough to start talks about a project 
reunification,
but in any case the following weeks will tell.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [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...@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