rust-for-linux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Airlie <airlied@gmail.com>
To: Asahi Lina <lina@asahilina.net>
Cc: Danilo Krummrich <dakr@kernel.org>,
	maarten.lankhorst@linux.intel.com, simona@ffwll.ch,
	 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,
	rust-for-linux@vger.kernel.org,  dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 0/8] DRM Rust abstractions
Date: Fri, 11 Apr 2025 10:43:09 +1000	[thread overview]
Message-ID: <CAPM=9tyXAdaota38cgeQc86teEebe9XOnBTZ+aDBZpzEBApD9A@mail.gmail.com> (raw)
In-Reply-To: <88270028-7541-4184-a118-96c182109804@asahilina.net>

>
> > However, I understand that you prefer to have primary authorship, even if the
> > code has been re-organized in new commits, moved, modified or rewritten.
>
> Correct.

For anyone working in this area that is intending to upstream anything
from asahi, I think if code is rewritten completely it's probably not
consistent to keep the primary author. Copyright doesn't cover ideas,
it covers the code. It's fine to add acknowledgements and other tags.
For all the other cases where it's just moving code around or
modifying it, please try and retain the primary author. I'd suggest if
anyone is basing stuff on the Asahi tree, they try to take things
as-is as closely as possible, then use subsequent commits to
clean/fix/rework, this might mean we have to live with some messy
history that isn't easily bisectable, but I think to avoid any
confusion later and to keep from repeatedly bothering Lina with kernel
development questions on what is acceptable for what patches, we
should try to remain consistent here.

If you write new code from scratch without reference to the asahi tree
at all, please try and state this is a clean implementation to avoid
future possible confusions, if you are aware there is asahi code,
though I realise that could be contradictory. There are often cases
where there is only one way to write some code and I'd rather we don't
fall into unwarranted accusations of bad behaviour.

Dave.

  parent reply	other threads:[~2025-04-11  0:43 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
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 [this message]
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='CAPM=9tyXAdaota38cgeQc86teEebe9XOnBTZ+aDBZpzEBApD9A@mail.gmail.com' \
    --to=airlied@gmail.com \
    --cc=a.hindborg@kernel.org \
    --cc=acurrid@nvidia.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=dakr@kernel.org \
    --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).