Le Mar 12 mars 2013 13:17, Hans de Goede a écrit : > Hi, > > On 03/12/2013 01:02 PM, Jiří Eischmann wrote: >> Allan Day píše v Út 12. 03. 2013 v 11:15 +0000: >>> Hi all, >>> >>> On the question of how kernel versions should be accessed, I am very >>> much in favour of the position that Chris Murphy expressed earlier: >>> choosing a kernel version is opaque to most users and requires fairly >>> advanced technical knowledge to understand. >> >> I agree, but unfortunately, it's not the case of Fedora. By having a >> rolling release policy for the kernel, we're forcing users to deal with >> kernel versions. >> I follow user forums quite a lot and I read it every day: I updated and >> my wireless card stopped working, my computer doesn't wake up from >> suspend, the system is now much slower. New kernels bring a lot of >> regressions and we don't have enough test coverage to avoid them. The >> general solution to those problems is to go back to the last working >> kernel version. But by making it less obvious we make these frequent >> problems more difficult to solve. > > Keep in mind that the not show the menu by default plan depends on > the bootspec changes, and that will include a gui tool which will > allow users to select things like show the menu (and then it won't have > a timeout so be easier to get to), or even to directly select the > kernel to boot next time. Any gui tool requires a successful boot Successful means kernel ok, systemd ok, selinux ok, x/wayland ok, gdm ok, gnome-shell ok (replace with other de equivalents) There are so many parts there where we *fail* the user regularly I don't see how can anyone reasonably propose to build any safety net over them. For example, how are you going to deal with gfx drivers that break after a kernel update? The system thinks all is fine, even though the display necessary for any gui is garbage. Or has anyone found the resources and consensus necessary to implement the draconian QA checks that would be necessary to make this safe? -- Nicolas Mailhot -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
