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: 34+ 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 2:40 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.