Re: [Qemu-devel] [PATCH v2 0/7] Misc sm501 improvements

[BALATON Zoltan]

On Wed, 4 Jul 2018, Philippe Mathieu-Daudé wrote:
> Hi David, I'll reply to you using Peter mail :)

Thanks a lot for this summary and your review spotting an error. I forgot 
about Gerd's OK as he did not send formal Reviewed or Acked but you're 
right that's also counts to show that the series should be sane.

I did not want to become maintainer of sm501 for at least two reasons:

1. Because it was part of SH and thus it should already have a maintainer 
or if it doesn't any more then I can't take that either as I don't know SH

2. I'm not familiar with the tasks a maintainer has to do and don't have 
enough time now to do that

But if it's only a question of responsibility I don't ask you to take 
that, only ask David or Peter to help in merging this. I take 
responsibility for problems it causes and will try to fix it or I'm OK to 
have it removed if I fail to do that. Hope that's acceptable at least for 
now, then we can discuss about what to do with the sam460ex and related 
parts for the future.

Thank you,
BALATON Zoltan

> On 07/03/2018 06:13 AM, Peter Maydell wrote:
> > On 3 July 2018 at 01:28, David Gibson <address@hidden> wrote:
> > > On Mon, Jul 02, 2018 at 10:42:07AM +0100, Peter Maydell wrote:
> > > > I can have a look, but really I think these should go via the
> > > > ppc tree -- the device is used in a ppc machine and an sh4 one,
> > > > and the ppc tree is much more active than sh4.
> > >
> > > Hm, well, if you like.  Although the gradual creep of my
> > > maintainership scope into things I know less and less about makes me
> > > rather nervous.  I tried to convince Balaton Zoltan to become sm501
> > > maintainer, but he didn't bite.
> >
> > It's not like I know anything more about the sm501 than you do :-)
> >
> > The arm parts of the tree have a lot of board and device code
> > I'm not familiar with either. Generally the approach I use is:
> >  * eyeball the code to see if it's doing anything that looks
> >    "obviously wrong", failing to use correct QEMU APIs, etc
>
> Gerd Hoffmann did a review for the graphic code,
> then commented "all look sane":
> http://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg06493.html
>
> I don't have a serious understanding of QEMU graphic internals, but
> looked at those patches and didn't find anything "obviously wrong".
>
> >  * anything that touches 'core' code or code common to multiple
> >    machines gets closer scrutiny
>
> The only SH4 tests I run are using Aurelien Debian:
> https://people.debian.org/~aurel32/qemu/sh4/
>
> >  * I might check the data sheet if I'm feeling enthusastic or
> >    if the code looks like it's doing weird things, but often
> >    not, especially if the code has had review from somebody else
>
> I did a review of the I2C/DDC patch with the specs at hand.
>
> >  * if I have a test image to hand I'll do a smoke test, but often
> >    I don't have a test image
>
> Neither do I.
>
> > Basically I think the important thing is to make sure the
> > codebase stays maintainable and generally the quality bar
> > in terms of using the right APIs and design approaches
> > tends to ratchet up rather than down. If our implementation
> > of an obscure device isn't actually right, that doesn't
> > really affect very many users, so I worry less about that
> > side of things.
>
> Zoltan used few deprecated API but said updating "could be done in
> separate clean up", which I agree :)
> http://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg06911.html
>
> FWIW and using Peter's criteria I think this series is good to go.
>
> Regards,
>
> Phil.