From: Darren Hart <dvhart@infradead.org>
To: "Michał Kępień" <kernel@kempniu.pl>
Cc: Jonathan Woithe <jwoithe@just42.net>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Andy Shevchenko <andy@infradead.org>,
Platform Driver <platform-driver-x86@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 00/10] fujitsu-laptop: renames and cleanups
Date: Fri, 24 Feb 2017 14:13:18 -0800 [thread overview]
Message-ID: <20170224221318.GB30506@wisp> (raw)
In-Reply-To: <20170217071451.GA1369@ozzy.nask.waw.pl>
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
prev parent reply other threads:[~2017-02-24 22:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-08 13:46 [PATCH 00/10] fujitsu-laptop: renames and cleanups Michał Kępień
2017-02-08 13:46 ` [PATCH 01/10] platform/x86: fujitsu-laptop: clearly denote backlight-related symbols Michał Kępień
2017-02-08 13:46 ` [PATCH 02/10] platform/x86: fujitsu-laptop: replace "hotkey" with "laptop" in symbol names Michał Kępień
2017-02-08 13:46 ` [PATCH 03/10] platform/x86: fujitsu-laptop: make platform-related variables match naming convention Michał Kępień
2017-02-08 13:46 ` [PATCH 04/10] platform/x86: fujitsu-laptop: rename FUNC_RFKILL to FUNC_FLAGS Michał Kępień
2017-02-08 13:46 ` [PATCH 05/10] platform/x86: fujitsu-laptop: replace numeric values with constants Michał Kępień
2017-02-08 13:46 ` [PATCH 06/10] platform/x86: fujitsu-laptop: remove redundant forward declarations Michał Kępień
2017-02-08 13:46 ` [PATCH 07/10] platform/x86: fujitsu-laptop: simplify acpi_bus_register_driver() error handling Michał Kępień
2017-02-08 13:46 ` [PATCH 08/10] platform/x86: fujitsu-laptop: only register backlight device if FUJ02B1 is present Michał Kępień
2017-02-13 2:40 ` [lkp-robot] [platform/x86] b925ff7dcd: BUG:unable_to_handle_kernel kernel test robot
2017-02-13 4:34 ` Jonathan Woithe
2017-02-13 8:14 ` Michał Kępień
2017-02-13 12:26 ` Jonathan Woithe
2017-02-08 13:46 ` [PATCH 09/10] platform/x86: fujitsu-laptop: autodetect LCD interface on all models Michał Kępień
2017-02-08 13:46 ` [PATCH 10/10] platform/x86: fujitsu-laptop: remove redundant MODULE_ALIAS entries Michał Kępień
2017-02-08 15:24 ` [PATCH 00/10] fujitsu-laptop: renames and cleanups Andy Shevchenko
2017-02-09 1:36 ` Darren Hart
2017-02-09 1:46 ` Andy Shevchenko
2017-02-09 6:57 ` Michał Kępień
2017-02-08 22:52 ` Jonathan Woithe
2017-02-09 7:29 ` Michał Kępień
2017-02-10 0:16 ` Jonathan Woithe
2017-02-10 0:42 ` Andy Shevchenko
2017-02-17 2:57 ` Darren Hart
2017-02-17 3:08 ` Jonathan Woithe
2017-02-17 3:53 ` Darren Hart
2017-02-17 4:17 ` Jonathan Woithe
2017-02-17 5:23 ` Darren Hart
2017-02-24 20:34 ` Andy Shevchenko
2017-02-26 11:30 ` Michał Kępień
2017-02-26 15:03 ` Andy Shevchenko
2017-02-17 7:14 ` Michał Kępień
2017-02-24 22:13 ` Darren Hart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170224221318.GB30506@wisp \
--to=dvhart@infradead.org \
--cc=andy.shevchenko@gmail.com \
--cc=andy@infradead.org \
--cc=jwoithe@just42.net \
--cc=kernel@kempniu.pl \
--cc=linux-kernel@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox