Tomas Härdin (12023-07-24): > Features either are or aren't in scope. I don't see how you can > compromise on that.
The scope is what we decide it is, collectively, based on arguments. Your conception of the scope is only a small part of that, and even smaller if you cannot sustain it with arguments. “I don't see how you can compromise on that” is called dogmatism and has no place in this project. The way I see it, avradio has about as much or as little its place in a project that historically contained software implementations of the major and minor multimedia codecs as hardware acceleration. Yet support for hardware acceleration has been added, to the convenience and satisfaction of everybody. > The Linux kernel also has separation of concerns. It has a concept of > userland for example, unlike say TempleOS. Not everything is in scope > for the Linux project. Yet features have repeatedly made back and forth between kernel and userland and mixed implementations, searching for the sweet spot of compromise between performance, security and convenience. Proof that “the scope”, even when there is a much more clearly delineated frontier, is fluid and a matter of compromise. If you cannot accept compromise, then your opinion should not be taken into consideration in a functioning collective project. > I have 63 forks of ffmpeg alone. I don't see the problem. I am doubtful whether this is to be considered a good thing or a bad thing, but I am rather leaning towards bad. > As for me being loudest, someone has to be. As a licensed amateur radio > operator I also happen to have domain knowledge, which is why I know > radio stuff will affect the code in profound ways, as we are already > seeing evidence of. These are hard-gotten learns. Well, if you are right, then we will see patches on the mailing list that will affect the code in profound ways, and you will be able to object to them then. But far from “already seeing evidence” of the apocalypse you predict, we see that the avradio code already delivers features while being self-contained and only required extending the signal processing abilities of our libraries a little, and in ways that are useful to other developers. So I guess it proves being licensed to operate something does not make you qualified to evaluate the difficulty in implementing the software of that thing. What a surprise. I will add that “affect the code in profound ways” was actually true for hardware acceleration, requiring a big mess in the code and significant to the internal API and even public API and user interface. Yet nobody is objecting to them. -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
