[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e28175e3-f62a-460d-88bc-3d9d5be78e11@igalia.com>
Date: Thu, 12 Jun 2025 14:46:59 +0100
From: Tvrtko Ursulin <tvrtko.ursulin@...lia.com>
To: Danilo Krummrich <dakr@...nel.org>, phasta@...nel.org
Cc: Lyude Paul <lyude@...hat.com>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Matthew Brost <matthew.brost@...el.com>,
Christian König <ckoenig.leichtzumerken@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, Thomas Zimmermann <tzimmermann@...e.de>,
Sumit Semwal <sumit.semwal@...aro.org>,
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@....com>,
dri-devel@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [RFC PATCH 0/6] drm/sched: Avoid memory leaks by canceling
job-by-job
On 11/06/2025 22:21, Danilo Krummrich wrote:
>> On Tue, 2025-06-03 at 13:27 +0100, Tvrtko Ursulin wrote:
>>> On 03/06/2025 10:31, Philipp Stanner wrote:
>>> What I am not that ecstatic about is only getting the Suggested-by
>>> credit in 1/6. Given it is basically my patch with some cosmetic
>>> changes
>>> like the kernel doc and the cancel loop extracted to a helper.
>>
>> Sign the patch off and I give you the authorship if you want.
>
> AFAICS, the proposal of having cancel_job() has been a review comment which has
> been clarified with a reference patch.
Right, this one:
https://lore.kernel.org/dri-devel/20250418113211.69956-1-tvrtko.ursulin@igalia.com/
> IMO, the fact that after some discussion Philipp decided to go with this
> suggestion and implement the suggestion in his patch series does not result in
> an obligation for him to hand over authorship of the patch he wrote to the
> person who suggested the change in the context of the code review.
It is fine. Just that instead of rewriting we could have also said
something along the lines of "Okay lets go with your version after all,
just please tweak this or that". Which in my experience would have been
more typical.
> Anyways, it seems that Philipp did offer it however, so this seems to be
> resolved?
At the end of the day the very fact a neater solution is going in is the
main thing for me. Authorship is not that important, only that the way
of working I follow, both as a maintainer and a colleague, aspires to be
more like what I described in the previous paragraph.
I am not sure I can review this version though. It feels it would be too
much like reviewing my own code so wouldn't carry the fully weight of
review. Technically I probably could, but in reality someone else should
probably better do it.
Regards,
Tvrtko
Powered by blists - more mailing lists