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 1BB11482AD for ; Wed, 20 Dec 2023 19:12:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CD3E168D228; Wed, 20 Dec 2023 21:12:06 +0200 (EET) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id A378C68D015 for ; Wed, 20 Dec 2023 21:12:00 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id A067820002 for ; Wed, 20 Dec 2023 19:11:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1703099519; 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=t2JW4qhnq0YAdgLTbVpihdeNbFM95jPhK3CvgGjnyL8=; b=kdMcFeze3Yaf7L60VP1DCdGJkfkGL+CKyJ5bU7HYsy+UOZugrsc5Ll1K7c0mPCenhKrXRo NwVN5Q/pWsdUNcgGgLwvu45IxVBiBoD3/etIsEzOnlB4RPq7PdnL//c//k84NZZLAzlPTS rqNDl4kcAw+L4FecxgHGlTo9FOa+Vfug5uz2903f75YSG7IKhtjOSDgL8uZ1Av3YV/fKzK Y+U0vsYYG0EM6wwoW71PriY4p9HILolhOYw89A3rxbGtpDYhSLkz+WXEbLGqivGttdQBkT xosOwNmp8mJQM3GNBeMcQXLnxDU7YB8w8mYMc0d11W3za4699Bkxfrn+dC3GCA== Date: Wed, 20 Dec 2023 20:11:58 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20231220191158.GA6420@pb2> References: <20231202155352.4680-1-anton@khirnov.net> <5211be404405e6d454d7d48e385d6057d1ea21d6.camel@haerdin.se> <584f952e5d3a56615f12426276bc1d05f81a0e49.camel@haerdin.se> MIME-Version: 1.0 In-Reply-To: <584f952e5d3a56615f12426276bc1d05f81a0e49.camel@haerdin.se> 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="===============6641694386958049973==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============6641694386958049973== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jsn5+Lu/ZvzbAGtZ" Content-Disposition: inline --Jsn5+Lu/ZvzbAGtZ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas H=E4rdin wrote: > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George: [...] > [...] , but every line of code > carries with it a non-zero maintenance burden Assuming you mean with "non-zero" a "larger than zero" maintenance burden then we can proof this to be false First we need to define what you mean by "maintenance burden" ? There are a few ways this could be defined A. the absolute number of hours all developers need to spend to maintain some sort of stable quality B. the number of hours on average a FFmpeg developers need to spend to maintain some sort of stable quality (A favors 9 hours over 10 hours even if the 10 hour case has 2 devlopers available but the 9 has only 1. While B favors the 10/2 over 9/1) C. the number of hours of work noone really wants to do, FFmpeg developers = need to spend to maintain some sort of stable quality (again we can do this as all or per developer) (the idea of C is that we count work that people dont like to do with more = weight) (and there are many more ways to define it ...) Now the sketch of a proof :) Consider all the code related to "--help" code related to printing the version and build. Code printing where to send bugreports/samples. Also all formating maybe ;) or even some random check here or there. The "maintenance burden" in all definitions will worsen as the code becomes less readable, less well documented or as things related to maintaince are removed But its more than just this i think. * If you remove code that some comnpany or major user needs, and who pays f= or maintaince than removial of even complex and hard to maintain code can actually be negative and similarly adding complex code can actually be positive maintaince wise. IF it also results in additional resources becoming available for maintaince. (this can be a developers time or a companies money or other) * In the same light both merging and spliting code can have an impact on maintenance burden. For example if you have a group of developers who are unable to work together, them spliting up in 2 forks and a 3rd merging th= eir work together avoiding their inability to agree can reduce burden on both OTOH if 2 groups can join and work together the sharing of resources and = such can free up time and reduce maintaince burden What iam trying to say is, the maintaince burden resulting from a change is complex In this specific case here we have a patch proposing the removial of a deco= der missing a test. Its easy to say the burden is less when the decoder is removed But its author recently left the project too [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. --Jsn5+Lu/ZvzbAGtZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZYM8ZQAKCRBhHseHBAsP q4lVAJ0ausYavnnA+u9AWxISgwMxl/sYAgCfWITgxnwFGQqPvEktkAKqF8nt6oA= =pjMB -----END PGP SIGNATURE----- --Jsn5+Lu/ZvzbAGtZ-- --===============6641694386958049973== 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". --===============6641694386958049973==--