Where are we going? (Not a rant)

[Mark Bidewell]

On Sat, Dec 8, 2012 at 1:48 PM, Roberto Ragusa <mail at 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
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

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
http://www.linkedin.com/in/markbidewell
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20121208/79c3a94f/attachment.html>