On Wed, Jan 15, 2025 at 10:11:00AM +0100, Greg KH wrote:
> On Tue, Jan 14, 2025 at 11:22:26AM +0200, Jani Nikula wrote:
> > On Tue, 14 Jan 2025, Dave Airlie <airlied@xxxxxxxxx> wrote:
> > > 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>
> > >>
> > >> 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.
> > >
> > > Let me try and work out what you think is the problem with this
> > > particular commit as I read your email and I don't get it.
> > >
> > > This commit is in drm-next as 55039832f98c7e05f1cf9e0d8c12b2490abd0f16
> > > and says Fixes: 8135f1c09dd2 ("drm/xe/oa: Don't reset
> > > OAC_CONTEXT_ENABLE on OA stream close)
> > >
> > > It was pulled into drm-fixes a second time as a cherry-pick from next
> > > as f0ed39830e6064d62f9c5393505677a26569bb56
> > > (cherry picked from commit 55039832f98c7e05f1cf9e0d8c12b2490abd0f16)
> > >
> > > Now the commit it Fixes: 8135f1c09dd2 is also at
> > > 0c8650b09a365f4a31fca1d1d1e9d99c56071128
> > >
> > > Now the above thing you wrote is your cherry-picked commit for stable?
> > > since I don't see
> > > (cherry picked from commit f0ed39830e6064d62f9c5393505677a26569bb56)
> > > in my tree anywhere.
> >
> > The automatic cherry-pick for 6.12 stable failed, and Umesh provided the
> > manually cherry-picked patch for it, apparently using -x in the process,
> > adding the second cherry-pick annotation. The duplicate annotation
> > hasn't been merged to any tree, it's not part of the process, it's just
> > what happened with this manual stable backport. I think it would be wise
> > to ignore that part of the whole discussion. It's really not that
> > relevant.
>
> On the contrary, this commit shows the whole problem very well. It is
> trivial for people to get confused, the author submitted a backport of a
> commit that is NOT in Linus's tree because they got an email telling of
> a failure and didn't use the correct id because they looked in the
> drm-next branch, NOT in Linus's branch.
>
> Which is why I flagged it, as the commit id used here was not a valid
> one at this point in time. Yes, after -rc1 it would be valid, but
> again, totally confusing.
>
> You all are seeing confusion with this development model. That's the
> issue. Whether or not it's intentional, that's the result. And because
> of it, I am telling you all, the kernel is less secure as it allows us
> all to get confused and mis backports and drop fixes incorrectly.
>
> So either you all change the process, or just live with it and the
> consequences of having total confusion at times and grumpy stable
> developers because of it, and less secure users due to missed bug and
> security fixes.
We won't change our process, because I couldn't find the maintainer
volunteers to make that happen. And I don't think you can find them for
me.
Full answer here:
https://lore.kernel.org/dri-devel/Z4d6406b82Pu1PRV@phenom.ffwll.local/
And all we need to sort out the fallout is that
- drm maintainers consistently add cherry-picked from lines (which means
you need to stop shouting about them)
- downstream consumers look at cherry-picked from lines to figure out all
the sha1 aliases a commit has, which with the dumbest git log script
here takes less than a second here to check
I've tried to explain this here in a reply to Sasha:
https://lore.kernel.org/dri-devel/Z4aNwGys3epVzf7G@phenom.ffwll.local/
And yes I'm aware this breaks your workflow, we've had these discussions
at regularly scheduled intervals for as long as we've been doing the
committer model. And I've been trying for as long to explain what you need
to adjust to cope, purely using scripts.
This shit is easy, except somehow here we are almost a decade later.
-Sima
--
Simona Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
