From: Dan Carpenter <dan.carpenter@oracle.com>
To: Stefan Wahren <stefan.wahren@i2se.com>
Cc: Fabio Aiuto <fabioaiuto83@gmail.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Nicolas Saenz Julienne <nsaenz@kernel.org>,
linux-staging@lists.linux.dev
Subject: Re: [PATCH 01/20] staging: vchiq_core: fix return type of vchiq_init_state
Date: Mon, 17 May 2021 14:25:54 +0300 [thread overview]
Message-ID: <20210517112554.GG1955@kadam> (raw)
In-Reply-To: <129774c3-884b-19e2-68ab-b1a8d8763458@i2se.com>
On Sun, May 16, 2021 at 11:38:10AM +0200, Stefan Wahren wrote:
> Hi Fabio,
>
> Am 16.05.21 um 09:27 schrieb Fabio Aiuto:
> > Hi Stefan,
> >
> > On Sat, May 15, 2021 at 09:10:40PM +0200, Stefan Wahren wrote:
> >> Recent commit "staging: vchiq_core: drop vchiq_status from vchiq_init_state"
> >> missed to change the return type in the definition. Let's fix this now.
> > if this patch fixes something that a previous commit broke,
> > it's better adding Fixes: tag
>
> the mentioned commit is still in next, so a Fixes tag doesn't make sense
> to me. Or do i miss something?
>
This patch doesn't affect runtime so a Fixes tag is not strictly
required although probably most of the times we would add it. But it
doesn't matter whether or not the commit is in -next or not. The git
hash from the fixes tag will remain valid unless Greg rebases (which he
seldom does). And if a maintainer rebases their tree, they are
responsible for updating the Fixes tag.
Fixes tags are useful for backporting because you can see that the bug
was introduced in the latest release so the patch doesn't need to be
backported.
But it's not all about backporting they're also useful for review so we
can see why a patch was introduced. Or sometimes I like to look at the
fixes tags and see if "cleanup" patches are introducing bugs into
staging etc.
regards,
dan carpenter
next prev parent reply other threads:[~2021-05-17 11:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-15 19:10 [PATCH 00/20] staging: vchiq_arm: more code clean-up Stefan Wahren
2021-05-15 19:10 ` [PATCH 01/20] staging: vchiq_core: fix return type of vchiq_init_state Stefan Wahren
2021-05-16 7:27 ` Fabio Aiuto
2021-05-16 9:38 ` Stefan Wahren
2021-05-16 16:54 ` Fabio Aiuto
2021-05-17 11:25 ` Dan Carpenter [this message]
2021-05-15 19:10 ` [PATCH 02/20] staging: vchiq_core: drop unnecessary release_count Stefan Wahren
2021-05-15 19:10 ` [PATCH 03/20] staging: vchiq_core: separate postfix increment Stefan Wahren
2021-05-16 7:31 ` Fabio Aiuto
2021-05-15 19:10 ` [PATCH 04/20] staging: vc04_services: remove __VCCOREVER__ Stefan Wahren
2021-05-15 19:10 ` [PATCH 05/20] staging: vchiq_arm: balance braces for if-else statements Stefan Wahren
2021-05-15 19:10 ` [PATCH 06/20] staging: vchiq_core: introduce poll_services_of_group Stefan Wahren
2021-05-15 19:10 ` [PATCH 07/20] staging: vchiq_core: avoid indention in poll_services_of_group Stefan Wahren
2021-05-15 19:10 ` [PATCH 08/20] staging: vchiq_arm: Use define for doorbell irq Stefan Wahren
2021-05-15 19:10 ` [PATCH 09/20] staging: vchiq_arm: drop ftrace-like logging Stefan Wahren
2021-05-15 19:10 ` [PATCH 10/20] staging: vchiq_arm: Prefer kzalloc(sizeof(*waiter)...) Stefan Wahren
2021-05-15 19:10 ` [PATCH 11/20] staging: vchiq_arm: drop non-beneficial comments Stefan Wahren
2021-05-15 19:10 ` [PATCH 12/20] staging: vchiq_arm: add blank line after declarations Stefan Wahren
2021-05-15 19:10 ` [PATCH 13/20] staging: vchiq_arm: re-arrange function header Stefan Wahren
2021-05-15 19:10 ` [PATCH 14/20] staging: vchiq_core: reduce indention in release_service_messages Stefan Wahren
2021-05-15 19:10 ` [PATCH 15/20] staging: vchiq_core: fix comment in vchiq_shutdown_internal Stefan Wahren
2021-05-15 19:10 ` [PATCH 16/20] staging: vchiq_arm: make vchiq_shutdown_internal return void Stefan Wahren
2021-05-15 19:10 ` [PATCH 17/20] staging: vchiq_arm: Avoid unnecessary line breaks Stefan Wahren
2021-05-15 19:10 ` [PATCH 18/20] staging: vchiq_core: introduce parse_message Stefan Wahren
2021-05-17 11:49 ` Dan Carpenter
2021-05-17 17:38 ` Stefan Wahren
2021-05-18 7:36 ` Dan Carpenter
2021-05-15 19:10 ` [PATCH 19/20] staging: vchiq_core: introduce defines for close_recvd Stefan Wahren
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=20210517112554.GG1955@kadam \
--to=dan.carpenter@oracle.com \
--cc=fabioaiuto83@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-staging@lists.linux.dev \
--cc=nsaenz@kernel.org \
--cc=stefan.wahren@i2se.com \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).