Re: [PATCH 0/82] changing CONFIG_LOCALVERSION rebuilds too much, for no good reason.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/10/05, Jeff Garzik <[email protected]> wrote:
> David S. Miller wrote:
> > Kernel janitor-like patches split up their work _FAR_ too much.  They
> > post one patch per driver, or even per-file, for something as simple
> > as removing the use of a redundant header file.  That's totally
> > rediculious, and bloats up the kernel changelog history for no good
> > reason.  Instead, you should just post one big patch for all of
> > drivers/, one for all of net/, something like that.
> 
> 
> Whoops, in an email just sent, I repeated what you said here, except
> that you said it better :)
> 
> 100% agreed...

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.

There is already a patch pending for the KJ FAQ from Domen Puncer
(http://lists.osdl.org/pipermail/kernel-janitors/2005-July/004438.html)
to note that the same logical change can be made for all of
drivers/net, e.g., in one patch, but it's still not quite clear how
the appropriate CCs should be respected. We should probably make that
as clear as possible now.

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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux