Re: [FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter
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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter
Hi, Le 13 février 2024 18:22:46 GMT+02:00, Nicolas George 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-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter
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-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [TC] Decision on FF_INTERNAL_FIELDS in libavfilter
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-requ...@ffmpeg.org with subject "unsubscribe".
