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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
