[lkml]   [2005]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 0/82] changing CONFIG_LOCALVERSION rebuilds too much, for no good reason.
From: Nish Aravamudan <>
Date: Sun, 10 Jul 2005 21:18:15 -0700

> A quick question here regarding the possibility of one logical change
> for all of drivers/. Does that hold true for *any* logical change?
> Intuitively, I would say no. My biggest concern with that is there are
> many Maintainers listed for particular SCSI drivers, e.g., as well as
> one for the SCSI subsystem. If those individual driver maintainers'
> files are being modified, should they be CC'ed, or is the big patch
> just sent to the SCSI maintainer (in this example)? I just want to
> make sure the correct patch-chain is respected.

Please just use common sense. It depends upon how intrusive the
change is. In most cases, the driver author's have to learn to
"let go" and let these general cleanups happen. The onus is on
them to follow upstream when the submit new changes of their own.

Some examples:

1) Deleting superfluous header file.

Just do a clean sweep.

2) Adding a new argument to an existing interface.

Just do a clean sweep.

3) Transitioning drivers over to a new exception handling mechanism.

Probably want to do submit a patch for driver at a time. You
should be doing more a few of these driver conversions at a time
anyways, so no risk of patch bombing.

4) Straight forward transformations, for example hiding data
structure member access behind a function or macro.

Just do a clean sweep in large chunks.

Again, use common sense. If you're just crossing your "T"'s and
dotting your "i"'s, don't spam everyone with a thousand patches
for such a cleanup.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-11 07:02    [W:0.088 / U:1.468 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site