[FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter

[FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter

[FFmpeg Technical Committee]

Hi,

Last year, Anton raised the conflict on his patch "lavfi: get rid of FF_INTERNAL_FIELDS", https://lists.ffmpeg.org//pipermail/ffmpeg-devel/2023-January/306102.html, to the TC to decide on.

At the time, the TC did not come to any conclusion on the matter. Recently, Anton raised the question again, and this time, the current TC managed to successfully discuss the matter and come to a conclusion.

The main arguments raised were about API consistency, prevention of accidental inclusions, as well as explicitness in marking a field as public or private. These advantages were deemed to be worth the trade-off of making access to private fields slightly less convenient.

The TC has voted on the matter, with 4 votes in favour of the patch, 1 vote preferring to look for other solutions, and Anton himself abstaining from the vote.

Therefore, the matter has been decided, approving the patch at hand.

Regards,
The FFmpeg Technical Committee
- Jan Ekström
- Mark Thompson
- Martin Storsjö
- Michael Niedermayer
- Niklas Haas
- 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".

Re: [FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter

[Nicolas George]

Martin Storsjo (12024-02-13):
> The main arguments raised were about API consistency, prevention of
> accidental inclusions, as well as explicitness in marking a field as
> public or private.

Too bad the committee neglected to ask for the arguments of the people
who opposed this. Like having a trial and not listening to the defense.

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

Re: [FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter

[Rémi Denis-Courmont]

Hi,



Le 13 février 2024 18:22:46 GMT+02:00, Nicolas George <george@nsup.org> a écrit :
>Martin Storsjo (12024-02-13):
>> The main arguments raised were about API consistency, prevention of
>> accidental inclusions, as well as explicitness in marking a field as
>> public or private.
>
>Too bad the committee neglected to ask for the arguments of the people
>who opposed this. Like having a trial and not listening to the defense.

Speaking as an elected member of another OSS project's TC, I believe that the experienced adult developers on the FFmpeg TC are perfectly capable of reading mailing archives and Trac comments as necessary. In fact, I think it is preferable that they stick to arguments made in public, rather than go out of their way to dig up private information.

Or to follow your metaphor, in a trial, the arguments are made before the jury in public sessions. The deliberations of the jury are kept private to shield members from external pressure.

I don't expect that antagonising the TC members will do you, and any potential future arguments of yours, much good.
_______________________________________________
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".

Re: [FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter

[Nicolas George]

Rémi Denis-Courmont (12024-02-13):
> Speaking as an elected member of another OSS project's TC, I believe
> that the experienced adult developers on the FFmpeg TC are perfectly
> capable of reading mailing archives and Trac comments as necessary. In
> fact, I think it is preferable that they stick to arguments made in
> public, rather than go out of their way to dig up private information.

So you are thinking that Anton did not summarize and polish his
arguments while submitting the question to the TC. Sure, let us believe
that.

> Or to follow your metaphor, in a trial, the arguments are made before
> the jury in public sessions. The deliberations of the jury are kept
> private to shield members from external pressure.

As a matter of principle, the defense has the last word.

> I don't expect that antagonising the TC members will do you, and any
> potential future arguments of yours, much good.

I have lost all confidence in both committees and consider the only hope
to save this project is if Fabrice reboots it.

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