Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@linaro.org>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/selftests: Add some missing error propagation
Date: Mon, 5 Jun 2023 16:43:41 +0300	[thread overview]
Message-ID: <b47de249-085d-482a-afb2-eee82a06aba8@kadam.mountain> (raw)
In-Reply-To: <20230605131135.396854-1-tvrtko.ursulin@linux.intel.com>

On Mon, Jun 05, 2023 at 02:11:35PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Add some missing error propagation in live_parallel_switch.
> 
> To avoid needlessly burdening the various backport processes, note I am
> not marking it as a fix against any patches and not copying stable since
> it is debug/selftests only code.
> 

This patch is unlikely to make a difference in real life, but I don't
think avoiding Fixes tags and backports is the right thing.

I would add a Fixes tag and not add a stable tag.

The real burden with Fixes tags is if it breaks someone's system.  But
if it's breaking selftests then hopefully those are the people best
able to deal with it.

Fixes tags are different from stable tags.  If the code is very recent
then the fixes tag can automatically allow us to filter out that patch
from going back to stable.  So for new patches Fixes is the opposite of
CC'ing stable.

If the bug is old, then adding a Fixes tag does increase the chance of a
backport though, that's true.

My guess is that if the stable maintainers thought that selftests/ were
causing too much issue with backports they would add a grep line to
their scripts to solve that problem.  Instead we were having the
opposite discussion the other week where the bpf people didn't want to
backport selftest stuff and Greg wanted to.
https://lore.kernel.org/all/2023052647-tacking-wince-85c5@gregkh/

regards,
dan carpenter


  reply	other threads:[~2023-06-05 13:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05 13:11 [Intel-gfx] [PATCH] drm/i915/selftests: Add some missing error propagation Tvrtko Ursulin
2023-06-05 13:43 ` Dan Carpenter [this message]
2023-06-05 14:54   ` Tvrtko Ursulin
2023-06-05 13:47 ` Andi Shyti
2023-06-06  9:44   ` Tvrtko Ursulin
2023-06-05 15:18 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2023-06-05 15:32 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-06-06 11:21 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork

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=b47de249-085d-482a-afb2-eee82a06aba8@kadam.mountain \
    --to=dan.carpenter@linaro.org \
    --cc=Intel-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.intel.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