On Sat, Dec 8, 2012 at 1:48 PM, Roberto Ragusa <mail@robertoragusa.it> wrote:
On 12/07/2012 08:26 PM, Mark Bidewell wrote:
> It underscores the need for the base OS or core to be absolutely as small as possible.  FreeBSD provides a good model, small installed system customized with packages/ports.  Personally I would like to see a three-level approach:
> Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - moves the slowest.
> Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, KDE/QT, GNOME, etc - moves faster.
> Level 3 (Userland) - LibreOffice, Firefox, Games, etc.
> A major change to one level should cause a rebuild of higher layers to avoid the API issues you mention.  Changes within a layer should be independent.  I would propose change rates of:
> Level 1 - 12-18 mos
> Level 2 - 6-12 mos
> Level 3 - release as soon as stable packages are available.

IMHO it is not the "level" of things which is problematic.
I have no problem with rapid updates for the kernel (great for hardware
support and bug fixes), or for X11 (same reasons), gcc upgrades never
gave me problems, I like the fast updates to KDE.

There are two things which are problematic:

1) projects undergoing great revolutions. They are quickly absorbed
by Fedora and all the immaturity issues of the projects cast shadows on Fedora.
Two examples: GNOME 2->3, KDE 3->4; exactly the same problem, upstream
changing everything and users unhappy about the results (even if different
answers were given by KDE ("wait, we will readd what is missing") and
by GNOME ("forget what is missing, this is how it will be").
Obviously a regression of the desktop environment is not a small detail
for end users (read: "Fedora doesn't work").

2) revolutions at the system level. Things that replace other things and
everything changes: command line tools, GUIs, config files, logs, ...
Many examples: pulseaudio, NetworkManager, systemd, grub2, firewalld.
These projects sometimes have bugs (being in their infancy), often
are badly documented and are always completely unknown by end users; the
result is that things "do not work" and "who knows how this should be fixed".
In many cases the impact on the collateral utilities (dracut,
system-config-*, anaconda, ...) contribute to the chaos.

As a final consideration, the fixability of the issues is important.
I can easily revert to a previous kernel, I can less easily throw
away pulseaudio, and I can in no way fix GNOME 3.

(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and
never stepping up as Fedora packager because too scared by the bureaucracy)

   Roberto Ragusa    mail at robertoragusa.it

I hear you.  I will admit I haven't thought through all of the possible permutations.  Probably a better criterion would be impact of ABI changes.  What I would like to see changed is the fact that, right now (and this goes for all Linux distros),  if you want to have the smallest probability of upgrade  issues, all packages must upgrade at once - preferably with a clean install.  On other OSs, If I want a new version of Libreoffice I can download and install it.  On Linux, your choices are: 
1)  Install from source or packages may be available from the developer and take the risk that they might not play nice with the rest of the system.
2)  Wait for the next OS release.

It seems like there should be some way to improve this situation.

Mark Bidewell