Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1641331 > unrolled thread

Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry Mark Brown <broonie@kernel.org> - 2017-05-15 10:00 +0200
    Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry Lee Jones <lee.jones@linaro.org> - 2017-05-16 10:00 +0200
      Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry Mark Brown <broonie@kernel.org> - 2017-05-16 13:10 +0200
        Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry Javier Martinez Canillas <javier@dowhile0.org> - 2017-05-16 14:00 +0200
        Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry  Lee Jones <lee.jones@linaro.org> - 2017-05-22 13:10 +0200
          Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry Mark Brown <broonie@kernel.org> - 2017-05-22 14:10 +0200

#1641331 — Re: [RESEND PATCH] MAINTAINERS: Update MAX77802 PMIC entry

[Multipart message — attachments visible in raw view] — view raw

On Thu, May 04, 2017 at 12:36:25AM -0400, Javier Martinez Canillas wrote:

> Acked-by: Mark Brown <broonie@kernel.org>

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).

[toc] | [next] | [standalone]

#1642282

On Sun, 14 May 2017, Mark Brown wrote:

> On Thu, May 04, 2017 at 12:36:25AM -0400, Javier Martinez Canillas wrote:
> 
> > Acked-by: Mark Brown <broonie@kernel.org>
> 
> 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.
 
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.

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.

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

[toc] | [prev] | [next] | [standalone]

#1642410

[Multipart message — attachments visible in raw view] — view raw

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.

> 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.

> 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.

[toc] | [prev] | [next] | [standalone]

#1642459

Hello Mark and Lee,

On Tue, May 16, 2017 at 1:06 PM, Mark Brown <broonie@kernel.org> 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 wondered what to do for this corner case... since I also didn't want
you to tell me why I didn't carry the provided Acked-by tag :)

>> 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.
>

Thanks a lot for clarifying your process. I'll remember to drop your
Acked-by tag if the same situation happens in the future for patches
to your subsystems.

>> 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.

Yes, I know you add Acks for your own reference to know that the patch
has been already reviewed/acked by you. So I'll continue to carry them
for patches to the MFD subsystem.

Best regards,
Javier

[toc] | [prev] | [next] | [standalone]

#1646745

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

[toc] | [prev] | [next] | [standalone]

#1646807

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 22, 2017 at 12:06:04PM +0100, Lee Jones wrote:
> On Tue, 16 May 2017, Mark Brown wrote:

> > > 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

Interesting...  any examples?  I get quite a bit of this as well as a
result of regmap and regulator and I can't say it's ever come up.

> > > 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.

An ack is basically a step down from a review saying "I'm OK with this
being applied" but not actually "I did a thorough review".  That makes
it a bit funny compared to a review, testing or similar.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web