From: Michael Niedermayer <michael@niedermayer.cc> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding Date: Tue, 20 Feb 2024 22:39:17 +0100 Message-ID: <20240220213917.GV6420@pb2> (raw) In-Reply-To: <170837863557.27417.16524845266170993956@lain.khirnov.net> [-- Attachment #1.1: Type: text/plain, Size: 4322 bytes --] On Mon, Feb 19, 2024 at 10:37:15PM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-02-18 23:34:39) [...] > > > > But I think it is reasonable that parties of a disagreement cannot be > > > > the judge of the disagreement. > > > > > > Why not? This is one of those truthy-sounding statements that does not > > > actually hold up to scrutiny. > > > > * A disagreement implies that there are 2 parties > > * And we assume here that what one party wants is better for FFmpeg than what the other wants. > > * The TC needs to find out which partys choice is better or suggest a 3rd choice. > > * If one but not the other party is a member of the TC then this decission becomes biased if that member votes > > This example is flawed in at least two following ways: > > First, you keep comparing TC members to judges in a legal system. As I > said above - in a paragraph you ignored - I do not think that is a > meaningful comparison. We have no law, TC members are not judges and > decide based on their experience and opinions. well, TC members make decissions, lets call them decission makers then lets see how that would look so if we had judges and law we seem to agree that a decission maker cannot be a party to the very disagreement she decides on. lets take away the law so a courtroom with 5 judges, deciding on a persons fate, no more law everyone can choose as they prefer. The judge accusing another man of something, can now be a judge of that case ? No, the removial of "the law" isnt making the common sense rule any less common sense so lets now not call teh judges "judges" anymore, and lets pick them identically to how TC members are picked Does this change anything ? The decission maker accusing another man of something, can now be a decission maker of that case ? No, the issue remains. A party to a disagreement cannot be decission maker in the disagreement. There is bias and if the goal is a optimal decission we want no bias. > > > Imagine a judge kills someone and judges himself innocent afterwards in a panel of 5 judges > > Second, in this example the judge in question has two roles in the > situation: that of a criminal who wants to avoid being found guilty and that > of a judge who is supposed to find criminals guilty. The interests of > these roles are in conflict, hence we have a conflict of interest. > > That does not translate to the situation we are actually dealing with. > My interests in my role as a patch reviewer and as a TC member are > exactly the same. There is thus no conflict of interest. i disagree A TC member who wants to block a patch and wants to decide if a patch should be blocked is in the same situation as a Judge who wants to sue someone and wants to judge that someone. Again, the judge being a party to a lawsuite cannot be judge in that lawsuite Similarly a TC member initiating a conflict cannot judge in that same conflict The TC member surely does the same thing in both cases, he wants something like blocking a patch. Similarly the judge also wants to whatever is the goal of his lawsuite And there are in fact more problems Consider this: Normally we have PartyA and PartyB in a conflict and then we have 5 TC members who look into that, both parties can argue their case in front of the TC (publically) and the TC then discusses and make a decission, possibly asking more people an so on But now the case here changes we have PartyA and PartyTC Theres a disagreement between a developer and a TC member The TC member is part of the TC and discusses with the other 4 members, he will support himself in all votes and potential private arguments. PartyA here has substantially worse chance to win even if PartyA is correct and has the better solution. Iam sorry but i insist that the TC member in this case cannot act both as a party to teh disagreement and as a member of the TC in the same disagreement. It is completely unfair to partyA in this example above, they are not on equal ground. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus [-- 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".
next prev parent reply other threads:[~2024-02-20 21:39 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-23 6:49 Gyan Doshi 2024-01-23 6:49 ` [FFmpeg-devel] [PATCH 2/2] fate: add tests for dolby_e decoding in s302m Gyan Doshi 2024-01-23 7:56 ` [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding Kieran Kunhya 2024-01-23 8:32 ` Gyan Doshi 2024-01-23 9:05 ` Kieran Kunhya 2024-01-23 14:50 ` Devin Heitmueller 2024-01-23 14:53 ` Kieran Kunhya 2024-01-23 15:04 ` Devin Heitmueller 2024-01-23 10:28 ` Nicolas Gaullier 2024-01-23 11:18 ` Gyan Doshi 2024-01-25 4:59 ` Andreas Rheinhardt 2024-01-25 7:11 ` Gyan Doshi 2024-01-25 13:17 ` Andreas Rheinhardt 2024-01-26 4:23 ` Gyan Doshi 2024-01-26 6:42 ` Andreas Rheinhardt 2024-01-28 10:54 ` Anton Khirnov 2024-01-28 21:29 ` Kieran Kunhya 2024-01-29 4:00 ` Gyan Doshi via ffmpeg-devel 2024-01-29 9:27 ` Nicolas Gaullier 2024-01-29 10:17 ` Gyan Doshi 2024-01-29 10:18 ` Kieran Kunhya 2024-02-15 10:47 ` Anton Khirnov 2024-02-15 12:31 ` Gyan Doshi 2024-02-15 16:10 ` Anton Khirnov 2024-02-15 16:47 ` Gyan Doshi 2024-02-15 20:26 ` Kieran Kunhya 2024-02-16 4:12 ` Gyan Doshi 2024-02-16 9:03 ` Anton Khirnov 2024-02-17 11:46 ` Gyan Doshi 2024-02-17 12:22 ` Anton Khirnov 2024-02-17 12:37 ` Gyan Doshi 2024-02-17 19:55 ` Anton Khirnov 2024-02-18 0:43 ` Michael Niedermayer 2024-02-18 18:20 ` Anton Khirnov 2024-02-18 22:34 ` Michael Niedermayer 2024-02-18 22:47 ` Vittorio Giovara 2024-02-19 8:45 ` Nicolas George 2024-02-19 14:15 ` Vittorio Giovara 2024-02-19 14:28 ` Nicolas George 2024-02-19 14:37 ` Vittorio Giovara 2024-02-19 14:41 ` Nicolas George 2024-02-18 22:48 ` Hendrik Leppkes 2024-02-19 1:17 ` Michael Niedermayer 2024-02-19 2:26 ` Vittorio Giovara 2024-02-19 2:07 ` Ronald S. Bultje 2024-02-19 21:37 ` Anton Khirnov 2024-02-19 21:54 ` Nicolas George 2024-02-20 21:39 ` Michael Niedermayer [this message] 2024-02-20 21:56 ` Kieran Kunhya 2024-02-20 22:07 ` Nicolas George 2024-02-18 18:50 ` Rémi Denis-Courmont 2024-02-18 18:55 ` Nicolas George 2024-02-18 4:06 ` Gyan Doshi 2024-02-18 18:03 ` Anton Khirnov 2024-02-18 18:40 ` Nicolas George 2024-02-18 19:03 ` Rémi Denis-Courmont 2024-02-18 19:11 ` Nicolas George 2024-02-18 21:06 ` Vittorio Giovara 2024-02-18 21:25 ` Nicolas George 2024-02-18 21:55 ` Vittorio Giovara 2024-02-19 8:54 ` Nicolas George 2024-02-19 14:21 ` Vittorio Giovara 2024-02-19 14:30 ` Nicolas George 2024-02-19 14:33 ` Vittorio Giovara 2024-02-19 14:34 ` Nicolas George 2024-02-18 19:02 ` Gyan Doshi 2024-02-18 21:46 ` Vittorio Giovara 2024-02-19 5:10 ` Gyan Doshi 2024-02-19 14:30 ` Vittorio Giovara 2024-02-19 15:39 ` Gyan Doshi 2024-02-20 3:02 ` Vittorio Giovara 2024-02-17 12:31 ` Rémi Denis-Courmont 2024-02-19 2:16 ` epirat07 2024-02-16 13:55 ` Andreas Rheinhardt 2024-02-17 11:44 ` Gyan Doshi
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=20240220213917.GV6420@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