Re: KDE vs. GNOME on F10

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

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux