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

[Steven Liu]

2016-11-30 23:29 GMT+08:00 Nicolas George <george at nsup.org>:

> 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
> yet.)
>
> 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
> negatively.
>
> 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.
>
> Regards,
>
> --
>   Nicolas George
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Maybe open a ffserver project is a better way,
A Server project , support every thing use ffmpeg libav*,
So if there have a project, maybe drop ffserver from ffmpeg is a good idea,
but if there have no project or a server ,maybe users need a demo to
reference.