Received-SPF: pass (google.com: domain of linux-kernel+bounces-131744-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 4 Apr 2024 17:44:18 +0200
From: Greg KH <gregkh@linuxfoundation.org>
To: Linux regressions mailing list <regressions@lists.linux.dev>
Cc: Tejun Heo <tj@kernel.org>, Sasha Levin <sashal@kernel.org>,
	"stable@vger.kernel.org" <stable@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Do we need a "DoNotBackPort" tag? (was: Re: Hibernate stuck
 after recent kernel/workqueue.c changes in Stable 6.6.23)
Message-ID: <2024040454-playful-tainted-7446@gregkh>
References: <ce4c2f67-c298-48a0-87a3-f933d646c73b@leemhuis.info>
 <ZgylCe48FuOKNWtM@slm.duckdns.org>
 <b6cdb17f-206c-4dff-bb45-a60317e0a55e@leemhuis.info>
 <2024040328-surfacing-breezy-34c6@gregkh>
 <Zg10Keik4KORjXMh@slm.duckdns.org>
 <2024040319-doorbell-ecosystem-7d31@gregkh>
 <dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <dfd87673-c581-4b4b-b37a-1cf5c817240d@leemhuis.info>

On Thu, Apr 04, 2024 at 05:36:42PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 03.04.24 18:10, Greg KH wrote:
> > On Wed, Apr 03, 2024 at 05:22:17AM -1000, Tejun Heo wrote:
> >> On Wed, Apr 03, 2024 at 07:11:04AM +0200, Greg KH wrote:
> >>>> Side note: I have no idea why the stable team backported those patches
> >>>> and no option on whether that was wise, just trying to help finding the best
> >>>> solution forward from the current state of things.
> >>>
> >>> The Fixes: tag triggered it, that's why they were backported.
> 
> Yeah, this is what I assumed.
> 
> >>>>> which would
> >>>>> be far too invasive for -stable, thus no Cc: stable.
> >>>>>
> >>>>> I didn't know a Fixes
> >>>>> tag automatically triggers backport to -stable. I will keep that in mind for
> >>>>> future.
> >>>>
> >>>> /me fears that more and more developers due to situations like this will
> >>>> avoid Fixes: tags and wonders what consequences that might have for the
> >>>> kernel as a whole
> >>>
> >>> The problem is that we have subsystems that only use Fixes: and not cc:
> >>> stable which is why we need to pick these up as well.  Fixes: is great,
> >>> but if everyone were to do this "properly" then we wouldn't need to pick
> >>> these other ones up, but instead, it's about 1/3 of our volume :(
> 
> I'm also well aware of that and do not want to complain about it, as I
> think I grasped why the stable team works like that -- and even think
> given the circumstances it is round about the right approach. I also
> understand that mistakes will always happen.
> 
> Nevertheless this thread and the Bluetooth thing we had earlier this
> week[1] makes me fear that this approach could lead to developer
> avoiding Fixes: tags. And funny thing, that's something that is already
> happening, as I noticed by chance today: "'"A "Fixes" tag has been
> deliberately omitted to avoid potential test failures and subsequent
> regression issues that could arise from backporting."'"[2].
> 
> I wonder if that in the long term might be bad. But well, maybe it won't
> matter much. Still made me wonder if we should have a different solution
> for this kind of problem. Something like this?
> 
>   Cc: <stable@vger.kernel.org> # DoNotBackport
> 
> Or something like this?
> 
>   Cc: <stable@vger.kernel.org> # DoNotBackport - or only after 16 weeks
> in mainline [but I don't care]

We do this today, with stuff like:
	Cc: stable <stable@kernel.org>	# wait for -rc3 to be out

So if people want to do that, they can, the documentation says that you
can give us hints and the like in the # area, and usually we notice them :)

thanks,

greg k-h