Re: [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 3070 bytes --]

On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin 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 for
  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 their
  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 decoder
missing a test.
Its easy to say the burden is less when the decoder is removed
But its author recently left the project too

[...]
-- 
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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".