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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
