Re: Custom patched kernels in RPMFusion
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