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 6EDFE44EFA for ; Tue, 26 Dec 2023 12:58:20 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B860E68CBBE; Tue, 26 Dec 2023 14:58:17 +0200 (EET) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4624468BCEC for ; Tue, 26 Dec 2023 14:58:11 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id 777FB40002 for ; Tue, 26 Dec 2023 12:58:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1703595490; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3GfwQc78o4D/OH1RFU+qc7Z0GsEaNR6BudcF6RokKLQ=; b=LiZeAkaok2+t3Eu/OSEZnf60DYHvPgE4dgPdouORSd4SSEkIn1SONWNn5MpR9RBPeGCWk/ nI36svkTrAv7HZErH5Bzor39ci4c0YajlqGK6FFsWBQsdLef6Zm2dYS+lUhXkqRTpsM/s4 vlcMuiVqdjGAG91yOmVexv1qnox2AlNVO3YZVJwrWfAUsqVsVnQLeyDF04tU91PuWe364G NWVAeEEx/qif1YGCtOQDhLh8kWOJok1jC37z75denjTnL9nE6KRjE15dkD9k7cdyBphskK 2OB4axPQ/u9mK3TPJVoE4ENmyKYu39h/4IMuadH4RHb7d5Rd30WHwzQplxUK0g== Date: Tue, 26 Dec 2023 13:58:09 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20231226125809.GS6420@pb2> References: <5211be404405e6d454d7d48e385d6057d1ea21d6.camel@haerdin.se> <584f952e5d3a56615f12426276bc1d05f81a0e49.camel@haerdin.se> <20231220191158.GA6420@pb2> <55c8f48079b6956621df72c0e230037ba20be286.camel@haerdin.se> <20231222033250.GG6420@pb2> <2aa1a8b9-4b9c-477b-87d4-90dbb4ea6dd3@gmail.com> MIME-Version: 1.0 In-Reply-To: <2aa1a8b9-4b9c-477b-87d4-90dbb4ea6dd3@gmail.com> X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder 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="===============4199823539233572989==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4199823539233572989== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qoa3+4LHNtB0VmQh" Content-Disposition: inline --qoa3+4LHNtB0VmQh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 25, 2023 at 11:22:40AM -0600, Leo Izen wrote: > On 12/21/23 21:32, Michael Niedermayer wrote: > >=20 > > Can you think of a way to add some lines of code to this that makes it = more maintainable ? > >=20 > > if yes, then i think you proofed that adding code can reduce maintaince= burden > >=20 > > thx > >=20 >=20 > This is clearly not the point here. The point is that an in-house module = has > to be maintained, and removing that module removes the maintenance burden. > An international obfuscated C contest entry isn't really on-topic. You snipped the whole discussion this was a reply to and argue in a differe= nt context. The claim was: > > > [...] , but every line of code > > > carries with it a non-zero maintenance burden And the text you replied to was part of sketching a proof that the claim was false. If you make a different claim, yes, you need a different proof. So what is the new claim ? "The point is that an in-house module has to be maintained, and removing that module removes the maintenance burden." This is true, IF you ignore that "removing that module" has lead to loss of developers, should lead to loss of users and also a higher burden on the end user, who then may have to compile various external dependancies and maintain these with security updates. OR maybe the end user would have to choose between 2 forks depending in what feature she wants. If one, for sake of argument would say the removial of any module would be good, then the optimum is 0 modules. Thats clearly not optimal so that would be abusrd So we know removial cannot always be optimal. That also means it must be a good thing sometimes to have what you call additional "maintenance burden" thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle --qoa3+4LHNtB0VmQh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZYrN3gAKCRBhHseHBAsP qwIhAJ9HgmGnXsqt9e6fL7UI8M/9qogRkQCeJmpOk62aNFlP4lqVLkY09baI32k= =+eOy -----END PGP SIGNATURE----- --qoa3+4LHNtB0VmQh-- --===============4199823539233572989== 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". --===============4199823539233572989==--