[FFmpeg-devel] [PATCH] lavc/vvc_mc: reduce sequential dependency in R-V V sad

[Alexander Strasser]

On 2024-12-30 20:25 +0200, Rémi Denis-Courmont wrote:
> Le tiistaina 24. joulukuuta 2024, 15.30.00 EET Nuo Mi a écrit :
> > On Mon, Dec 23, 2024 at 11:18 PM flow gg <hlefthleft at gmail.com> wrote:
> > > Hi, It looks like you submitted your review comments not long after the
> > > patch was merged.
> > >
> > > Previously, regarding the VVC avg patch, you mentioned "LGTM for the
> > > RISC-V
> > > side. No clue about the VVC side",
> > > so I contacted Nuomi in the hope that he could help merge the patch that
> > > had been pending for a while.
> >
> > Hi Remi,
> > Yes, v2 has been on the mailing list for about two weeks.
>
> Yes but there was only a day and a half between v2_2 and my comments, and
> that's way too short.

Misunderstandings can (and probably will) always happen.

In case they do, as a maintainer, you should revert the parts that you
consider wrong, if you feel that is better than waiting for a patch
to fix the remaining problems.

In some situations if a partial revert is too hard, even a full revert
can be considered. Should be judged based on something like the impact
you estimate and the number of users potentially affected.

In any case why a patch set was reverted and how big you estimated the
problems should be part of the message of the revert commit.

What must not happen of course is "revert wars", but generally quickly
reverting things once, should be considered instead of leaving things
knowingly broken for an undetermined amount of time.

I hope other developers agree to my reasoning here. If not please raise
your voice. If there is no disagreement, we should maybe extend our
documentation. Will have a look into that.

Also there is a case for committing security relevant fixes, even if
the maintainer couldn't ack them yet. IMHO we should not let those
wait too long because the maintainer is not quick to respond. It's
another topic, but should probably also be documented if it isn't.
Also it's the lived practice of the recent decades of FFmpeg
development I think.


  Alexander

[...]