linux-kernel - Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAL_JsqKZjYF2Jrvcd8BAHsMfm5-S1J11NVoc6o2q5zE5ekmRTw@mail.gmail.com>
Date:   Mon, 8 Jun 2020 17:46:59 -0600
From:   Rob Herring <robh@...nel.org>
To:     Serge Semin <fancer.lancer@...il.com>
Cc:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Jarkko Nikula <jarkko.nikula@...ux.intel.com>,
        Wolfram Sang <wsa@...-dreams.de>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        "open list:MIPS" <linux-mips@...r.kernel.org>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from
 the DW I2C example

On Fri, May 29, 2020 at 12:58 PM Serge Semin <fancer.lancer@...il.com> wrote:
>
> On Fri, May 29, 2020 at 09:45:37PM +0300, Serge Semin wrote:
> > On Fri, May 29, 2020 at 09:42:01PM +0300, Andy Shevchenko wrote:
> > > On Fri, May 29, 2020 at 09:22:56PM +0300, Serge Semin wrote:
> > > > On Fri, May 29, 2020 at 12:13:38PM -0600, Rob Herring wrote:
> > > > > On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:
> > >
> > > > > you're sending
> > > > > new versions too fast. Give people time to review.
> > > >
> > > > Yeah, you did. Sorry for sending the new versions very fast. Normally I prefer
> > > > to keep up with comments so to past a particular maintainer review as fast as
> > > > possible without long delays. In my experience the longer you wait, the lesser
> > > > maintainers remember about your patchset, the harder for one to continue the
> > > > next versions review.
> > >
> >
>
> > > Documentation/process/submitting-patches.rst:
> > >
> > > "Wait for a minimum of one week before resubmitting or pinging reviewers -
> > > possibly longer during busy times like merge windows."
> >
> > Good to know what I already know.) How much do you personally wait before
> > resubmitting? In my experience reviewing your DW APB GPIO patches, no longer
> > than a few hours.
>
> Moreover the statement you cited is about the patches, which doesn't get any
> attention from the maintainers/reviewers for quite some time. In this case I
> normally resubmit the patches no sooner than a week. I was talking about the
> situation when you get the review comments, which need to be addressed.

There's not going to be any rule that always works. It takes
judgement. I'd say the greater the rework from review comments, the
sooner you can resend. But then if it's multiple
subsystems/maintainers, you need to give all of them time.

I go in date order mostly. You send a new version, then you go to the
back of the queue. So if you want it reviewed the soonest, send it 2
weeks ago. ;) There's also the strategy of reviewing other patches in
front of yours. Sometimes I go by version numbers, but send version 50
and I might be suspicious. And that's rewarding folks who are sloppy
or keep sending broken stuff. The real solution is I just need more
help reviewing things.

Rob