On Sun, 12 Jan 2025 at 22:19, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Fri, Jan 10, 2025 at 12:53:41PM -0800, Umesh Nerlige Ramappa wrote:
> > commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16 upstream
>
> <snip>
>
> > Fixes: 8135f1c09dd2 ("drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close")
> > Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@xxxxxxxxx>
> > Reviewed-by: Matthew Brost <matthew.brost@xxxxxxxxx> # commit 1
> > Reviewed-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx>
> > Cc: stable@xxxxxxxxxxxxxxx # 6.12+
> > Reviewed-by: Jonathan Cavitt <jonathan.cavitt@xxxxxxxxx>
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@xxxxxxxxx>
> > Link: https://patchwork.freedesktop.org/patch/msgid/20241220171919.571528-2-umesh.nerlige.ramappa@xxxxxxxxx
> > (cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)
> > Signed-off-by: Thomas Hellström <thomas.hellstrom@xxxxxxxxxxxxxxx>
> > (cherry picked from commit f0ed39830e6064d62f9c5393505677a26569bb56)
>
> Oh I see what you all did here.
>
> I give up. You all need to stop it with the duplicated git commit ids
> all over the place. It's a major pain and hassle all the time and is
> something that NO OTHER subsystem does.
>
> Yes, I know that DRM is special and unique and running at a zillion
> times faster with more maintainers than any other subsystem and really,
> it's bigger than the rest of the kernel combined, but hey, we ALL are a
> common project here. If each different subsystem decided to have their
> own crazy workflows like this, we'd be in a world of hurt. Right now
> it's just you all that is causing this world of hurt, no one else, so
> I'll complain to you.
All subsystems that grow to having large teams (more than 2-4 people)
working on a single driver will eventually hit the scaling problem,
just be glad we find things first so everyone else knows how to deal
with it later.
>
> We have commits that end up looking like they go back in time that are
> backported to stable releases BEFORE they end up in Linus's tree and
> future releases. This causes major havoc and I get complaints from
> external people when they see this as obviously, it makes no sense at
> all.
None of what you are saying makes any sense here. Explain how patches
are backported to stable releases before they end up in Linus's tree
to me like I'm 5, because there should be no possible workflow where
that can happen, stable pulls from patches in Linus' tree, not from my
tree or drm-next or anywhere else. Now it might appear that way
because tooling isn't prepared or people don't know what they are
looking at, but I still don't see the actual problem.
>
> And it easily breaks tools that tries to track where backports went and
> if they are needed elsewhere, which ends up missing things because of
> this crazy workflow. So in the end, it's really only hurting YOUR
> subsystem because of this.
Fix the tools.
>
> And yes, there is a simple way to fix this, DO NOT TAG COMMITS THAT ARE
> DUPLICATES AS FOR STABLE. Don't know why you all don't do that, would
> save a world of hurt.
How do you recommend we do that, edit the immutable git history to
remove the stable
tag from the original commit?
>
> I'm tired of it, please, just stop. I am _this_ close to just ignoring
> ALL DRM patches for stable trees...
If you have to do, go do it. The thing is the workflow is there for a
reason, once you have a large enough team, having every single team
member intimately aware of the rc schedule to decide where they need
to land patches doesn't scale. If you can't land patches to a central
-next tree and then pick those patches out to a -fixes tree after a
maintainer realises they need to be backported to stable. Now I
suppose we could just ban stable tags on the next tree and only put
them on the cherry-picks but then how does it deal with the case where
something needs to be fixes in -next but not really urgent enough for
-fixes immediately. Would that be good enough, no stable tags in -next
trees, like we could make the tooling block it? But it seems like
overkill, to avoid fixing some shitty scripts someone is probably
selling as a security application.
Dave.
