Josh de Kock (2018-04-26): > It's also not impossible, nor irrational to be removing code which > doesn't fit or could be written better if an alternative is provided, the > need was never there or removal can otherwise be justified.
Then justify. But you will need to address all the arguments that were given three years ago. The policy of this project has always been that for its core features it must not depend on external libraries, apart from system libraries. What exactly constitutes a "system library" is up for discussion, but in this particular case there is no doubt. What constitutes a "core feature" is also up for debate, but ffserver have been part of the project for much more time than not, have many users that are upset by its removal, and was only removed because the code was an obsolete mess and nobody had the courage to rework it. It seems unambiguous to me that ffserver IS a core feature of the project. I will add two considerations: First, the actual objections to having an HTTP server in the project are about the maintenance burden, are they not? In that case, it seems to me that the most weight in the decision should be given to people who have an accurate idea of what it involves. So I ask: Do you consider yourself skilled in network programming? Are you familiar with the RFCs describing the HTTP protocol? Have you in the past implemented HTTP servers? Second, the habit of endlessly going back on past decisions is really hurting the project. I know I have several ambitious goals for FFmpeg, including a fully-typed option system with minimum string escaping. But under the current conditions, there is no way I would ever start working on them: we could decide today that the goal is worthy, but by the time the first batch of development is done, some people will start bieshedding it to death, and if it ever gets applied they will start yapping "revert, revert" each time it causes a tiny bug. Speaking for myself, I can say this: I will not perform anything more than basic maintenance on code under my responsibility as long as this project has this "one step forward, two steps on the side, one step backward" mentality; that would be a waste of my time. So if you think that my past work (especially the rework of the lavfi scheduling) had merit, you should help finding a solution. Electing a leader that can make final decisions and give the project direction (no steps backward) would be one. I will finish by saying the same thing in a shorter way: Shut up, work and let people work. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
