2016-11-30 23:29 GMT+08:00 Nicolas George <geo...@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@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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
