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

Re: To what extent should Debian modify the kernel? (Re: Debian should not modify the kernels!)



Herbert Xu <herbert@gondor.apana.org.au> writes:

> Matt Zimmerman <mdz@debian.org> 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         dmaze@debian.org      http://people.debian.org/~dmaze/
"Theoretical politics is interesting.  Politicking should be illegal."
	-- Abra Mitchell



Reply to: