Herbert Xu <[EMAIL PROTECTED]> writes: > Matt Zimmerman <[EMAIL PROTECTED]> wrote: >> >> So, I'm curious why you chose to make it a part of the Debian >> kernel source, rather than a separate patch (kernel-patch-ipsec or >> such). > > Well the reason for it to be in the default kernel-source is simple: > > The patch should be used on all default Debian kernel images unless > the arch maintainer chooses to override it.
That doesn't sound like it really answers the question... >> I suppose the more fundamental question is, what is your vision for the >> Debian kernel source? What do you feel belongs there, and what does not? > > Perhaps vision is too strong a word. > > I have some simple checks when it comes to patch inclusion: > > * Is it actively maintained by someone? > * If it's a feature, can it be disabled/enabled at runtime? > * If it's a bug fix, how bad are its side-effects? > * What size impact does it have to the binary kernel image? ...do you include *everything* that comes by you that meets these criteria? Because from this it sounds like anything that has an upstream that can be built as modules would be included. My particular directed thought right now is a somewhat invasive patch that updates the 2.4 kernels to use i2c-2.8, which would solve some headaches for me ("somewhat invasive", in that it also goes off and modifies all of the other drivers that depend on i2c); if I were the kernel maintainer, it'd trip a "too different from kernel.org" flag for me, but it sounds like it does meet your four criteria here. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell