> For example, making it so key applications and development stacks could >> easily float from one base OS to the next would make it less of an issue >> when the base OS needs to be upgraded. >> > > Not sure I catch your drift here, but it sounds like it could cause API > mismatch headaches. > >> >> 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. -- Mark Bidewell http://www.linkedin.com/in/markbidewell
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
