Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Anton Khirnov <anton@khirnov.net>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: stop mapping text/plain attachments to AV_CODEC_ID_TEXT
Date: Wed, 08 Jun 2022 19:38:14 +0200
Message-ID: <165470989408.5088.14566997065698893831@lain.khirnov.net> (raw)
In-Reply-To: =?utf-8?q?=3CDM8P223MB03650A071143B1B0941BEBE7BAA49=40DM8P223MB?= =?utf-8?q?0365=2ENAMP223=2EPROD=2EOUTLOOK=2ECOM=3E?=

Quoting Soft Works (2022-06-08 17:38:31)
> > Tests. Lots of tests.
> > If any change in behaviour is a breaking change for you, then git commit
> > hash is the library version you should use.
> 
> Not any change, but for a change in output, I'd say yes. I mean - isn't that
> what FATE is checking? And don't you say "breaks FATE" when the an output
> changes?

We generally do not make hard guarantees about the output produced by
the libraries, otherwise almost everything would be a compatibility
break (e.g. adding support for previously unimplemented codec or
container features).
We only promise to make best effort to produce "sensible" output, where
"sensible" has no strict definition and is subject to discussion and
consensus among developers. In this case, I argued that previous
behavior was a bug and nobody disagreed so far.

"breaks FATE" is a shortcut, it means only that the output has changed.
That may be because a change broke something, but it also happens that
there is a legitimate reason for the output changing, then the test
references are simply updated.

> 
> After all, I'm still having a hard time in assimilating the logic and mindsets 
> here. I'm obviously coming from a very different background and certain things 
> just don't make sense to me, so I have to ask many questions, when I can't 
> believe it, I ask once again, and again and re-assure that it's really that 
> way that I can hardly believe. When the versions do not guarantee anything
> besides API compatibility, then there's almost not practical value in having
> them, because things can always go wrong no matter whether those versions
> match or not as you always need to test thoroughly. You would be able
> to rule out some combinations up-front, but that's it.
> Also, given that fact that matching versions do not guarantee anything of
> practical value, who would then still want to mix ffmpeg libs from different 
> Git revisions based on those version numbers? I can't compute this ;-)

API compatibility is of great practical value to many people. To the
contrary, I'd say that absolute output stability is far less important
to most our users.

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

      parent reply	other threads:[~2022-06-08 17:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-07 11:58 Anton Khirnov
2022-06-08  3:19 ` Soft Works
2022-06-08  3:45   ` Soft Works
2022-06-08  6:17 ` Anton Khirnov
2022-06-08  6:39   ` Soft Works
2022-06-08  7:09   ` Anton Khirnov
2022-06-08  7:43     ` Soft Works
2022-06-08  8:04     ` Anton Khirnov
2022-06-08  8:34       ` Soft Works
2022-06-08 11:29       ` Soft Works
2022-06-08 11:34         ` Soft Works
2022-06-08 12:16       ` Anton Khirnov
2022-06-08 15:38         ` Soft Works
2022-06-08 17:38         ` Anton Khirnov [this message]

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=165470989408.5088.14566997065698893831@lain.khirnov.net \
    --to=anton@khirnov.net \
    --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