From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id DC33D47BC2 for ; Tue, 3 Oct 2023 19:23:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id C5C1C68CB3D; Tue, 3 Oct 2023 22:23:06 +0300 (EEST) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0437168CA9C for ; Tue, 3 Oct 2023 22:22:59 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 4848EC0008 for ; Tue, 3 Oct 2023 19:22:58 +0000 (UTC) Date: Tue, 3 Oct 2023 21:22:58 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20231003192258.GR5133@pb2> References: <20230707150654.GX1093384@pb2> <168889764928.542.505537875908829599@lain.khirnov.net> <20230922092754.GV8640@pb2> <169571962013.20400.259576230656271580@lain.khirnov.net> <20230926150947.GM3543730@pb2> <169574221973.6638.5162903459684406928@lain.khirnov.net> <20230926171630.GN3543730@pb2> <169575207748.6638.4929384189591808216@lain.khirnov.net> MIME-Version: 1.0 In-Reply-To: <169575207748.6638.4929384189591808216@lain.khirnov.net> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [RFC] Release 6.1 X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============7056759287023001758==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============7056759287023001758== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="abHgUoWNUdkkRBEn" Content-Disposition: inline --abHgUoWNUdkkRBEn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 26, 2023 at 08:14:37PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-09-26 19:16:30) > > On Tue, Sep 26, 2023 at 05:30:19PM +0200, Anton Khirnov wrote: > > > Quoting Michael Niedermayer (2023-09-26 17:09:47) > > > > On Tue, Sep 26, 2023 at 11:13:40AM +0200, Anton Khirnov wrote: > > > > > Quoting Michael Niedermayer (2023-09-22 11:27:54) > > > > > > The idea was really just, that i said ill include SDR and i wan= t to > > > > > > keep this word > > > > >=20 > > > > > Well, you should not have spoken for the entire project without > > > > > consulting the rest of the community first. Nobody here is entitl= ed to > > > >=20 > > > > This statement is a little misleading, i think > > > >=20 > > > > Iam part of the community, i would think and for 99% of the tweets = made > > > > on the official twitter account i have never been asked or even had= a > > > > chance to comment before they where made. So what you suggest here = is > > > > "the correct way", has never been applied. > > >=20 > > > This is disingenuous sophistry, and honestly I find it insulting that > > > you expect people to swallow it. > > >=20 > > > You made the tweet in question long after it was clear that the featu= re > > > is controversial. Then you tried to use it as an argument in favor of > > > pushing SDR to master. In other words, you used the fact that you have > > > Twitter posting rights to promote your opinion over that of other > > > developers. If that is not abuse of power then I don't know what is. > >=20 > > ok > > I wrote a SDR input device for free, wanted to give it to the users > > as i believed it was a cool and usefull feature > >=20 > > i tried to argue for it, i tried to promote it. > > And as the person doing all releases of FFmpeg since a very long time > > i thought yeah we will be able to resolve the disagreements and get it > > in 6.1 with everyone geing happy. > > I was wrong, i announced this before i actually got people to agree yes > > I still belive if people where not so "excited" on this whole and if it > > was just a technical question we could get SDR in 6.1 with everyone > > agreeing. > > But now heres a man to be burned at the stake, and thats more important. >=20 > You keep framing this as some kind of a personal campaign against you. > It is not. From my perspective, the objections to SDR have been largely > technical, and most of the "heat" comes from your refusal to accept that > many active developers are against it. Technical arguments ? Yes, several people had technical arguments, I remember Tomas and Remi and = some others. But at least subjectively i felt that the bulk of people where alot= more emotional than technical But let me list a few observations, from memory First objection was because processing is done in an external library. Then it was found out that was wrong and actually processing is done in the= new code so the objection flipped and people demanded it to be moved into an externa= l library. If you object to pink and want blue and when you find out its actually blue= you have to be happy and become a supporter but what happened was the opposit, the o= bjection was simply adjusted to object to whatever was the case and demand whatever = was not. Ok so thats at least one developers "Technical objection" down here, maybe = more i dont know if anyone else expressed that same initial objection. but lets = move on In all cases we prefer not to have external dependancies, this is the Techn= ical position of FFmpeg no, there is no technical argument in this. Also personal preferrances of people is not a technical argument. Noone exp= lained why a avdevice module with more external depandancies would be ok but a avdevice = module with fewer external depandancies was not. <-- This last sentance is a technical = argument I could go as far as call this a proof by contradiction. If people are happy with a avdevice module and FFmpeg prefers fewer externa= l dependancies then my suggestion of first starting with a plain simple self contained avd= evice/avformat module, would have to be fine too. We can always move this to an external library once there is a technical re= ason for that like for example some other software wants to use it About the attack/rallying/compaign stuff. Ill keep it very brief as its not= useful i think. Also this is my own personal and subjective view. In fact the whole mail is There was alot of (negative) emotion from 1-2 people about SDR. This emotio= n was what spread slash rallied other developers. That came before any technical arguments. Now people have picked their flag and march to war. Everyone will deny it, same as every patriot will fight to the death for th= e colors of the flag of the country and religion they where born into. My claim, sorry to be stubborn, is that had this started a slight bit diffe= rent there would be little opposition to SDR. Iam not denying that now there are sever= al people against it. thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart than the original author, trying to rewrite it will not make it better. --abHgUoWNUdkkRBEn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZRxqDgAKCRBhHseHBAsP q+NHAJ97gVp2PPbGhmyoYZKAtkZfBYC7sACeM3AvZWmbNR43QX2qhqfkwOp4Oyg= =D3TR -----END PGP SIGNATURE----- --abHgUoWNUdkkRBEn-- --===============7056759287023001758== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". --===============7056759287023001758==--