From: Vittorio Giovara <vittorio.giovara@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
Date: Mon, 19 Feb 2024 03:26:23 +0100
Message-ID: <CABLWnS_RvhfoeTz79EnPmH+U+rA4rsuapdj0GS+h3=E2cyJ7GQ@mail.gmail.com> (raw)
In-Reply-To: <20240219011705.GR6420@pb2>
On Mon, Feb 19, 2024 at 2:17 AM Michael Niedermayer <michael@niedermayer.cc>
wrote:
> On Sun, Feb 18, 2024 at 11:48:59PM +0100, Hendrik Leppkes wrote:
> > On Sun, Feb 18, 2024 at 11:34 PM Michael Niedermayer
> > <michael@niedermayer.cc> wrote:
> > >
> > > * 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
> > >
> > > Your interpretation suggests that the TC members are "above" everyone
> and should
> > > prevail in arguments they have with others.
> > >
> >
> > 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
>
>
> >
> > 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
> should
> 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
> decission.
> (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
>
i long for the day in which ffmpeg might actually seem like a functioning
community, where we would not constantly and needlessly bikeshed rules and
other politics,but that day is clearly not today
--
Vittorio
_______________________________________________
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-19 2:26 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 [this message]
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
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='CABLWnS_RvhfoeTz79EnPmH+U+rA4rsuapdj0GS+h3=E2cyJ7GQ@mail.gmail.com' \
--to=vittorio.giovara@gmail.com \
--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