On Wed, 7 Dec 2016 19:29:58 +0100 Nicolas George <geo...@nsup.org> wrote:
> Le quintidi 15 frimaire, an CCXXV, Rostislav Pehlivanov a écrit : > > I need more time to decide. > > You supported dropping ffserver since before the vote started, and now > you are hesitating? Seriously? > > Arriving at the last minute when it became obvious the tide turned to > ensure a longer delay. Where did I see that? This whole circus is > looking more and more like the libmpcodec travesty. > > Let us see where we are: > > drop James Almer > drop Paul B Mahol > drop Ronald S. Bultje (slightly invalid) > > keep Andreas Cadhalpun > keep Marton Balint > keep Michael Niedermayer (slightly invalid) > keep Nicolas George > keep Reynaldo H. Verdejo Pinochet (slightly invalid) > > spoilt wm4 Incorrect. > blank Lukasz Marek > > Well, for now, you cannot remove ffserver. You can continue discussing > if you want. > > For the people who want to actually move forward, I suggest the > following guidelines: > > For any fringe component of the project, ffserver or anything that shows > the same issues in the future: > > - There is a problem if, during the course of development, either: > > 1. the component is present in the default execution path of the > important tools (at probing, for example) and that causes execution > bugs; > > 2. the component causes a compilation failure with default / > reasonable options. 3. It's entangled with the rest of the project and stops people from doing useful work. It's awesome how you just ignore this point. I'll give you the benefit of the doubt and will just assume that you actually don't know why we want to remove ffserver. Removing unneeded stuff works much better for development as keeping everything forever. Proof: Libav. Without Libav, FFmpeg would still have no reference counted AVFrames, no simple way to do direct rendering (look at the old now-removed code ffmpeg.c used to enable direct rendering with libavfilter - it was horrible), advanced hardware transcoding (I'm still waiting for related work to be merged from Libav). So yes, removing things can mean progress. > - If there is no such problem, leave it alone and get working on > something useful! Nobody would care if ffserver actually used the ffmpeg libs correctly. But it still requires ffserver-specific code in libavformat. And even after all of michaelni's oddly-timed hard work to cleanup ffserver, ffserver itself uses internal libavformat stuff (see libavformat/libavformat.v - it also includes internal headers). > - If you are hit by one such problem, then: > > 1. Make an honest attempt at fixing it yourself. Emphasis on the word > "honest". So "we" are supposed to fix ffserver? This is where feature bloat slows down development. I think those who want to keep a feature should work for it. Where are YOUR patches to fix ffserver anyway? > 2. If that proves impossible, post the description of the problem on > the mailing-list and demand the maintainers to fix it. If necessary > (depending on the urgency of your own development, the availability > of the developers), set an ultimatum, even with a short deadline. This was done. The deadline was even extended. Nobody made any notable progress. The promise that ffserver would get fixed in time was disappointed. This is why we call for moving ffserver out of the master branch so we can go on. Only michaelni has made significant progress on fixing parts of it recently (after having watched from the sides for months). > 3. If the ultimatum expires, disable the component. Disable, not > remove: that is what requires the least amount of work from you, > and also what will require the least amount of work from the > maintainer later. We ALREADY announced ffserver removal for the current release (and then delayed it). What you demand all already happened. What a joke. > 4. If the component has been disabled for some time, then we can > discuss removing it. We've discussed it for months. Where the were you? I guess if you'd actually made any sense, you'd advocate disabling ffserver NOW. > The short version of it is: > > If you do not LIKE a component, IGNORE it but do not HATE it. It's hard to ignore something if it hinders your progress. Do you think we started about talking removing ffserver just because we wanted to be mean? > Hate is what spoils the ambiance in projects. This project is frustrating because it puts features (even broken, half-implemented ones) over robust implementation and ease of use, and on top of it is unable to enforce any policy or decisions the community may have made. You have to waste your time discussing about nothing to overly... self-confident... people when trying to make a change. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel