From: Danilo Krummrich <dakr@kernel.org>
To: Asahi Lina <lina@asahilina.net>
Cc: airlied@gmail.com, simona@ffwll.ch,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, lyude@redhat.com, acurrid@nvidia.com,
daniel.almeida@collabora.com, j@jannau.net, ojeda@kernel.org,
alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH 0/8] DRM Rust abstractions
Date: Tue, 8 Apr 2025 21:17:59 +0200 [thread overview]
Message-ID: <Z_V2ZxIZxI_HiHM5@cassiopeiae> (raw)
In-Reply-To: <143206f6-cd97-4ef8-a4f3-f68d703903bf@asahilina.net>
On Wed, Apr 09, 2025 at 03:06:38AM +0900, Asahi Lina wrote:
> On 4/9/25 2:04 AM, Danilo Krummrich wrote:
> > On Wed, Apr 09, 2025 at 01:29:35AM +0900, Asahi Lina wrote:
> >> On 3/26/25 8:54 AM, Danilo Krummrich wrote:
> >
> > You said "use it/submit it in any way".
>
> I thought keeping authorship is an implied part of kernel etiquette.
> Usually when you submit code someone else wrote, you keep them as
> primary author... I want you and others to use the code, that doesn't
> mean I want you to put your name on it as if you wrote most of it.
The broader context of the private mail was about you stepping back on kernel
development. You did so with a few more details (which I'm not going to
disclose), that made it clear to me that you don't want to be bothered with
kernel development any more.
In combination with you giving permission to "use it/submit it in any way", I
thought it's better to just pick a safe path to not misrepresent you given all
the changes I made.
I do still credit you on all corresponding patches though.
> >> I'm really tired of kernel politics and I don't want to spend more brain
> >> cycles looking at all the other patches or having to argue (in fact I
> >> usually don't look at patch emails at all recently), but I would
> >> appreciate if you keep my authorship for files that I did largely author
> >> myself. After everything I've been going through the past weeks (some of
> >> the people on Cc know what that's about...) this feels like yet another
> >> slap in the face.
> >
> > As mentioned, please diff the correct thing and then just tell me where you'd
> > like to have primary authorship changed.
>
> I don't even know what tree this series is supposed to apply onto (tried
> drm-misc next, torvalds/master, v6.15-rc1) so I'm just going to take
> drm-misc/topic/rust-drm and assume that's what this series includes.
>
> $ diff -urN rust/kernel/drm/drv.rs ../uplinux/rust/kernel/drm/driver.rs
> | grep '^+' | wc -l
> 45
>
> So I'm diffing the correct thing now and the result is essentially
> identical.
>
> Meanwhile, device.rs has many additions... but a big chunk of those is
> code that was just moved from drv.rs (like drm_legacy_fields and the
> code that uses it).
Except drm_legacy_fields! and VTABLE (which is just trival boilerplate code)
device.rs changed fundamentally, i.e. I switched the device abstraction to use
the subclassing pattern.
If you look further you will find that I really changed a lot of things.
I have *nothing* to hide, here's the overall diff for all the changes I made:
[1] https://pastebin.com/FT4tNn5d
>
> Again, I don't have the spoons to make some deep analysis here, you
> should know how much of the code you changed, added, or just moved
> around. I'm not going to litigate this further. If you think splitting
> up a commit into multiple commits and moving code around warrants taking
> over primary authorship of a project I've been working on for years now,
> so be it.
You just said you "don't have the spoons to make some deep analysis here" and
right below you acuse me of just "moving code around".
Which means that you do so *without* evidence. And again, I have *nothing* to
hide, see [1].
Besides that I also told you that I'm fine to change primary authership, if you
tell me where you think it would be appropriate (even though I do think my
changes do justify how things are currently).
> I'm just disappointed.
That's where you are maneuvering *yourself* into.
You could have easily just asked me to change things for patch #X, #Y and #Z.
Instead you outright started with accusing me of things. I also feel like you
intentionally try to misrepresent what I am doing and what my intentions are.
I neither have the time, nor am I willing to deal with random drama like this.
If you want something changed, just go ahead and tell me what, *without* more
drama and without more accusing me of things.
next prev parent reply other threads:[~2025-04-08 19:18 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 23:54 [PATCH 0/8] DRM Rust abstractions Danilo Krummrich
2025-03-25 23:54 ` [PATCH 1/8] drm: drv: implement __drm_dev_alloc() Danilo Krummrich
2025-03-26 8:46 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 2/8] rust: drm: ioctl: Add DRM ioctl abstraction Danilo Krummrich
2025-03-25 23:54 ` [PATCH 3/8] rust: drm: add driver abstractions Danilo Krummrich
2025-03-26 9:05 ` Maxime Ripard
2025-03-28 22:00 ` Lyude Paul
2025-03-28 22:46 ` Danilo Krummrich
2025-03-25 23:54 ` [PATCH 4/8] rust: drm: add device abstraction Danilo Krummrich
2025-03-26 9:12 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 5/8] rust: drm: add DRM driver registration Danilo Krummrich
2025-03-26 9:24 ` Maxime Ripard
2025-03-26 10:46 ` Danilo Krummrich
2025-03-28 14:28 ` Maxime Ripard
2025-03-28 14:50 ` Danilo Krummrich
2025-04-10 9:23 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 6/8] rust: drm: file: Add File abstraction Danilo Krummrich
2025-03-28 14:42 ` Maxime Ripard
2025-03-25 23:54 ` [PATCH 7/8] rust: drm: gem: Add GEM object abstraction Danilo Krummrich
2025-03-25 23:54 ` [PATCH 8/8] MAINTAINERS: add DRM Rust source files to DRM DRIVERS Danilo Krummrich
2025-03-28 14:49 ` Maxime Ripard
2025-03-28 14:50 ` Danilo Krummrich
2025-04-08 16:29 ` [PATCH 0/8] DRM Rust abstractions Asahi Lina
2025-04-08 17:04 ` Danilo Krummrich
2025-04-08 18:06 ` Asahi Lina
2025-04-08 19:17 ` Danilo Krummrich [this message]
2025-04-09 7:49 ` Asahi Lina
2025-04-09 21:29 ` Dave Airlie
2025-04-10 4:33 ` Asahi Lina
2025-04-10 7:12 ` Asahi Lina
2025-04-10 10:23 ` Danilo Krummrich
2025-04-10 12:37 ` Asahi Lina
2025-04-10 13:33 ` Danilo Krummrich
2025-04-11 0:43 ` Dave Airlie
2025-04-11 6:53 ` Asahi Lina
2025-04-10 6:44 ` Simona Vetter
2025-04-10 8:14 ` Asahi Lina
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=Z_V2ZxIZxI_HiHM5@cassiopeiae \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acurrid@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=j@jannau.net \
--cc=lina@asahilina.net \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=tzimmermann@suse.de \
/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;
as well as URLs for NNTP newsgroup(s).