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

James Almer jamrial at gmail.com
Mon Nov 28 19:18:31 EET 2016


On 11/28/2016 1:39 PM, Nicolas George wrote:
> L'octidi 8 frimaire, an CCXXV, James Almer a écrit :
>> I discuss project management. This is a late attempt at overriding a decision
>> from parties that didn't participate in the real decision making discussions.
> 
> Maybe they did not participate because they were busy working on the
> actual code.

Keep thinking that if it helps you sleep or whatever.

> 
>> This crap wouldn't fly anywhere else
> 
> Untrue.

I'm eagerly waiting for your results about overriding Brexit, or making other
projects override their decisions of dropping their SPARC and SH5 ports.

> 
>> That nobody will take the project seriously anymore. That nobody will believe
>> in any announcement anymore. That anyone will be 100% sure that with a little
>> lobbying and trolling they will be able to get away with absolutely anything,
>> including overriding old decisions.
> 
> I see. Then what about people who will be disgusted that FFmpeg is a
> project where positive development (fixing bugs) is overridden by
> negative development (removing things) just because the negative people
> are more vocal?

Tell me of all the negative things that happened after we removed all those
library wrappers, when we replaced SDL with SDL2, and many other examples of
old, obsolete, broken or otherwise unmaintained removed modules.

> 
> My wet finger, which I consider more accurate than yours, tells me there
> are many more.

And this is why nobody tolerates talking with you. You only enter a discussion
to remind everyone they are wrong and you're right.

> 
>> Malicious was the attempt at turning efforts of making the program capable
>> of living on its own into an argument against the reason why it must go.
> 
> How is it malicious?

Do i have to say it for a third or fourth time? I think you're better re-reading
my previous emails. It's pretty clear there.

You haven't yet answered my question about how it isn't a lie, for that matter.
You're fast to make new questions while avoiding those aimed at you.

> 
>> You're aware that we could have told Reynaldo that no, we don't want to give
>> him time to make it work standalone, and this patch would have been pushed
>> a week or two ago, long before you even realized this all was even happening?
> 
> And that would have been incredibly rude. I would not have supported
> that decision.

Exactly, it would have been rude to reject a request of that kind, which is
why it was not.

What's rude is what happened after that was granted, and how.

> 
>> That the decision was made, and there's no going back.
> 
> There is a French saying that I already quoted in this discussion: only
> imbeciles never change their mind. For all it being a saying, it is
> still very true.

Call me an imbecile if you want, but i'll see this project decision being
made effective.

Push that ffprobe demuxer if you want and you find no more oposition. Unlike this
it's not bound or limited by a project decision, at least until someone calls
a vote about it, so both going in or not are still options, and i lost interest
on it.

You're also welcome to post a patch reintroducing ffserver after it doesn't
depend on private API and the ffm* modules.

> 
> Making one's mind involves taking into account the state of affairs at
> the time and making a conclusion. If the state of affairs changes, then
> the valid conclusion may change too. Someone who keeps the old
> conclusion in this case is indeed an imbecile.
> 
> Well, for ffserver, the state of affairs just changed. Maybe it was a
> consequence of the old decision, so what? The old decision was valid at

Finally! Looks like i'm talking with a rational being that doesn't ignore
facts after all.

> the time, given the state of affairs then. But the net result is still:
> ffserver is now maintained, it no longer blocks the development of the
> rest of the project, therefore the correct decision is no longer to
> remove it.
> 
>> You could also add
>>
>> # November 29th, 2016, From now on, announcements from this project are
>> # worth as much as a copy of ET for the Atari.
>> #
>> # Thanks to the efforts of people that couldn't get over the fact they
>> # showed up late and that abused the goodwill of some developers, nothing
>> # you read announced here from now on is to be trusted.
> 
> You seem to have in your values system the axiom "keeping promises for
> the sake of keeping promises", as if there was a superior being
> rewarding that kind of consistency. A more correct axiom would be
> "keeping promises for the sake of the person to whom the promise was
> made".

I'm pissed of at how this shit was handled. Of all the attempts at twisting
development efforts towards an specific goal in an unacceptable way.

I do not take the abuse of trust and goodwill kindly.

> 
> You can try a poll on the users: "Considering the reasons to remove
> ffserver are now void, would you have us keep our promise and remove it
> now, or change our mind at the last minute and keep it?"
> 
> I have no doubt a huge majority of the users will answer: keep it.

Of course, ffserver, everyone wants it. I still remember the wars caused by
libav dropping avserver and Debian being affected by it. Or the massive
amounts of people that cried when the news entry was posted, or the many times
ffserver simply wasn't working and got some fix after hoards of users pointed
it out. Or the massive amounts of patches it got this year before November's
"Lets pretend this thing is maintained" batch.

> 
>> For things up to debate, sure. This is not the case.
> 
> What is this, if not a debate?

A waste of time for you, and work from my part to save the project more
embarrassment.

> 
>> No, those are the only options within the boundaries already established.
> 
> Changing the boundaries is always an option.
> 
> Regards,
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 



More information about the ffmpeg-devel mailing list