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


Groups > linux.kernel > #1583047 > unrolled thread

Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups

Started byDarren Hart <dvhart@infradead.org>
First post2017-02-17 04:00 +0100
Last post2017-02-24 23:20 +0100
Articles 10 — 4 participants

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: [PATCH 00/10] fujitsu-laptop: renames and cleanups Darren Hart <dvhart@infradead.org> - 2017-02-17 04:00 +0100
    Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Jonathan Woithe <jwoithe@just42.net> - 2017-02-17 04:10 +0100
      Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Darren Hart <dvhart@infradead.org> - 2017-02-17 05:00 +0100
        Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Jonathan Woithe <jwoithe@just42.net> - 2017-02-17 05:20 +0100
          Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Darren Hart <dvhart@infradead.org> - 2017-02-17 06:30 +0100
          Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-24 21:40 +0100
            Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Michał Kępień <kernel@kempniu.pl> - 2017-02-26 12:40 +0100
              Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-02-26 16:20 +0100
        Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Michał Kępień <kernel@kempniu.pl> - 2017-02-17 08:20 +0100
          Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups Darren Hart <dvhart@infradead.org> - 2017-02-24 23:20 +0100

#1583047 — Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups

FromDarren Hart <dvhart@infradead.org>
Date2017-02-17 04:00 +0100
SubjectRe: [PATCH 00/10] fujitsu-laptop: renames and cleanups
Message-ID<tbGW5-6FB-1@gated-at.bofh.it>
On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrote:
> On Fri, Feb 10, 2017 at 2:16 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
> > On Wed, Feb 08, 2017 at 02:46:23PM +0100, Micha?? K??pie?? wrote:
> 
> > In summary, I see no issues with this patch series which provides a much
> > needed clean up of the code and naming conventions within the fujitsu-laptop
> > driver.  I'm happy for this series (patches 1-10/10) to be applied.
> >
> > Signed-off-by: Jonathan Woithe <jwoithe@just42.net>
> 
> I have noticed people start using SoB for the code they are
> maintaining w/o sending any pull requests.
> It is okay, but there is, as Wolfram pointed, a downside for patchwork
> users. Patchwork is tracking tags (A/R/T) which by a glance allows to
> see what patches are acked/reviewed/tested.

Signed-off-by tracks the path the code takes from author to mainline. If you are
not the author or committing it to a tree followed by a pull-request, the
correct tag is "Reviewed-by".

-- 
Darren Hart
Intel Open Source Technology Center

[toc] | [next] | [standalone]


#1583050

FromJonathan Woithe <jwoithe@just42.net>
Date2017-02-17 04:10 +0100
Message-ID<tbH5M-6Yf-11@gated-at.bofh.it>
In reply to#1583047
On Thu, Feb 16, 2017 at 06:57:08PM -0800, Darren Hart wrote:
> On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrote:
> > On Fri, Feb 10, 2017 at 2:16 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
> > > On Wed, Feb 08, 2017 at 02:46:23PM +0100, Micha?? K??pie?? wrote:
> > 
> > > In summary, I see no issues with this patch series which provides a much
> > > needed clean up of the code and naming conventions within the fujitsu-laptop
> > > driver.  I'm happy for this series (patches 1-10/10) to be applied.
> > >
> > > Signed-off-by: Jonathan Woithe <jwoithe@just42.net>
> > 
> > I have noticed people start using SoB for the code they are
> > maintaining w/o sending any pull requests.
> > It is okay, but there is, as Wolfram pointed, a downside for patchwork
> > users. Patchwork is tracking tags (A/R/T) which by a glance allows to
> > see what patches are acked/reviewed/tested.
> 
> Signed-off-by tracks the path the code takes from author to mainline. If you are
> not the author or committing it to a tree followed by a pull-request, the
> correct tag is "Reviewed-by".

Yes, of course - I clearly had a brain fade back there.  Having said that, 
in the past I've used "Acked-by" intead of "Reviewed-by".

Do you want me to continue to use Acked-by, or should I switch to
Reviewed-by?

Regards
  jonathan

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


#1583077

FromDarren Hart <dvhart@infradead.org>
Date2017-02-17 05:00 +0100
Message-ID<tbHS9-7lr-5@gated-at.bofh.it>
In reply to#1583050
On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> On Thu, Feb 16, 2017 at 06:57:08PM -0800, Darren Hart wrote:
> > On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrote:
> > > On Fri, Feb 10, 2017 at 2:16 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
> > > > On Wed, Feb 08, 2017 at 02:46:23PM +0100, Micha?? K??pie?? wrote:
> > > 
> > > > In summary, I see no issues with this patch series which provides a much
> > > > needed clean up of the code and naming conventions within the fujitsu-laptop
> > > > driver.  I'm happy for this series (patches 1-10/10) to be applied.
> > > >
> > > > Signed-off-by: Jonathan Woithe <jwoithe@just42.net>
> > > 
> > > I have noticed people start using SoB for the code they are
> > > maintaining w/o sending any pull requests.
> > > It is okay, but there is, as Wolfram pointed, a downside for patchwork
> > > users. Patchwork is tracking tags (A/R/T) which by a glance allows to
> > > see what patches are acked/reviewed/tested.
> > 
> > Signed-off-by tracks the path the code takes from author to mainline. If you are
> > not the author or committing it to a tree followed by a pull-request, the
> > correct tag is "Reviewed-by".
> 
> Yes, of course - I clearly had a brain fade back there.  Having said that, 
> in the past I've used "Acked-by" intead of "Reviewed-by".

:-)

> Do you want me to continue to use Acked-by, or should I switch to
> Reviewed-by?

These tags do have different meanings, and have come up at Kernel Summit the
last couple of years. My interpretation of those discussions is:

Acked-by: I have no objection to this patch, but I didn't really give it a
thorough review. I trust your judgement. e.g. minor change to your driver to
support a subsystem API change. These are of very little value.

Reviewed-by: I have carefully reviewed this patch and would like it to be
applied. This should usually come with some sort of commentary describing the
level of review or an area you focused on. This is what we would like to see
from all of our driver maintainers. These are high value.

Linus *really* dislikes one line acked by's, and only *slightly* more so than
one line reviewed by's. :-)

Thanks!

-- 
Darren Hart
Intel Open Source Technology Center

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


#1583079

FromJonathan Woithe <jwoithe@just42.net>
Date2017-02-17 05:20 +0100
Message-ID<tbIbw-7H1-1@gated-at.bofh.it>
In reply to#1583077
On Thu, Feb 16, 2017 at 07:53:19PM -0800, Darren Hart wrote:
> On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> > Do you want me to continue to use Acked-by, or should I switch to
> > Reviewed-by?
> 
> These tags do have different meanings, and have come up at Kernel Summit the
> last couple of years. My interpretation of those discussions is:
> 
> Acked-by: I have no objection to this patch, but I didn't really give it a
> thorough review. I trust your judgement. e.g. minor change to your driver to
> support a subsystem API change. These are of very little value.
> 
> Reviewed-by: I have carefully reviewed this patch and would like it to be
> applied. This should usually come with some sort of commentary describing the
> level of review or an area you focused on. This is what we would like to see
> from all of our driver maintainers. These are high value.
> 
> Linus *really* dislikes one line acked by's, and only *slightly* more so than
> one line reviewed by's. :-)

Got it, thanks, this is very helpful.

In light of this I give you the following.

Reviewed-by: Jonathan Woithe <jwoithe@just42.net>

This patch series applies a much delayed patch series which implements a
very useful clean up to the fujitsu-laptop driver.  Among other things it
tidies up naming conventions within the driver to better reflect the
functionality and to be more consistent with the rest of the kernel.  This
will make future maintenance and feature additions much easier for all
concerned.

As per subsequent discussion we have agreed to drop patch 8/10 from the
series: it creates problems on newer hardware and the issue it is addressing
will be more completely dealt with in a subsequent patch series.

Regards
  jonathan

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


#1583100

FromDarren Hart <dvhart@infradead.org>
Date2017-02-17 06:30 +0100
Message-ID<tbJhg-8py-1@gated-at.bofh.it>
In reply to#1583079
On Fri, Feb 17, 2017 at 02:47:56PM +1030, Jonathan Woithe wrote:
> On Thu, Feb 16, 2017 at 07:53:19PM -0800, Darren Hart wrote:
> > On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> > > Do you want me to continue to use Acked-by, or should I switch to
> > > Reviewed-by?
> > 
> > These tags do have different meanings, and have come up at Kernel Summit the
> > last couple of years. My interpretation of those discussions is:
> > 
> > Acked-by: I have no objection to this patch, but I didn't really give it a
> > thorough review. I trust your judgement. e.g. minor change to your driver to
> > support a subsystem API change. These are of very little value.
> > 
> > Reviewed-by: I have carefully reviewed this patch and would like it to be
> > applied. This should usually come with some sort of commentary describing the
> > level of review or an area you focused on. This is what we would like to see
> > from all of our driver maintainers. These are high value.
> > 
> > Linus *really* dislikes one line acked by's, and only *slightly* more so than
> > one line reviewed by's. :-)
> 
> Got it, thanks, this is very helpful.
> 
> In light of this I give you the following.
> 
> Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
> 
> This patch series applies a much delayed patch series which implements a
> very useful clean up to the fujitsu-laptop driver.  Among other things it
> tidies up naming conventions within the driver to better reflect the
> functionality and to be more consistent with the rest of the kernel.  This
> will make future maintenance and feature additions much easier for all
> concerned.
> 
> As per subsequent discussion we have agreed to drop patch 8/10 from the
> series: it creates problems on newer hardware and the issue it is addressing
> will be more completely dealt with in a subsequent patch series.

Absolutely awesome :-) Thanks!

> 
> Regards
>   jonathan
> 

-- 
Darren Hart
Intel Open Source Technology Center

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


#1587926

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-02-24 21:40 +0100
Message-ID<teuOJ-5to-19@gated-at.bofh.it>
In reply to#1583079
On Fri, Feb 17, 2017 at 6:17 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
> On Thu, Feb 16, 2017 at 07:53:19PM -0800, Darren Hart wrote:
>> On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
>> > Do you want me to continue to use Acked-by, or should I switch to
>> > Reviewed-by?
>>
>> These tags do have different meanings, and have come up at Kernel Summit the
>> last couple of years. My interpretation of those discussions is:
>>
>> Acked-by: I have no objection to this patch, but I didn't really give it a
>> thorough review. I trust your judgement. e.g. minor change to your driver to
>> support a subsystem API change. These are of very little value.
>>
>> Reviewed-by: I have carefully reviewed this patch and would like it to be
>> applied. This should usually come with some sort of commentary describing the
>> level of review or an area you focused on. This is what we would like to see
>> from all of our driver maintainers. These are high value.
>>
>> Linus *really* dislikes one line acked by's, and only *slightly* more so than
>> one line reviewed by's. :-)
>
> Got it, thanks, this is very helpful.
>
> In light of this I give you the following.
>
> Reviewed-by: Jonathan Woithe <jwoithe@just42.net>

Thanks, applied for testing with above tag.

>
> This patch series applies a much delayed patch series which implements a
> very useful clean up to the fujitsu-laptop driver.  Among other things it
> tidies up naming conventions within the driver to better reflect the
> functionality and to be more consistent with the rest of the kernel.  This
> will make future maintenance and feature additions much easier for all
> concerned.
>
> As per subsequent discussion we have agreed to drop patch 8/10 from the
> series: it creates problems on newer hardware and the issue it is addressing
> will be more completely dealt with in a subsequent patch series.
>
> Regards
>   jonathan



-- 
With Best Regards,
Andy Shevchenko

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


#1588313

FromMichał Kępień <kernel@kempniu.pl>
Date2017-02-26 12:40 +0100
Message-ID<tf5lf-68s-7@gated-at.bofh.it>
In reply to#1587926
> On Fri, Feb 17, 2017 at 6:17 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
> > On Thu, Feb 16, 2017 at 07:53:19PM -0800, Darren Hart wrote:
> >> On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> >> > Do you want me to continue to use Acked-by, or should I switch to
> >> > Reviewed-by?
> >>
> >> These tags do have different meanings, and have come up at Kernel Summit the
> >> last couple of years. My interpretation of those discussions is:
> >>
> >> Acked-by: I have no objection to this patch, but I didn't really give it a
> >> thorough review. I trust your judgement. e.g. minor change to your driver to
> >> support a subsystem API change. These are of very little value.
> >>
> >> Reviewed-by: I have carefully reviewed this patch and would like it to be
> >> applied. This should usually come with some sort of commentary describing the
> >> level of review or an area you focused on. This is what we would like to see
> >> from all of our driver maintainers. These are high value.
> >>
> >> Linus *really* dislikes one line acked by's, and only *slightly* more so than
> >> one line reviewed by's. :-)
> >
> > Got it, thanks, this is very helpful.
> >
> > In light of this I give you the following.
> >
> > Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
> 
> Thanks, applied for testing with above tag.

Andy,

It looks like you missed this part of Jonathan's message:

> As per subsequent discussion we have agreed to drop patch 8/10 from the
> series: it creates problems on newer hardware and the issue it is addressing
> will be more completely dealt with in a subsequent patch series.

I see that patch 8/10 was applied to testing as well.  Could you please
drop that single patch?

Thanks,

-- 
Best regards,
Michał Kępień

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


#1588339

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2017-02-26 16:20 +0100
Message-ID<tf8Ma-5t-7@gated-at.bofh.it>
In reply to#1588313
On Sun, Feb 26, 2017 at 1:30 PM, Michał Kępień <kernel@kempniu.pl> wrote:
>> On Fri, Feb 17, 2017 at 6:17 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
>> > On Thu, Feb 16, 2017 at 07:53:19PM -0800, Darren Hart wrote:
>> >> On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
>> >> > Do you want me to continue to use Acked-by, or should I switch to
>> >> > Reviewed-by?
>> >>
>> >> These tags do have different meanings, and have come up at Kernel Summit the
>> >> last couple of years. My interpretation of those discussions is:
>> >>
>> >> Acked-by: I have no objection to this patch, but I didn't really give it a
>> >> thorough review. I trust your judgement. e.g. minor change to your driver to
>> >> support a subsystem API change. These are of very little value.
>> >>
>> >> Reviewed-by: I have carefully reviewed this patch and would like it to be
>> >> applied. This should usually come with some sort of commentary describing the
>> >> level of review or an area you focused on. This is what we would like to see
>> >> from all of our driver maintainers. These are high value.
>> >>
>> >> Linus *really* dislikes one line acked by's, and only *slightly* more so than
>> >> one line reviewed by's. :-)
>> >
>> > Got it, thanks, this is very helpful.
>> >
>> > In light of this I give you the following.
>> >
>> > Reviewed-by: Jonathan Woithe <jwoithe@just42.net>
>>
>> Thanks, applied for testing with above tag.
>
> Andy,
>
> It looks like you missed this part of Jonathan's message:

Indeed.

>
>> As per subsequent discussion we have agreed to drop patch 8/10 from the
>> series: it creates problems on newer hardware and the issue it is addressing
>> will be more completely dealt with in a subsequent patch series.
>
> I see that patch 8/10 was applied to testing as well.  Could you please
> drop that single patch?

Good we have testing branch and thank you for pointing out. Should be fixed now.

-- 
With Best Regards,
Andy Shevchenko

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


#1583156

FromMichał Kępień <kernel@kempniu.pl>
Date2017-02-17 08:20 +0100
Message-ID<tbKZK-176-77@gated-at.bofh.it>
In reply to#1583077
> On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> > On Thu, Feb 16, 2017 at 06:57:08PM -0800, Darren Hart wrote:
> > > On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrote:
> > > > On Fri, Feb 10, 2017 at 2:16 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
> > > > > On Wed, Feb 08, 2017 at 02:46:23PM +0100, Micha?? K??pie?? wrote:
> > > > 
> > > > > In summary, I see no issues with this patch series which provides a much
> > > > > needed clean up of the code and naming conventions within the fujitsu-laptop
> > > > > driver.  I'm happy for this series (patches 1-10/10) to be applied.
> > > > >
> > > > > Signed-off-by: Jonathan Woithe <jwoithe@just42.net>
> > > > 
> > > > I have noticed people start using SoB for the code they are
> > > > maintaining w/o sending any pull requests.
> > > > It is okay, but there is, as Wolfram pointed, a downside for patchwork
> > > > users. Patchwork is tracking tags (A/R/T) which by a glance allows to
> > > > see what patches are acked/reviewed/tested.
> > > 
> > > Signed-off-by tracks the path the code takes from author to mainline. If you are
> > > not the author or committing it to a tree followed by a pull-request, the
> > > correct tag is "Reviewed-by".
> > 
> > Yes, of course - I clearly had a brain fade back there.  Having said that, 
> > in the past I've used "Acked-by" intead of "Reviewed-by".
> 
> :-)
> 
> > Do you want me to continue to use Acked-by, or should I switch to
> > Reviewed-by?
> 
> These tags do have different meanings, and have come up at Kernel Summit the
> last couple of years. My interpretation of those discussions is:
> 
> Acked-by: I have no objection to this patch, but I didn't really give it a
> thorough review. I trust your judgement. e.g. minor change to your driver to
> support a subsystem API change. These are of very little value.
> 
> Reviewed-by: I have carefully reviewed this patch and would like it to be
> applied. This should usually come with some sort of commentary describing the
> level of review or an area you focused on. This is what we would like to see
> from all of our driver maintainers. These are high value.
> 
> Linus *really* dislikes one line acked by's, and only *slightly* more so than
> one line reviewed by's. :-)

This is really useful information and I think it does not deserve to be
forgotten in a mailing list archive.  If this is indeed the status quo,
Documentation/process/submitting-patches.rst could use some love.  Here
is what it currently says:

> Acked-by: is often used by the maintainer of the affected code when that
> maintainer neither contributed to nor forwarded the patch.

My short experience with the x86 platform driver subsystem is consistent
with that.  The informal rule I inferred from mailing list discussions
is that Acked-by: means the maintainer has reviewed the patch and sees
no objections to it being applied.

Granted, Documentation/process/submitting-patches.rst also states that:

> Acked-by: does not necessarily indicate acknowledgement of the entire patch.
> For example, if a patch affects multiple subsystems and has an Acked-by: from
> one subsystem maintainer then this usually indicates acknowledgement of just
> the part which affects that maintainer's code.  Judgement should be used here.
> When in doubt people should refer to the original discussion in the mailing
> list archives.

And indeed, that is also true, especially for patch series affecting
multiple subsystems.

However, while the meaning of Reviewed-by: is described very thoroughly
in that same document, I cannot recall a single case of a patch series
affecting a single driver that would get a Reviewed-by: _from the
maintainer_.  Let alone a Reviewed-by: with a description of review
depth.  Perhaps I have read too little threads (or the wrong ones) :)

With time, I have also grown to believe that one of the differences
between Acked-by: and Reviewed-by: is that anyone interested can offer
their Reviewed-by: while Acked-by: is reserved for driver maintainers.

Perhaps this is all material for a "falsehoods kernel developers believe
about commit tags"-type article ;)

-- 
Best regards,
Michał Kępień

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


#1587980

FromDarren Hart <dvhart@infradead.org>
Date2017-02-24 23:20 +0100
Message-ID<tewnv-6Lr-1@gated-at.bofh.it>
In reply to#1583156
On Fri, Feb 17, 2017 at 08:14:51AM +0100, Michał Kępień wrote:
> > On Fri, Feb 17, 2017 at 01:38:04PM +1030, Jonathan Woithe wrote:
> > > On Thu, Feb 16, 2017 at 06:57:08PM -0800, Darren Hart wrote:
> > > > On Fri, Feb 10, 2017 at 02:42:00AM +0200, Andy Shevchenko wrote:
> > > > > On Fri, Feb 10, 2017 at 2:16 AM, Jonathan Woithe <jwoithe@just42.net> wrote:
> > > > > > On Wed, Feb 08, 2017 at 02:46:23PM +0100, Micha?? K??pie?? wrote:
> > > > > 
> > > > > > In summary, I see no issues with this patch series which provides a much
> > > > > > needed clean up of the code and naming conventions within the fujitsu-laptop
> > > > > > driver.  I'm happy for this series (patches 1-10/10) to be applied.
> > > > > >
> > > > > > Signed-off-by: Jonathan Woithe <jwoithe@just42.net>
> > > > > 
> > > > > I have noticed people start using SoB for the code they are
> > > > > maintaining w/o sending any pull requests.
> > > > > It is okay, but there is, as Wolfram pointed, a downside for patchwork
> > > > > users. Patchwork is tracking tags (A/R/T) which by a glance allows to
> > > > > see what patches are acked/reviewed/tested.
> > > > 
> > > > Signed-off-by tracks the path the code takes from author to mainline. If you are
> > > > not the author or committing it to a tree followed by a pull-request, the
> > > > correct tag is "Reviewed-by".
> > > 
> > > Yes, of course - I clearly had a brain fade back there.  Having said that, 
> > > in the past I've used "Acked-by" intead of "Reviewed-by".
> > 
> > :-)
> > 
> > > Do you want me to continue to use Acked-by, or should I switch to
> > > Reviewed-by?
> > 
> > These tags do have different meanings, and have come up at Kernel Summit the
> > last couple of years. My interpretation of those discussions is:
> > 
> > Acked-by: I have no objection to this patch, but I didn't really give it a
> > thorough review. I trust your judgement. e.g. minor change to your driver to
> > support a subsystem API change. These are of very little value.
> > 
> > Reviewed-by: I have carefully reviewed this patch and would like it to be
> > applied. This should usually come with some sort of commentary describing the
> > level of review or an area you focused on. This is what we would like to see
> > from all of our driver maintainers. These are high value.
> > 
> > Linus *really* dislikes one line acked by's, and only *slightly* more so than
> > one line reviewed by's. :-)
> 
> This is really useful information and I think it does not deserve to be
> forgotten in a mailing list archive.  If this is indeed the status quo,
> Documentation/process/submitting-patches.rst could use some love.  Here
> is what it currently says:
> 
> > Acked-by: is often used by the maintainer of the affected code when that
> > maintainer neither contributed to nor forwarded the patch.
> 
> My short experience with the x86 platform driver subsystem is consistent
> with that.  The informal rule I inferred from mailing list discussions
> is that Acked-by: means the maintainer has reviewed the patch and sees
> no objections to it being applied.
> 
> Granted, Documentation/process/submitting-patches.rst also states that:
> 
> > Acked-by: does not necessarily indicate acknowledgement of the entire patch.
> > For example, if a patch affects multiple subsystems and has an Acked-by: from
> > one subsystem maintainer then this usually indicates acknowledgement of just
> > the part which affects that maintainer's code.  Judgement should be used here.
> > When in doubt people should refer to the original discussion in the mailing
> > list archives.
> 
> And indeed, that is also true, especially for patch series affecting
> multiple subsystems.
> 
> However, while the meaning of Reviewed-by: is described very thoroughly
> in that same document, I cannot recall a single case of a patch series
> affecting a single driver that would get a Reviewed-by: _from the
> maintainer_.  Let alone a Reviewed-by: with a description of review
> depth.  Perhaps I have read too little threads (or the wrong ones) :)
> 
> With time, I have also grown to believe that one of the differences
> between Acked-by: and Reviewed-by: is that anyone interested can offer
> their Reviewed-by: while Acked-by: is reserved for driver maintainers.
> 
> Perhaps this is all material for a "falsehoods kernel developers believe
> about commit tags"-type article ;)

Thanks Michał for your thoughts/experience. My definitions above are based
largely on the recent kernel summit discussions and if that is not reflected in
the submitting patches document, it should be. I'm happy to propose a patch to
that affect and hopefully that will shake out any differences of opinion on
definitions.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web