[FFmpeg-devel] [PATCH] Remove the ffserver program and the ffm muxer/demuxer

[Michael Niedermayer]

On Sun, Nov 27, 2016 at 05:31:39PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Nov 27, 2016 at 1:46 PM, Michael Niedermayer <michael at niedermayer.cc
> > wrote:
> 
> > On Sun, Nov 27, 2016 at 07:30:24PM +0100, Clément Bœsch wrote:
> > > On Sun, Nov 27, 2016 at 06:49:35PM +0100, Michael Niedermayer wrote:
> > > > On Sun, Nov 27, 2016 at 04:57:36PM +0100, Clément Bœsch wrote:
> > > > > On Sun, Nov 27, 2016 at 04:25:18PM +0100, Michael Niedermayer wrote:
> > > > > [...]
> > > > > > ffserver had 14 commits to it in about the last month
> > > > >
> > > > > That's also pretty close to the number of commits in the last years.
> > > > >
> > > > > Good will in the last weeks is not enough of a technical
> > > > > merit/justification to prevent the removal of junk code scheduled for
> > > > > deletion for a long time now.
> > > >
> > > > why do you call it junk ?
> > >
> > > because it's highly dependent on internal stuff, very limited, completely
> > > untested, unmaintained for several years but still contains a ton of
> > code.
> > >
> > > > and the sheduling for deletion was conditional on it not being fixed
> > > > IIRC.
> > > > Why the hurry to remove it while people work on fixing it ?
> > > > its not blocking anything ATM AFAIK
> > >
> > > There is no hurry, but piling up a bunch patches to fix small things just
> > > to use it as an argument to say "hey look now it's maintained" in order
> > to
> > > save it from being killed is really annoying. The people interested in it
> > > had years to act.
> > >
> >
> > > You can fix a ton of little things in it, but unless the fundamental
> > > problems are addressed (ZERO internal API usage + at least partial FATE
> > > coverage) it's pointless
> >
> > of course the goal is ZERO internal API usage + at least partial FATE
> > coverage.
> > Well in fact the lack of fate tests have been the primary reason
> > why i didnt fix some of the API issues years ago. I felt uneasy
> > changing it without regression tests
> >
> >
> > > and will be seen as yet another case of "KEEP
> > > EVERYTHING FOREVER" toxic mentality.
> >
> > The opposit is toxic too
> 
> 
> I'm perfectly fine with keeping the code, just not in the ffmpeg tree.
> Please move it to its own tree.
> 

> Everybody wants it out. Please follow majority.

Some people want it out yes, how many and what the majority want i do
not know.
Some people also wanted all tools treated equally and moved out (again
i dont know how many support that)

Spliting just ffserver out means more work for whoever maintains it
setting up seperate infrastructure, seperate coverity, coverage, fate,
...
theres a lot of work in all this, its long term continuous effort
and this is time that wont be spent on FFmpeg.

I dont know if people want me and reynaldo to spend less time on
FFmpeg, but time is a finite resource. If ffserver is maintained
externally it would mean a noticable hit in maintaince man hours of
FFmpeg. Now it might be that ffserver being pushed out would kill it.
But really as dumb as i am, i dont belive theres a majority who wants
to kill FFserver when there are people who actively work on it and
care about it.


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161128/602a7ef0/attachment.sig>