Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder
Date: Tue, 26 Dec 2023 13:58:09 +0100
Message-ID: <20231226125809.GS6420@pb2> (raw)
In-Reply-To: <2aa1a8b9-4b9c-477b-87d4-90dbb4ea6dd3@gmail.com>


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

On Mon, Dec 25, 2023 at 11:22:40AM -0600, Leo Izen wrote:
> On 12/21/23 21:32, Michael Niedermayer wrote:
> > 
> > Can you think of a way to add some lines of code to this that makes it more maintainable ?
> > 
> > if yes, then i think you proofed that adding code can reduce maintaince burden
> > 
> > thx
> > 
> 
> 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 different
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

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

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

  reply	other threads:[~2023-12-26 12:58 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-02 15:53 Anton Khirnov
2023-12-02 16:07 ` Paul B Mahol
     [not found] ` <42528A64-3630-4EBD-A2D2-A6A3E63709BB@cosmin.at>
2023-12-02 18:19   ` Cosmin Stejerean via ffmpeg-devel
2023-12-02 18:55     ` Paul B Mahol
2023-12-04 18:57       ` Jean-Baptiste Kempf
2023-12-04 18:53 ` Nicolas George
2023-12-05  4:21   ` Vittorio Giovara
2023-12-05  7:44     ` Nicolas George
2023-12-05 14:51       ` Vittorio Giovara
2023-12-05 14:59         ` Nicolas George
2023-12-05 15:42           ` Vittorio Giovara
2023-12-06 20:47             ` Nicolas George
2023-12-06 20:55               ` Vittorio Giovara
2023-12-19 13:57       ` Tomas Härdin
2023-12-19 14:02         ` Nicolas George
2023-12-20 16:57           ` Tomas Härdin
2023-12-20 18:05             ` Nicolas George
2023-12-20 19:11             ` Michael Niedermayer
2023-12-21 19:43               ` Tomas Härdin
2023-12-21 20:05                 ` Paul B Mahol
2023-12-21 20:31                   ` Nicolas George
2023-12-21 21:36                     ` Vittorio Giovara
2023-12-21 22:21                       ` Nicolas George
2023-12-21 22:37                         ` Vittorio Giovara
2023-12-21 22:41                           ` Nicolas George
2023-12-21 23:12                             ` Vittorio Giovara
2023-12-21 23:14                               ` Nicolas George
2023-12-21 23:24                                 ` Vittorio Giovara
2023-12-22  0:32                           ` Michael Niedermayer
2023-12-24  1:17                     ` Michael Niedermayer
2023-12-26 13:52                     ` [FFmpeg-devel] Mailinglist conduct [was: Re: [PATCH] lavc: remove the QOA decoder] Ronald S. Bultje
2023-12-21 21:38                   ` [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder Vittorio Giovara
2023-12-22  6:28                   ` Anton Khirnov
2023-12-22  9:28                     ` Paul B Mahol
2023-12-22 13:09                   ` James Almer
2023-12-24 12:10                     ` Tomas Härdin
2023-12-24 12:12                       ` Nicolas George
2023-12-24 13:23                         ` James Almer
2023-12-24 14:33                         ` Tomas Härdin
2023-12-24 14:47                           ` Paul B Mahol
2023-12-24 15:11                           ` Nicolas George
2023-12-24 17:21                             ` Michael Niedermayer
2023-12-24 20:55                               ` Tomas Härdin
2023-12-24 21:07                               ` Paul B Mahol
2023-12-26 22:20                   ` [FFmpeg-devel] Mailinglist conduct [was: Re: [PATCH] lavc: remove the QOA decoder] Ronald S. Bultje
2023-12-26 22:40                     ` Paul B Mahol
2023-12-26 23:53                       ` James Almer
2023-12-27  8:13                         ` Paul B Mahol
2023-12-22  3:32                 ` [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder Michael Niedermayer
2023-12-25 17:22                   ` Leo Izen
2023-12-26 12:58                     ` Michael Niedermayer [this message]
2023-12-06 20:49 ` James Almer
2023-12-07  7:17   ` Anton Khirnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231226125809.GS6420@pb2 \
    --to=michael@niedermayer.cc \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git