Custom patched kernels in RPMFusion

[Thorsten Leemhuis]

On 09.01.2009 10:22, Hans de Goede wrote:
> Felix Kaechele wrote:
>> I already shared my idea of providing custom patched kernels in
>> RPMFusion with Thorsten and he said that it would be an interesting
>> thing to do.

I feel a bit misquoted ;-) To be precise, this is what I said on IRC:

"I'm not sure if that's a good idea or not, but yes, I have thought 
about that as well; best to ask on the list"

>> But I also, of course, want to know the opinion of the
>> other contributors as this is a decision that should be made by not only
>> a few people.
> 
> Strong -1,

For me it gets a -0.5; but there might be cases where I maybe might give 
it a 0 or a +1

> one kernel is more then enough.

Yes, one kernel should be the goal. The PAE, smp and (in the past) xen 
kernels already created a lot of confusion and make kmod handling for 
users and developers harder.

> If you've got good reasons to want 
> extra patches in to the kernel you should take it up with Dave Jones (the 
> Fedora kernel maintainer), as long as there is a good chance of them getting 
> upstream eventually, he usually is quite willing to carry patches as long as 
> someone else does the work.

+1

> If they are not going upstream, it would be better to spend energy there 
> (getting it upstream) then building custom kernels IMHO.

I tend to agree, but OTOH:

> The only exception I can see is having a kernel with the realtime patch set. 

Agreed. But this kind of opens the door to other kernel sets as well :-/

> And maybe there are one or two more invasive patchsets which would be 
> interesting to have as alternate kernel, 

OpenVZ anyone for example? They are working with upstream (just like the 
rt guys), but that takes a while, thus I'd tend to say it might be 
acceptable as well if a rt kernel is.

> but in general for smaller patches I say no!

Agreed. But it's hard to draw the line.

Maybe it's really time to start a experimental repo for things like 
that. People are interested in crazy things -- we don't stop them by 
saying no. They instead will simply do it somewhere else, which it tend 
to say is not ideal either.

Or, IOW: Not sure, but even getting the crazy/stupid things into some 
special place within the RPM Fusion project might be better for everyone 
involved.

CU
knurd