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

Nicolas George george at nsup.org
Wed Nov 30 17:29:38 EET 2016

Le nonidi 9 frimaire, an CCXXV, James Almer a écrit :
> Seeing Nicolas is apparently very invested in ffserver, can we expect him to
> maintain it, improve and extend it if it were to remain in the tree? Or is he
> just fighting this fight to not remove code for the sake of not removing code,
> and will forget about it and expect someone else to deal with it if it starts
> bitrotting again?

You admitted you did not care about ffserver, yet you spend an awful lot
of time and energy fighting for its removal, probably as a matter of
principle. Am I not allowed to do the same? Double standards much?

I will take this opportunity to answer various points that lie all over
the place in the thread.

First, you complain that I called you a dictator. This was actually an
argument, and if it was taken as anything else I apologize. At the time,
you were trying to dictate what can be put to the vote. Democracy does
not work that way. Nowhere in the voting rules is there anything
preventing voting again and making a different decision. Just like any
parliament can revoke a law passed by its predecessors.

(As a side note, I would like to emphasize that no valid vote were cast

Second, you complain that I called you a imbecile. That is not true. I
called people who never change advice out of principle imbeciles. You, I
think, are only misguided. Let me explain.

Not changing advice as a matter of principle: imagine a doctor not
changing the decided treatment when new symptoms arise? a general not
changing the decided battle plans when new intelligence is known? a
prosecutor not changing the decided plea when new evidence is found? How
can any of these not be imbecile?

And surely, if someone were to offer a huge sponsorship to keep ffserver
in the project, including money, immediate good-quality patches for the
most urgent problems and a full-time developer for the rest, you would
at least consider changing your mind, would you not?

Never ever changing one's mind, whatever the circumstances changes, is
imbecile, there is no way around it. What you can argue, on the other
hand, is that in this particular instance, the circumstances have not
changed enough.

Because it all boils down to this question: have the circumstances
changed enough to warrant a change of advice?

You and others think that no. I think they have. Let us discuss that.

Some people argue that the recent patches fixing the most urgent
problems were only submitted because of the deadline. Maybe it is true,
I will no longer argue that point. But so what? How is it relevant?
Developers have a limited time: they will work on what they think most
urgent. A deadline change the urgency of things: of course, that will
change the priorities of the developers. What did you expect?

You, mostly, have argued that changing our mind would send a bad signal
to the users community. I do not agree. The users community knows how
Libre software works, they know we have limited manpower. I cannot
imagine anybody criticizing a change in that direction. Everybody will
agree that keeping it if it is possible is better than dropping it. Even
those who do not care about ffserver, because they will remember that it
can happen to a feature they care about just the same.

If you are still not convinced, look at what happens in Linux: the
kernel hackers spend their time changing their mind, deprecating a
feature that was introduced two versions ago, and then undeprecating it
on the next one, reimplementing something a different way, etc. Do
people complain? Yes, they do, when the changes affect their workflow
and they have to spend time to adapt.

The same goes for Google. They are endlessly starting new projects,
reattaching them to other projects, axing them, etc. Do people complain?
Again: only when it affects them negatively.

Keeping ffserver instead of dropping it does not affect anybody

Now, to the technical questions.

If ffserver is blocking or hindering the development of the rest of the
project, and if the people who care about do not fix it soon enough,
then dropping is acceptable. Setting a deadline for the fix is
acceptable enough.

As I understand things, ffserver used to access private APIs in a way
that conflicts with merges from the fork, and the patches that were
posted recently are enough to fix it. The reason to remove ffserver
immediately is therefore gone. If it is not enough, then of course the
previous paragraph still applies.

Clément requested "zero internal API usage" and "FATE coverage". I agree
that it should be the goal. But it should not be the condition for not
removing it now. Otherwise, it feels like "do this change that I want
right now, or I remove your code". We do not do that, it is not an
acceptable practice in Libre software development.

I ask to all the people who want drop ffserver to sincerely think about
their reasons for dropping it. As long as it is not obstructing you, why
do you care? Why do you care if it is in this repository or another? Why
do you care whether it has FATE coverage? Why do you care if it uses
internal APIs?

In theory, the more ffsomething programs we have, the better: more
involved developers, more testing for the APIs, more consistency in the
options, more convenience for the users. Of course, if there are too
many, it may become annoying on the mailing-list, but we are nowhere
near that.

And it is not just theoretic: if ffserver gets FATE coverage, it
automatically increases the coverage of libavformat's network protocols,
something that is sorely needed. And a maintained ffserver can become
the tool for even more specific coverage of the client side of the
network protocols.

As for moving it to a separate repository: what is the point? We lose
all the benefits of having it (extra contributors, extra testing), and
it introduce so much overhead, starting with the duplicate maintenance
of the build system, the options system, etc., that it is a sure way of
killing it altogether.

So I ask again: why do you want to kick ffserver out so much? The
technical reasons are gone. The image reasons are feeble.

It really looks like you want to punish the developers who care about
ffserver for the bad state of the code. "Your code is too ugly, go in
the corner with a dunce cap and come back when it is fixed." Even worse,
the bad code is not theirs: "you did not fix this old code fast enough,
go in the corner with a dunce cap."

Sorry, but this is not acceptable. Reynaldo is not at your disposal, and
neither are the other people who care about ffserver. They will work on
it eventually, but according to their available time. Unless it affects
the rest of the project, you have no authority to set a deadline on pain
of trashing their work.

It would be much better for everybody if the people who want to kick
ffserver out took some time, before answering to this mail, to think
carefully about their reasons, and see if the consequences are really
the good of the project or just satisfying a personal distaste.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161130/4491540c/attachment.sig>

More information about the ffmpeg-devel mailing list