1 |
Alexis - thanks a lot for the awesome response! |
2 |
|
3 |
Alexis Ballier wrote: |
4 |
> 'those who are right' |
5 |
|
6 |
(Just a note that I am in no way invested in libav/ffmpeg, I merely |
7 |
speak from experience with another fork.) |
8 |
|
9 |
|
10 |
> However, as I said, maybe with an incorrect tone, I do not think |
11 |
> libav ignoring what happens in ffmpeg to be a pragmatic attitude |
12 |
> and believe it is mainly hurting applications trying to do their |
13 |
> best in supporting both, and users wanting the extra bugfixes or |
14 |
> featues from ffmpeg or the better review process from libav. |
15 |
|
16 |
Thanks for clarifying that! And I completely agree with you. |
17 |
Especially with forks it's important to keep compatibility a |
18 |
high priority in all projects. |
19 |
|
20 |
|
21 |
> The critic was directed towards this, which I believe should be |
22 |
> orthogonal to the reasons of the split. |
23 |
|
24 |
Yes, I agree also with that. Separate issues. |
25 |
|
26 |
|
27 |
> Finally, I would really love to see some will in reopening the |
28 |
> discussions, |
29 |
|
30 |
I guess it was some years ago, but maybe some more time still is |
31 |
good. I know no details, I only recognize the pattern. |
32 |
|
33 |
|
34 |
> > For a long time I idealized open source as being an ideal community, |
35 |
> > where communication always worked because everyone wanted it to. But |
36 |
> > that's unfortunately not at all the case. |
37 |
> |
38 |
> Yep, thanks for shaking me on this, it seems I should reread twice |
39 |
> before hitting send on an email since I fell in the same trap. |
40 |
|
41 |
It's easy. I did too. |
42 |
|
43 |
|
44 |
> Again, apologies if what I wrote has been taken personally, esp. to |
45 |
> those that tried their best to avoid the split. |
46 |
|
47 |
Not me - but if someone did feel bad about what you wrote I am very |
48 |
sure that they appreciate this! |
49 |
|
50 |
|
51 |
> > Quality is not a very helpful metric, because it means completely |
52 |
> > different things for different people. |
53 |
> |
54 |
> Quality here is: Everything that works with FFmpeg works with libav, |
55 |
> and vice-versa. |
56 |
|
57 |
Agree API compatibility is very important. |
58 |
|
59 |
|
60 |
> (and here, it seems the majority goes with libav) |
61 |
|
62 |
I for one am sadly uninformed and can not make a decision. :( |
63 |
|
64 |
|
65 |
> > Unless libav considers the API too broken to still be functional I |
66 |
> > don't see the point of differentiation. |
67 |
> |
68 |
> For distributors it does matter: if we start to have libav-only or |
69 |
> ffmpeg-only packages then users get the choice on what package to use, |
70 |
> not the implementation. |
71 |
|
72 |
Ah! Yes, but that is just a function of what happens upstream, and |
73 |
nothing that can ever really be a distribution's job to resolve. |
74 |
|
75 |
If anything, I think that incompatibilities showing through in the |
76 |
distribution can only help users become more informed about what |
77 |
happens upstream. |
78 |
|
79 |
It can be argued that they shouldn't have to be informed - but |
80 |
actually I don't mind that. It's good to be aware of what is going |
81 |
on even a few layers down. I know that this is not a very common |
82 |
attitude, but I think for Gentoo in particular it wouldn't be bad |
83 |
at all. |
84 |
|
85 |
|
86 |
> If there is a differentiation, then upstream decides what they |
87 |
> think is best and that's about it. It would not kill competition, |
88 |
> rather the contrary I believe. |
89 |
|
90 |
You're right that there would possibly be more activity in both |
91 |
projects if they were going fast in their own direction. On the |
92 |
other hand that fragments the user base (applications) and everyone |
93 |
is already invested in the common API, so I can understand that |
94 |
moving away from that also isn't very desirable. |
95 |
|
96 |
|
97 |
Anyway - good thoughts. Thanks again! |
98 |
|
99 |
//Peter |