All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Leon Romanovsky <leon@kernel.org>, linux-rdma@vger.kernel.org
Subject: Re: [PATCH 0/4] RDMA/srp: Handle dev_set_name() failure
Date: Tue, 30 Aug 2022 15:10:42 -0300	[thread overview]
Message-ID: <Yw5SolqHtQU2eh7a@ziepe.ca> (raw)
In-Reply-To: <f98c7a98-21e5-817b-df6c-04df777307c2@acm.org>

On Sun, Aug 28, 2022 at 12:50:28PM -0700, Bart Van Assche wrote:
> On 8/28/22 03:04, Leon Romanovsky wrote:
> > On Thu, Aug 25, 2022 at 02:38:56PM -0700, Bart Van Assche wrote:
> > > This patch series includes one patch that handles dev_set_name() failure and
> > > three refactoring patches. Please consider these patches for the next merge
> > > window.
> > 
> > You confuse me. "next merge window" means that patches are targeted to
> > -next, but you added stable@... tag and didn't add any Fixes lines.
> > 
> > I applied everything to rdma-next and removed stable@ tag.
> 
> Hi Leon,
> 
> Although it's not a big deal for this patch series, please do not modify patches
> without agreement from the patch author.
> 
> As far as I know adding a Fixes: tag if a Cc: stable tag is present is not required
> by any document in the Documentation/ directory?
> 
> I had not added a Fixes: tag because the issue fixed by patch 3/3 was introduced
> by the commit that added the ib_srp driver to the kernel tree. So it would be fine
> to backport the first three patches of this series to all older kernel versions to
> which the patches can be backported.

Generally I always want to see the Fixes tag because it aides everyone
in the ecosystem to know when they should consider the patch for
backporting with a simple uniform algorithm.

So marking the first commit as the thing being fixed is expected.

Jason

      parent reply	other threads:[~2022-08-30 18:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-25 21:38 [PATCH 0/4] RDMA/srp: Handle dev_set_name() failure Bart Van Assche
2022-08-25 21:38 ` [PATCH 1/4] RDMA/srp: Rework the srp_add_port() error path Bart Van Assche
2022-08-25 21:38 ` [PATCH 2/4] RDMA/srp: Remove the srp_host.released completion Bart Van Assche
2022-08-25 21:38 ` [PATCH 3/4] RDMA/srp: Handle dev_set_name() failure Bart Van Assche
2022-08-25 21:39 ` [PATCH 4/4] RDMA/srp: Use the attribute group mechanism for sysfs attributes Bart Van Assche
2022-08-28 10:04 ` [PATCH 0/4] RDMA/srp: Handle dev_set_name() failure Leon Romanovsky
2022-08-28 19:50   ` Bart Van Assche
2022-08-29  5:41     ` Leon Romanovsky
2022-08-30 18:10     ` Jason Gunthorpe [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=Yw5SolqHtQU2eh7a@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=bvanassche@acm.org \
    --cc=leon@kernel.org \
    --cc=linux-rdma@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.