On 12/07/2012 08:26 PM, Mark Bidewell wrote:IMHO it is not the "level" of things which is problematic.
>
> 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.
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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel