Re: [PATCH 1/4] drm/sched: optimize drm_sched_job_add_dependency

[Danilo Krummrich <dakr@kernel.org>]

On Wed, May 28, 2025 at 04:39:01PM +0200, Danilo Krummrich wrote:
> On Wed, May 28, 2025 at 09:29:30AM -0400, Alex Deucher wrote:
> > On Wed, May 28, 2025 at 8:45 AM Simona Vetter <simona.vetter@ffwll.ch> wrote:
> > > I do occasionally find it useful as a record of different approaches
> > > considered, which sometimes people fail to adequately cover in their
> > > commit messages. Also useful indicator of how cursed a patch is :-)
> > >
> > > But as long as anything relevant does end up in the commit message and
> > > people don't just delete stuff I don't care how it's done at all. It's
> > > just that the cost of deleting something that should have been there can
> > > be really nasty sometimes, and storage is cheap.
> > 
> > I like them for the same reasons.  Also, even with links, sometimes
> > there are forks of the conversation that get missed that a changelog
> > provides some insight into.  I find it useful in my own development as
> > I can note what I've changed in a patch and can retain that in the
> > commit rather than as something I need to track separately and then
> > add to the patches when I send them out.
> 
> Personally, I don't think it's super useful in the commit message, it still
> remains in the patches sent to the mailing list though. And since we put lore
> links everywhere, it's easily accessible, *including* the context of why a
> change was made from one version to another, i.e. the full conversation.
> 
> However, if we really want that, we should make it an offical thing, since
> currently the kernel's process documentation [1] clearly states otherwise:
> 
> "Please put this information after the '---' line which separates the changelog
> from the rest of the patch. The version information is not part of the changelog
> which gets committed to the git tree. It is additional information for the
> reviewers. If it's placed above the commit tags, it needs manual interaction to
> remove it."
> 
> Alternatively, it can go into the cover letter.

One additional note:

This is not me trying to be super bureaucratic; instead I think being consistent
in the process across the whole kernel results in a better experience for (new)
contributors.

> [1] https://docs.kernel.org/process/submitting-patches.html#commentary