Re: Can't seem to find a maintainer for init/* files

From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Paulo Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: Can't seem to find a maintainer for init/* files
Date: Fri, 18 Oct 2019 19:25:12 -0400	[thread overview]
Message-ID: <131515.1571441112@turing-police> (raw)
In-Reply-To: <CAMLg8QgejaXgeDH83wdCt_-VEE4w4a1wntwrs+UXiehfzSNWsA@mail.gmail.com>

[-- Attachment #1.1: Type: text/plain, Size: 1989 bytes --]

On Sat, 19 Oct 2019 10:33:00 +1300, Paulo Almeida said:

> 1 - This specific code block has been around for quite some time and many
> additions using the correct printk(KERN_* were made after it was written.
> Does that mean that this code block is an exception and should be left
> as-is for some technical reason? Or, people have somehow forgotten about it
> and I finally found something to do? :)

There's a meta-consideration or two here to think about.

First, many maintainers are not thrilled with trivial patches to code,
especially checkpatch cleanups.  That's because those patches fall into two
major categories:

The patch is against code that's debugged and rock solid stable.  Most of
do_mounts.c is close to a decade old, and it's only being changed when it's
needed to add an actual feature (such as mounting by partition label in 2018
or mounting a CIFS filesystem this year).  And we *have* had what looked like
"trivial checkpatch cleanup" patches that were buggy and broke stuff.

The other category is "patches against code that's being worked on".  If it's
something that somebody else is working on, it can cause merge conflicts, which
make maintainers grumpy.  So the maintainer only wants to see those cleanups if
they're by the person who's working on the code, at the front of the patch
series, so that (presumably) they don't have merge commits and they've gotten
some compile and run testing.

The other big consideration is git.  Yes, git knows where and when every single
line of code came from.  That doesn't mean it's always easy to get it to cough
up information.

For example:   'git blame init/do_mounts.c'.  That tells you where each line came from.
Now... imagine a commit that did a spaces-to-tabs cleanup on lines 249 to 257.
git blame' now lists the cleanup commit, not the 6 commits that added the original code.

Exercise for the reader:  Determine the easiest way to get 'git blame' to show you
the original 6 commits rather than the cleanup.

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies