On Wed, 2009-08-05 at 23:05 -0700, Adam Williamson wrote: > The problem with that approach is that, in the conventional approach to > updates, the key factor is _continuity_. You don't change behaviour or > risk regressions. If an update fixes ten bugs but changes the behaviour > of some component people see every day - which is a fairly accurate > description of both KDE and GNOME point releases - it's not appropriate > to be an update, in this theory, because it means the updated product is > breaking the expectations of the the initial release. What your frazzled The kernel's a great example here, BTW. If we update F10 to kernel 2.6.29, the ATI proprietary driver will stop working. We don't care about proprietary software and yadda yadda yadda, but it's exactly the kind of behaviour change in a supposedly 'final' product that certain groups of users just don't want to have to deal with. It doesn't really matter that the driver's proprietary, even. The point is that an interface that could reasonably be expected not to change in a 'stable' operating system release, by conventional definitions, does change in Fedora. Similar with the changes from 2.6.29 to 2.6.31. If we were to bump F11 from 2.6.29 to 2.6.31, the NVIDIA proprietary driver and the rt2860sta wireless driver (and possibly other out-of-kernel network drivers, too...) would break. The kernel guys consider it fine to do this sort of breakage between point releases, and Fedora considers it fine to ship kernel point releases as updates for 'stable' releases (we've done this in the past, 2.6.29 is still planned for F10 - just stuck due to problems - and I don't see any indication we won't be doing the same for F11). Certain groups of users just don't want this hassle. They have enough pain getting their graphics card / wireless card / whatever bit of hardware working right _once_, they don't want to have to do it again every two months (or whenever the next kernel point release happens to come out). They figure, since it's a stable release, once they get something working it ought to _keep_ working. This is the scenario that's problematic as long as we don't have a reliable conservative update path available. Again, if we decide that's a hit we're willing to take, that's fine. To bring it back to where we came in, we have a problem in that the KDE team are following one policy (update to the latest KDE release on the basis that it brings in new shiny goodness and fixes more stuff than it breaks) while the GNOME team are following the other (don't go to the latest point release in the interest of consistency). This doesn't make sense - if some parts of the distro are going with the adventurous policy, it renders the caution of other parts essentially null and void. The caution of the GNOME team doesn't really work, overall, if the kernel is following the adventurous policy. Conservative users still aren't going to go with Fedora. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
