[FFmpeg-devel] [libav-devel] Common mailing-list for API evolutions

Alexander Strasser eclipse7 at gmx.net
Thu Aug 28 22:12:45 CEST 2014


On 2014-08-28 18:58 +0200, Anton Khirnov wrote:
> On Sun, 24 Aug 2014 00:28:56 +0200, =?utf-8?B?Q2zDqW1lbnQgQsWTc2No?= <u at pkh.me> wrote:
> > Kieran suggested tonight on #ffmpeg-devel to have a common mailing-list
> > between the two projects to start communicating again in sane terms.
> > 
> > The proposition would be a mailing-list where the 2 projects would send
> > the patches that will make API evolutions. So the projects can continue to
> > drop or add codecs & filters without caring about the other, but will try
> > to communicate more about the API, for the sake of our common users.
> > 
> > At first, I suggest that won't engage anything from any of the two
> > projects (so we don't end up in a stalled states such as one project
> > trying to block the other), but it could be seen as a way to introduce
> > some common technical ground.
> > 
> > What do you think?
> 
> While some kind of non-hostile coexistence or even cooperation is desirable and
> might even be possible, I have large doubts that this specific approach can
> work.
> 
> First, some of your project's developers (most importantly your leader)
> are being actively hostile to our project. That includes spreading FUD about us
> all over the internet, stalking our new contributors, etc. I do not think any
> kind of cooperation can work while this crap goes on.
> 
> Second, how do you propose this arrangement will actually function? As you
> probably know, I see many of the API additions done in your project as ugly
> hacks, and would be strongly opposed to having them in our tree in their current
> form. Conversely, some API changes done in Libav were AFAIK rejected by your
> leader. So -- what happens when one side proposes a change that the other side
> fundamentally disagrees with.
> And furthermore -- what would ensure that the code actually gets pushed to both
> trees. Because otherwise there really is no point to this.

  Please read what you wrote again; it is almost completely hostile
towards FFmpeg...

  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140828/8568342c/attachment.asc>


More information about the ffmpeg-devel mailing list