On Wed, Sep 22, 2010 at 15:34:34 +0100, "Richard W.M. Jones" <rjones@xxxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
