Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1583047 > unrolled thread
| Started by | Darren Hart <dvhart@infradead.org> |
|---|---|
| First post | 2017-02-17 04:00 +0100 |
| Last post | 2017-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.
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
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-02-17 04:00 +0100 |
| Subject | Re: [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]
| From | Jonathan Woithe <jwoithe@just42.net> |
|---|---|
| Date | 2017-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]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-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]
| From | Jonathan Woithe <jwoithe@just42.net> |
|---|---|
| Date | 2017-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]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-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]
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Michał Kępień <kernel@kempniu.pl> |
|---|---|
| Date | 2017-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]
| From | Andy Shevchenko <andy.shevchenko@gmail.com> |
|---|---|
| Date | 2017-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]
| From | Michał Kępień <kernel@kempniu.pl> |
|---|---|
| Date | 2017-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]
| From | Darren Hart <dvhart@infradead.org> |
|---|---|
| Date | 2017-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