linux-kernel - Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry

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]

Message-ID: <20170522110604.g66mzwhkum4v6eyp@dell>
Date:   Mon, 22 May 2017 12:06:04 +0100
From:   Lee Jones <lee.jones@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Javier Martinez Canillas <javier@...hile0.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry 

On Tue, 16 May 2017, Mark Brown wrote:

> On Tue, May 16, 2017 at 08:51:40AM +0100, Lee Jones wrote:
> > On Sun, 14 May 2017, Mark Brown wrote:
> 
> > > Since I'm expected to apply this I wouldn't normally expect to see my
> > > ack - like I say if I'm acking something for me it's normally because I
> > > expect someone else to actually apply it (that's the standard thing).
> 
> > I don't agree with this.  You provided your Ack under the assumption
> > that it would be applied though another tree, but there is no reason
> > why it would be dropped just because that is no longer the case.
> 
> When I see a patch I've acked, especially one that I'd not expect to
> apply, I'll just delete the mail since I've already reviewed it.  I get
> lots of such stuff that's part of a bigger series resent for
> whatever reason.  One of the first questions I ask myself if I'm not
> sure why I have something is if I already handled it and if so I often
> stop there.  
> 
> This didn't happen here mainly because I remembered what the patch was,
> if I'd forgotten I'd probably have just discarded it for the same reason
> I initially acked it.  Of course it's possible that that could've
> happened anyway but it's less likely as it's less mechanical.

Although logical and of benefit to you most of the time, doing that
will lead to exactly this issue occasionally.  If you adopt such a
process, you need to be aware (and forgiving) of it when users submit
patches for you to apply which contain your Ack.

> > It's commonplace for me to provide Acks for patches I know will
> > *eventually* be applied by me.  Removing them when applying patches is
> > part of my daily routine.
> 
> You're the only person I'm aware of who does this.

The operative words here are "I'm aware".  Conversely, I know lots of
Maintainers who do this, but I guess that comes with the territory
when dealing with the types of patch-sets that I handle.  Often times
we do not know who will take a particular cross-subsystem set until
the reviews have been conducted.  Usually it ends up being myself, but
not always.

> > TL;DR:  If a Maintainer (or anyone for that matter) provides a *-by
> > tag, it should be carried forward with the (unchanged) patch until
> > acceptance.
> 
> Given what acks get used for (they're more of a process thing than
> anything else) I'm not so sure it works well for them.

I'm not entirely sure what is meant by this.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog