qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Aleksandar Markovic <aleksandar.qemu.devel@gmail.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Aurelien Jarno <aurelien@aurel32.net>
Subject: Re: [PULL 08/13] softfloat: Fix BAD_SHIFT from normalizeFloatx80Subnormal
Date: Sat, 11 Apr 2020 13:55:46 +0100	[thread overview]
Message-ID: <87wo6m89m5.fsf@linaro.org> (raw)
In-Reply-To: <CAFEAcA_aE5uA9eaZWU9cr8tZR3x=dmqWBx5FO8QD8K3n+Fsv5w@mail.gmail.com>


Peter Maydell <peter.maydell@linaro.org> writes:

> On Fri, 10 Apr 2020 at 16:17, Richard Henderson
> <richard.henderson@linaro.org> wrote:
>> Although why Alex didn't add his own R-b to my patch when merging it to his
>> branch, I don't know.
>
> I think this is one of those areas where different submaintainers
> have different work practices. Personally I distinguish "did I
> actually review this" from "did I just put this into my tree and
> rely on others doing the review" and use r-by for the former
> and not on the latter (although obviously everything I put in
> my tree I will have at least very very briefly looked over).
> But I think some submaintainers don't bother to add r-by tags
> for things they review in the process of assembling their
> tree because they see it as implicit in the process.

It was exactly this - pulling in via my tree and adding my own s-o-b
implies I'm happy enough with it. Typically for longer series that
gestate on the list the total number of r-b tags grows with each re-roll
until the series gets pulled into a maintainer branch. This PR is
atypical in that regard because it's a fairly random collection of fixes.

I think the only patches we should be wary of are those with only a
single s-o-b tag from the author. I have to admit there was one such
patch in this PR:

  Subject: [PULL 09/13] linux-user: factor out reading of /proc/self/maps
  Date: Tue,  7 Apr 2020 16:51:14 +0100
  Message-Id: <20200407155118.20139-10-alex.bennee@linaro.org>

I made an executive decision to include it as it was part of the bug fix
for patch 10 and as we approach RC releases I wanted to get it merged.
If you follow the msg-id in the patch you will see the changes in the
patch are purely in response to review comments so while missing a r-b
tag it's not like it's not been on the list and had some scrutiny.
However we should certainly aim for most patches to be fully reviewed
even if we never achieve that level of perfection.

>
> thanks
> -- PMM


-- 
Alex Bennée


  parent reply	other threads:[~2020-04-11 12:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07 15:51 [PULL for 5.0-rc2 00/13] various fixes Alex Bennée
2020-04-07 15:51 ` [PULL 01/13] .github: Enable repo-lockdown bot to refuse GitHub pull requests Alex Bennée
2020-04-07 15:51 ` [PULL 02/13] elf-ops: bail out if we have no function symbols Alex Bennée
2020-04-07 15:51 ` [PULL 03/13] linux-user: protect fcntl64 with an #ifdef Alex Bennée
2020-04-07 15:51 ` [PULL 04/13] tests/tcg: remove extraneous pasting macros Alex Bennée
2020-04-07 15:51 ` [PULL 05/13] linux-user: more debug for init_guest_space Alex Bennée
2020-04-07 15:51 ` [PULL 06/13] target/xtensa: add FIXME for translation memory leak Alex Bennée
2020-04-07 15:51 ` [PULL 07/13] gdbstub: fix compiler complaining Alex Bennée
2020-04-07 15:51 ` [PULL 08/13] softfloat: Fix BAD_SHIFT from normalizeFloatx80Subnormal Alex Bennée
2020-04-10  9:38   ` Aleksandar Markovic
2020-04-10 15:17     ` Richard Henderson
2020-04-10 15:54       ` Aleksandar Markovic
2020-04-10 16:13       ` Peter Maydell
2020-04-10 18:33         ` Aleksandar Markovic
2020-04-11 12:55         ` Alex Bennée [this message]
2020-04-07 15:51 ` [PULL 09/13] linux-user: factor out reading of /proc/self/maps Alex Bennée
2020-04-07 15:51 ` [PULL 10/13] linux-user: clean-up padding on /proc/self/maps Alex Bennée
2020-04-07 15:51 ` [PULL 11/13] hw/core: properly terminate loading .hex on EOF record Alex Bennée
2020-04-07 15:51 ` [PULL 12/13] configure: Add -Werror to PIE probe Alex Bennée
2020-04-07 16:08   ` Mark Cave-Ayland
2020-04-07 16:25     ` Richard Henderson
2020-04-07 15:51 ` [PULL 13/13] tcg/i386: Fix %r12 guest_base initialization Alex Bennée
2020-04-07 22:13 ` [PULL for 5.0-rc2 00/13] various fixes Peter Maydell

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=87wo6m89m5.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=aleksandar.qemu.devel@gmail.com \
    --cc=aurelien@aurel32.net \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).