On 7/10/05, David S. Miller <[EMAIL PROTECTED]> wrote: > From: Nish Aravamudan <[EMAIL PROTECTED]> > 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.
Great! Thanks for the quick feedback. I'll make sure this gets added to the KJ FAQ (mayhap even verbatim :) ) Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/