On Wed, Sep 22, 2010 at 15:34:34 +0100,
"Richard W.M. Jones" <rjones(a)redhat.com> wrote:
No, I think you are wrong.
First of all, I can see no benefit in pushing a package that cannot do
its basic function to Rawhide. Even in Rawhide, no one wants a kernel
that doesn't boot, even if in some circumstances they could go to the
trouble of downgrading their kernel. If we can test these situations
easily and reject these packages, we should just do it. (libguestfs
%check is a proof by example that such a thing is possible and easy in
Koji).
My issue was with how much of a problem broken kernels in rawhide are.
It's still a problem, but not as big of a problem as other random
breakage when trying to run rawhide as your desktop.
Secondly, it does matter that in Rawhide you can at least get to the
login prompt, log in, and get a shell. AIUI this was the basic idea
behind the critical path packages. From the shell you have a hope of
fixing things. Your browser not working is a problem you might be
able to fix with a shell. Your kernel hanging under disk load or
hanging in init scripts (both actual problems with the current Rawhide
kernel) is a good deal more complex to fix.
Sure, but if you don't automatically switch to the new kernel on every
update (there's a setting to control this), you won't likely run into
that because of a kernel update. You might have something else cause that
though. The downside is that at some point you need to manually go in
and switch kernels.