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] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 4 Jul 2018 10:21:09 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Cc:     mturquette@...libre.com, sboyd@...nel.org, robh+dt@...nel.org,
        mark.rutland@....com, lgirdwood@...il.com, broonie@...nel.org,
        mazziesaccount@...il.com, arnd@...db.de, dmitry.torokhov@...il.com,
        sre@...nel.org, chenjh@...k-chips.com, andrew.smirnov@...il.com,
        linus.walleij@...aro.org, kstewart@...uxfoundation.org,
        heiko@...ech.de, gregkh@...uxfoundation.org,
        linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        mikko.mutanen@...rohmeurope.com, heikki.haikola@...rohmeurope.com
Subject: Re: [PATCH v7 0/4] mfd/regulator/clk/input: bd71837: ROHM BD71837
 PMIC driver

On Wed, 04 Jul 2018, Matti Vaittinen wrote:

> On Tue, Jul 03, 2018 at 08:02:00AM +0100, Lee Jones wrote:
> > On Thu, 21 Jun 2018, Matti Vaittinen wrote:
> > 
> > > On Tue, Jun 19, 2018 at 01:55:31PM +0300, Matti Vaittinen wrote:
> > > > Patch series adding support for ROHM BD71837 PMIC.
> > > > 
> > > What is the preferred way when I send updated patches:
> > > 
> > > 1. always resend _all_ unapplied patches even if there is no changes to
> > >    some of them. (patch-vN mail thread contains _all_ unapplied patches)
> > > 2. only resend changed patches (patch-vN mail thread contains only
> > >    patches that were changed from patch-vN-1)
> > > 
> > > I have currently used approach 1 - so that no patches would be
> > > accidentally forgotten - but downside is that people need to check if
> > > they have already reviewed some of the patches. I'd rather not caused
> > > any extra work. What is the most convenient way for you guys?
> > 
> > Option 1 is preferred.
> > 
> > Just ensure you apply any tags you have collected so reviewers can see
> > which patches are pending a review.  It's also a good idea to keep a
> > succinct change log between the "--" marker and the diff stat where
> > you can state "v4: No change" or the like.
> 
> Right. Thanks. Just one question - what if I get reviewed-by for a
> patch which I later rework? Like this MFD patch where I got reviewed-by
> from Linus Walleij for v6 - but which I reworked due to comments from
> Enric and Dmitry. I have not kept the reviewed-by as the patch is not
> exactly the same Linus was originally reviewing. I guess the tags should
> be only kept for patches which are unchanged, right?

That is the $64,000 question.  The answer is "it depends".  You should
use your common sense.  Did your re-work taint the code that your
reviewer provided his tag for?  If so, drop it.  If not, keep it.

There are no hard and fast rules about these kinds of things.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ