[FFmpeg-devel] [PATCH 1/2] avcodec/s302m: enable non-PCM decoding
Vittorio Giovara
vittorio.giovara at gmail.com
Mon Feb 19 16:30:44 EET 2024
On Mon, Feb 19, 2024 at 6:11 AM Gyan Doshi <ffmpeg at gyani.pro> wrote:
>
>
> On 2024-02-19 03:16 am, Vittorio Giovara wrote:
> > On Sun, Feb 18, 2024 at 8:02 PM Gyan Doshi <ffmpeg at gyani.pro> wrote:
> >
> >>
> >> On 2024-02-18 11:33 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2024-02-18 05:06:30)
> >>>> b) what "maximalist" interpretation?
> >>> A non-maximalist interpretation would be that a TC member is only
> >>> excluded from voting when they authored the patch that is being
> >>> disputed.
> >> If the promulgators meant to only prevent proposers of the disputed
> >> change to not take part, then
> >> the verbiage would be different.
> >>
> >> In looking up how this clause came to be present, I came across the
> >> following messages:
> >>
> >> https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/273443.html
> >> (Nicolas George originally proposes this clause - wording is more
> >> restrictive)
> >>
> >> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274822.html
> >> (this one is interesting, you objected to the clause but on the grounds
> >> that it was all-encompassing i.e. anyone commenting on the dispute was
> >> potentially subjected to recusal and referred to some 'model'
> >> discussion, so your describing my reading as maximalist is weird since
> >> that is how you read it - you just happen to object to this rule)
> >>
> >> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-January/274826.html
> >> (Ronald clarifies that "involved" should be constrained to just be one
> >> of the two parties -- of which you happen to be one)
> >>
> >> There's the matter of what the rule currently is, distinct from what it
> >> should be. What it ideally should be is that the decision should be
> >> taken by a fresh set of eyes consisting of those who haven't become or
> >> are seen to be publicly invested in the outcome. So the TC should have a
> >> set of alternates - those who can make up the quorum and constitute an
> >> odd number of voters when some from the first 5 are recused.
> >>
> > I'd like to offer a lighter interpretation of the rule, the mailing list
> is
> > the common playing ground, where discussions and disagreements can be
> had.
> > In case of a technical "maximalist" disagreement, then either party can
> > invoke the TC to judge on the matter. If anyone in the TC is involved in
> > the patch, as if it's an author or significantly contributed to it, then
> > they should step away from voting. In other words the "level of
> > involvement" rule takes place at the TC level, not at the ffmpeg-devel
> > discussion.
>
> The TC is invoked when there's an intractable dispute. So the dispute
> precedes the TC activity hence the parties to the dispute are the main
> opposing participants at the venue of the dispute wherever that is, and
> the rules applies to all main parties. Imagine there's a new feature to
> be added which doesn't exist in the codebase in any form so there's no
> status quo. Member A submits a patch using design pattern X. Member B
> objects and wants design pattern Y. Now let's say if only A was on the
> TC, then as per the arguments of some here, A should recuse themselves
> but if only B was on the TC, B gets to vote. That asymmetry is not
> supported in the wording nor would it be fair.
>
The asymmetry is that the TC should be protecting the good of the project
and the community interests, while the member of the community proposing
the patch is protecting their own interest. For the better or the worse of
course. The rule you keep bringing forth is stated to avoid a conflict of
interest where the member of the TC is also the author of the patch, but
was never meant to exclude one party from voting in the TC.
> Also consider that even in a vote recusal, the member's
> > arguments will still be read and by all likelihood taken into
> consideration
> > by the TC, so yours seems to be a literal interpretation of the rule,
> > instead of the spirit of the rule, which in my opinion matters more.
>
> Of course. There's no mind-reading or mind-control machine here. Humans
> aren't automatons either. The judges on any Supreme Court are older
> human beings with all the deep convictions that one acquires during a
> long lifetime but that's the best we can do. The rules are meant to be
> the most that is practically feasible within mutually observable
> reality, not ideally efficient within an omniscient universe.
>
If you believe the interpretation of the rule is dubious or incorrect, you
should propose a formal vote to change or clarify its wording.
--
Vittorio
More information about the ffmpeg-devel
mailing list