<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 8, 2012 at 1:48 PM, Roberto Ragusa <span dir="ltr"><<a href="mailto:mail@robertoragusa.it" target="_blank">mail@robertoragusa.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/07/2012 08:26 PM, Mark Bidewell wrote:<br>
><br>
> 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:<br>
><br>
> Level 1 (Core) - OS Kernel, command-line utilities, C/C++ compiler and libc - moves the slowest.<br>
> Level 2 (System) - Dev Libraries, interpreters (Python, Ruby, etc), X11, KDE/QT, GNOME, etc - moves faster.<br>
> Level 3 (Userland) - LibreOffice, Firefox, Games, etc.<br>
><br>
> 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:<br>
><br>
> Level 1 - 12-18 mos<br>
> Level 2 - 6-12 mos<br>
> Level 3 - release as soon as stable packages are available.<br>
<br>
</div>IMHO it is not the "level" of things which is problematic.<br>
I have no problem with rapid updates for the kernel (great for hardware<br>
support and bug fixes), or for X11 (same reasons), gcc upgrades never<br>
gave me problems, I like the fast updates to KDE.<br>
<br>
There are two things which are problematic:<br>
<br>
1) projects undergoing great revolutions. They are quickly absorbed<br>
by Fedora and all the immaturity issues of the projects cast shadows on Fedora.<br>
Two examples: GNOME 2->3, KDE 3->4; exactly the same problem, upstream<br>
changing everything and users unhappy about the results (even if different<br>
answers were given by KDE ("wait, we will readd what is missing") and<br>
by GNOME ("forget what is missing, this is how it will be").<br>
Obviously a regression of the desktop environment is not a small detail<br>
for end users (read: "Fedora doesn't work").<br>
<br>
2) revolutions at the system level. Things that replace other things and<br>
everything changes: command line tools, GUIs, config files, logs, ...<br>
Many examples: pulseaudio, NetworkManager, systemd, grub2, firewalld.<br>
These projects sometimes have bugs (being in their infancy), often<br>
are badly documented and are always completely unknown by end users; the<br>
result is that things "do not work" and "who knows how this should be fixed".<br>
In many cases the impact on the collateral utilities (dracut,<br>
system-config-*, anaconda, ...) contribute to the chaos.<br>
<br>
As a final consideration, the fixability of the issues is important.<br>
I can easily revert to a previous kernel, I can less easily throw<br>
away pulseaudio, and I can in no way fix GNOME 3.<br>
<br>
(my two cents, as someone using Red Hat / Fedora daily since RH5.1, and<br>
never stepping up as Fedora packager because too scared by the bureaucracy)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Roberto Ragusa mail at <a href="http://robertoragusa.it" target="_blank">robertoragusa.it</a><br>
</font></span><div class="HOEnZb"><div class="h5">--<br>
devel mailing list<br>
<a href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/devel" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/devel</a></div></div></blockquote></div><br>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: </div>
<div class="gmail_extra">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.</div><div class="gmail_extra">2) Wait for the next OS release.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">It seems like there should be some way to improve this situation.<br clear="all"><div><br></div>-- <br>Mark Bidewell<br><a href="http://www.linkedin.com/in/markbidewell">http://www.linkedin.com/in/markbidewell</a><br>
</div>