From: Aleksandar Markovic <amarkovic@wavecomp.com>

The following changes since commit 3f3285491dd52014852a56135c90e428c8b507ea:

  Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2018-10-30 14:09:25 +0000)

are available in the git repository at:

  https://github.com/AMarkovic/qemu tags/mips-queue-october-2018-part-5

for you to fetch changes up to 12ccc41b192a0a65e9379bafa947d1ed7de79750:

  target/mips: Enable only tested modes for R5900 (2018-10-30 18:17:17 +0100)

----------------------------------------------------------------
MIPS queue for October 2018, part 5

  - some cleanup of R5900 support
----------------------------------------------------------------
Aleksandar Markovic (5):
  target/mips: Rename MMI-related masks
  target/mips: Rename MMI-related opcodes
  target/mips: Rename MMI-related functions
  target/mips: Remove some spurious R5900-related comments
  target/mips: Enable only tested modes for R5900

 target/mips/translate.c          | 533 ++++++++++++++++++++-------------------
 target/mips/translate_init.inc.c |  16 +-
 2 files changed, 271 insertions(+), 278 deletions(-)

-- 
2.7.4

Hi Aleksandar,

On 30/10/18 18:28, Aleksandar Markovic wrote:
> From: Aleksandar Markovic <amarkovic@wavecomp.com>
> 
> The following changes since commit 3f3285491dd52014852a56135c90e428c8b507ea:
> 
>    Merge remote-tracking branch 'remotes/jnsnow/tags/bitmaps-pull-request' into staging (2018-10-30 14:09:25 +0000)
> 
> are available in the git repository at:
> 
>    https://github.com/AMarkovic/qemu tags/mips-queue-october-2018-part-5
> 
> for you to fetch changes up to 12ccc41b192a0a65e9379bafa947d1ed7de79750:
> 
>    target/mips: Enable only tested modes for R5900 (2018-10-30 18:17:17 +0100)

1h44min between a series posted and the same series sent as pull request 
is quite fast for qemu-devel@.

I'm sorry to complain about this, but this is not the first time I 
review your patches and make comment, and see the previous series in PR 
and my comment ignored.

There are (paid) reviewers working in about every timezones, also note 
that some hobbyist might only have time during week-ends.

I don't know if they are guidelines for that. 24h could work.

Maybe you can answer 'Applied' to the series you take, so people 
interested won't spend time reviewing.

Regards,

Phil.

> 
> ----------------------------------------------------------------
> MIPS queue for October 2018, part 5
> 
>    - some cleanup of R5900 support
> ----------------------------------------------------------------
> Aleksandar Markovic (5):
>    target/mips: Rename MMI-related masks
>    target/mips: Rename MMI-related opcodes
>    target/mips: Rename MMI-related functions
>    target/mips: Remove some spurious R5900-related comments
>    target/mips: Enable only tested modes for R5900
> 
>   target/mips/translate.c          | 533 ++++++++++++++++++++-------------------
>   target/mips/translate_init.inc.c |  16 +-
>   2 files changed, 271 insertions(+), 278 deletions(-)
> 

On 30 October 2018 at 17:49, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> 1h44min between a series posted and the same series sent as pull request is
> quite fast for qemu-devel@.
>
> I'm sorry to complain about this, but this is not the first time I review
> your patches and make comment, and see the previous series in PR and my
> comment ignored.
>
> There are (paid) reviewers working in about every timezones, also note that
> some hobbyist might only have time during week-ends.
>
> I don't know if they are guidelines for that. 24h could work.

We don't have specific guidelines, but yes, in general there should
be a reasonable time between patches being posted and their being
applied, to allow time for review. There is some element of a
judgement call here -- if the patch is "obviously" non-controversial
or trivial and it gets reviewed quickly it may be ok to put it into
a pull request sooner rather than later. And I appreciate that it
being softfreeze day today imposes some time pressure.

I think in this case it would be good to let these have a bit more
time and to handle the code review comments; we can still put them
into 3.1.

thanks
-- PMM