Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Vittorio Giovara <vittorio.giovara@gmail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive
Date: Fri, 25 Aug 2023 19:26:21 +0200
Message-ID: <CABLWnS-Rpu10UstEOdyt4SWwOJHcdw0yr3CM=TCayEfOduchcw@mail.gmail.com> (raw)
In-Reply-To: <169297702590.20400.2202310309151021276@lain.khirnov.net>

On Fri, Aug 25, 2023 at 5:24 PM Anton Khirnov <anton@khirnov.net> wrote:

> Quoting Rémi Denis-Courmont (2023-08-25 17:09:55)
> > Le perjantaina 25. elokuuta 2023, 17.58.40 EEST Anton Khirnov a écrit :
> > > > And then sometimes an argument has been argued to death previously
> and
> > > > there is really no point to rehash it again and again. If people
> cannot
> > > > agree, they should refer to the TC, not brute force the review
> through
> > > > overwhelming insistance.
> > >
> > > I think we just have different interpretations of the word
> > > 'constructive' here.
> > > I certainly agree that some patches are just not acceptable - I
> certainly
> > > did not mean to imply that there must be a way forward for all patches.
> >
> > I think that you do not agree with the generally accepted meaning of
> > "constructive" in this context. By definition a review cannot be
> constructive,
> > as in helpful or conducive of a way forward, if it argues that there are
> no
> > ways forward.
>
> Explaining why a patch is not acceptable is helpful IMO.
> Saying 'no', on the other hand, is not.
>

that is true, but saying "no" and preventing some bad code from making it
in the codebase is better than not saying anything


> Maybe you meant "supported" or "corroborated".
>
> Might as well describe it in more than one word, since apparently it's
> so unclear. Would you be in favor of something along the lines of
>
>   Nontrivial (i.e. other than cosmetics or accepting the patch) reviews
>   must be based on technical arguments. If the reviewer fails to provide
>   arguments for rejecting the patch or requesting changes, then the
>   review may be disregarded.
>

I agree with the text suggested, but I don't understand why it needs to be
set in stone in the first place...
-- 
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".

  reply	other threads:[~2023-08-25 17:26 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-24 19:56 [FFmpeg-devel] [PATCH 0/2] [RFC] doc/developer patch review improvements Michael Niedermayer
2023-08-24 19:56 ` [FFmpeg-devel] [PATCH 1/2] doc/developer: Reviews must be constructive Michael Niedermayer
2023-08-25  1:56   ` Vittorio Giovara
2023-08-25  6:46     ` Nicolas George
2023-08-25  9:22       ` Paul B Mahol
2023-08-25 17:23       ` Vittorio Giovara
2023-08-25 14:06     ` Anton Khirnov
2023-08-25 14:22   ` Rémi Denis-Courmont
2023-08-25 14:58     ` Anton Khirnov
2023-08-25 15:09       ` Rémi Denis-Courmont
2023-08-25 15:23         ` Anton Khirnov
2023-08-25 17:26           ` Vittorio Giovara [this message]
2023-08-25 17:35             ` Anton Khirnov
2023-08-25 17:34         ` Leo Izen
2023-08-25 17:39           ` Nicolas George
2023-08-24 19:56 ` [FFmpeg-devel] [PATCH 2/2] doc/developer: Code pushed without patches on ffmpeg-devel must be announced on the ML Michael Niedermayer
2023-08-24 20:04   ` Andreas Rheinhardt
2023-08-25 15:34     ` Michael Niedermayer
2023-08-25 15:36       ` Jean-Baptiste Kempf
2023-08-25 15:47         ` Paul B Mahol
2023-08-25 16:27         ` Nicolas George
2023-08-25 16:33           ` Jean-Baptiste Kempf
2023-08-25 17:16             ` Nicolas George
2023-08-25 17:25               ` James Almer
2023-08-25 17:42                 ` Nicolas George
2023-08-25 21:41                   ` Ronald S. Bultje
2023-08-24 20:06   ` James Almer
2023-08-24 20:23     ` Andreas Rheinhardt

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-Rpu10UstEOdyt4SWwOJHcdw0yr3CM=TCayEfOduchcw@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