From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 2BDC249762 for ; Mon, 19 Feb 2024 01:17:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7A70F68D3B5; Mon, 19 Feb 2024 03:17:12 +0200 (EET) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8ADCD68D187 for ; Mon, 19 Feb 2024 03:17:06 +0200 (EET) Received: by mail.gandi.net (Postfix) with ESMTPSA id BA1B7FF804 for ; Mon, 19 Feb 2024 01:17:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1708305425; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=qx8Fq16kWwcopt9X/ZtYd1TWr42o+ADNW9+BWLwNXiw=; b=D0LOs/hj3iQjmOO0vxMyYs8vB008pdqY1W17g1/i0VxPeEBDwyH1nZKoHF288UrJDQrbmn Xn3bgGCl0EIl+xThwoHB9MCcb62ZJojBJMXrx+0s+iYud6aZ/vRGvCEA91GUrnAn/bt66e BRyqSBkKnVat+wVzMhAOgFSrDhhTLHBugzQY8IDM5docoufapy3+m+FsRN63ARzdG1s2XY 9/RFfjhGzg+MsFdLjTWUiGfDqsaqaN/W6wbYN4KvvVgHexktZVy8TVC5Zah3qR9F0UWX59 593MmOp/IQtxlKenEIv6rB+kv3rP1HMgWjsPlH6DKlliCa+e91bmEr2bivoSRg== Date: Mon, 19 Feb 2024 02:17:05 +0100 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240219011705.GR6420@pb2> References: <170807419472.21676.17214572018161936192@lain.khirnov.net> <6a46373c-3a6b-4490-9ae9-46d2a72a3e5a@gyani.pro> <170817255879.21676.17805665941049439864@lain.khirnov.net> <170819974399.21676.13449065399578350362@lain.khirnov.net> <20240218004314.GM6420@pb2> <170828044320.21676.10142270056126999587@lain.khirnov.net> <20240218223439.GP6420@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============5711970830620639506==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============5711970830620639506== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="X+179IfhW9ZxtqoP" Content-Disposition: inline --X+179IfhW9ZxtqoP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 18, 2024 at 11:48:59PM +0100, Hendrik Leppkes wrote: > On Sun, Feb 18, 2024 at 11:34=E2=80=AFPM Michael Niedermayer > wrote: > > > > * A disagreement implies that there are 2 parties > > * And we assume here that what one party wants is better for FFmpeg tha= n what the other wants. > > * The TC needs to find out which partys choice is better or suggest a 3= rd choice. > > * If one but not the other party is a member of the TC then this deciss= ion becomes biased if that member votes > > > > Your interpretation suggests that the TC members are "above" everyone a= nd should > > prevail in arguments they have with others. > > >=20 > Noone is above the rules, but just because someone has an opinion and > shared it shouldn't disqualify them, because they were specifically > voted into the TC for their opinions on technical matters. > Would their opinion, and therefore their vote, change if someone else > was seen as the person "blocking"? I think you are mixing the concept of an oppinion and blocking a patch. following is how i see the concept If you state that you prefer a linked list but dont mind the patch as it is thats an oppinion If you state that you prefer a linked list and i tell you that i would prefer to keep an array and you say you are ok, again thats an oppinion the patch is not blocked If you state that you prefer a linked list and i tell you that i would prefer to keep an array and you now tell me that if i want an array i have to go to the TC then you are blocking the patch. You and me in this case are the cause of the TC being involved. Only at this point we would be parties to the disagreement IMHO and we cannot be the judge here >=20 > What if multiple people had expressed disagreement with a patch, and > most of the TC was involved in the public discussion already? Do the The question would be who is actually blocking it and not just stating their oppinion. > remaining "uninvolved" people on the TC get all the decision power? Or > do we consider most of the TC already opposing it publicly as perhaps > an indicator that the patch might not be the way to go? > Thats what the TC was voted in for, to give their opinion on technical > matters and decide if needed, so why deprive them of their opinion, > just because they already stated it publicly? That makes no sense to > me. You certainly have a point but, again I think there are big differences between a TC oppinion and someone blocking a patch If a TC member states an oppinion and clearly explains the reasoning behind= it that should have no impact on the TC members ability to vote. In fact it sh= ould lead to all parties discussing and resolving the conflict probably without = the need to formally involve the TC IMHO, invoking the TC is already an exceptional situation and failure. and it shouldnt give the parties of that failure more influence in the deci= ssion. (which is another orthogonal reason why the parties of a conflict should not be judges of the conflict) Its really strange. You know, if a judge files a lawsuit, that judge cannot be the judge in that lawsuit. This is a very simple concept. It seems some people here see "their friend" not being allowed to vote but thats not what this is about. If a TC member blocks a patch, that TC member cannot vote on how to resolve that blockage. If a TC member chooses not to block a patch so he retains the power in a potential future vote. Thats a game theoretic decission he makes to maximize his blocking power. But really if he doesnt block it it could be applied so this is not a logic decission. The logic decission is to block the patch if thats what he wants and if noone else is blocking it. game theoretically the example you provide above would never happen as there would never be more than 1 TC member blocking a patch. So IMO arguing that a person should be party to a disagreement and judge of it. But making this dependant on an argument where people have to act in an illogic way is really odd thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus --X+179IfhW9ZxtqoP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZdKsBwAKCRBhHseHBAsP q2BWAJ49D/GXdp28Qhfmr4TNe8DZjqh5jQCfcpg2wjiyNhSkahrqQgKM5edwAFo= =nsOB -----END PGP SIGNATURE----- --X+179IfhW9ZxtqoP-- --===============5711970830620639506== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============5711970830620639506==--