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

Re: kernels in the packaging universe



Dave Jones schrieb:
> On Wed, Dec 20, 2006 at 04:21:35PM +0100, Thorsten Leemhuis wrote:
>  > [...] with a big, fat warning sign:
>  > - Use at your own risk
>  > - no guarantees for security updates
> This alone should be enough to be a nail in this coffin.
That's why I said "(semi-)official". I didn't mean to put those into
what's currently know as Core or Extras.

>  > - be aware that these kernels might miss features like Xen, tux, foo or
>  > bar that are in the main kernel package
>  > - no precompiled kmods are available
> You can add all the warning signs you want, but there's a fatal flaw.
>                     PEOPLE DON'T FSCKING READ THEM.

Sure, I think we all know that.

> [...] 
> To go through the examples you gave:

BTW, sure, I also thing we all also know that upstream is the best place
and that in an ideal world we would ship only one Fedora kernel per arch
that can do everything: Xen, kdump, kexec, PAE, non-PAE, foo, bar, baz

> RT : This needs to be upstream. And bits of it are going that way all
>      the time.

Ingo provides yum-able kernels for some weeks now and it seems to have
improved testing a lot, which should help getting it fixed and upstream.
Why not have a highlyexperimental.download.fedoraproject.org
for stuff like that?

> [...]
> Vanilla: Probably the only alternative kernel that actually makes sense.

Well, I'd say "that makes most sense", especially as we could tell out
users then "try that kernel; if it's broken, too, report the problem to
upstream please".

> mm: Seriously bad idea. Seriously. Bad. Idea.  The last one ate peoples
>  data. We cannot allow things like this into extras, even as an experiment,
>  even with a gazillion warnings that people will ignore.

Well, I think it would improve testing and that's what kernel-developers
normally want. I for example hit some cases where I would have used that
kernel to test if a bug I hit is solved in it. I was to lame to compile
a kernel myself so I was no help.

> [...]


CU
thl


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