On 9/8/2021 10:49 PM, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
James Almer
Sent: Thursday, 9 September 2021 03:34
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
On 9/8/2021 10:29 PM, Soft Works wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of
James Almer
Sent: Thursday, 9 September 2021 03:18
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH] Why does this break FATE?
On 9/8/2021 10:14 PM, Soft Works wrote:
Test seek-lavf-asf failed. Look at tests/data/fate/seek-lavf-
asf.err for details.
make: *** [/build/ffmpeg-git/tests/Makefile:256: fate-seek-lavf-
asf] Error 139
$ cat tests/data/fate/seek-lavf-asf.err
/build/ffmpeg-git/tests/fate-run.sh: line 78: 21786 Segmentation
fault $target_exec $target_path/"$@"
It's the same on both Windows/MSYS2 and Linux. Let's see how
patchwork results will be...
Please, don't send patches just to have patchwork run FATE for
you.
It
litters the mailing list. Do it locally.
As written above I _did_ run it locally on both Linux and
Windows/MSYS.
That was more than enough to know that the failure you saw was not a
fluke.
Might be true, but it doesn't seem right to me that this is happening
and submitting a patch for demonstration seemed to be an adequate
measure to present the issue.
Since we haven't had a release since the last major bump, we can
still
apply ABI (not API) breaking changes, if needed.
Based on the fact that requirements are strict about MINOR bumps and
mandating them to be included in the very commit that is requiring
the bump, I didn't expect that there's a different strategy for
MAJOR bumps.
A major bump is done once every few years to remove deprecated APIs and
open the ABI for changes. After a major bump takes place, there's an
"Unstable ABI" period where one can make such breaking changes (Altering
field offsets in public structs, adding new fields or changing their
types on structs that have their size tied to the ABI, changing public
enum and #define values, etc).
A single major bump should encompass every breaking change during this
short "unstable" period. In contrast, every new API addition requires
its own minor or micro bump.
Anyway - will use minor bumps, then.
Thanks,
softworkz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
