Re: [PATCH v8 3/7] platform/x86/thinkpad: Call led_classdev_notify_brightness_hw_changed on kbd brightness change

[Darren Hart <dvhart@infradead.org>]

On Tue, Feb 14, 2017 at 11:33:49AM +0200, Andy Shevchenko wrote:
> On Tue, Feb 14, 2017 at 11:25 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> > On 13-02-17 23:52, Andy Shevchenko wrote:
> >> On Thu, Feb 9, 2017 at 8:08 PM, Henrique de Moraes Holschuh
> >> <hmh@hmh.eng.br> wrote:
> >>> On Thu, Feb 9, 2017, at 13:44, Hans de Goede wrote:
> 
> >>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> >>> Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
> 
> >> Thanks, thinkpad_acpi bits are applied to testing
> 
> > Thank you, so the Dell bits are waiting for Pali's ack ?
> > Note the Dell bits have been tested on actual hardware too.
> 
> This cycle shows a flaw in my understanding of process. I've
> mistakenly pushed couple of patches without maintainers' review. So, I
> guess from now on we highly recommend to have a tag from actual
> maintainer before we are going to proceed.
> 
> Darren, if you think this is too strong, what would be better approach?

What I've discussed with the various driver maintainers is they should reply
within a week, and after that, I (now Andy and/or I) will make the decision.

I try to stick to this especially for functional changes. For DMI matches and
new HIDs and other trivial things, I usually just queue to testing and ask the
maintainer if they have any objections, and take silence for accent :)

I do think there is value in getting the patch into testing as soon as possible,
even while waiting for the driver maintainer to get to it. The risk would be
accidentally committing a patch a maintainer objects to. I don't think this has
happened yet as an email from the maintainer can trigger dropping the patch. We
can discuss how to manage the corner cases offline.

-- 
Darren Hart
Intel Open Source Technology Center