[FFmpeg-devel] [DECISION] Revoke the decision of dropping ffserver

[wm4]

On Wed, 7 Dec 2016 19:29:58 +0100
Nicolas George <george at 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.