Sorry For the double post, I wanted to start a new thread. What if? The system was, "11 boxed" (SLE11rc1) and openSUSE 12.0 where the same ISO (with branding and repo changes), I'm suggesting three layers of release; dev, tester , "Joe Plumber"\SLE. For all Novell Linux "Nightly" repo would be for internal development - aka unstable "Factory" could be the community "devs" repo and provide 12.0.X, 12.1.X, etc. released quarterly and the only place to include new kernel and desktop changes but never in X.3.X A "tester", could install with the 12 ISO which had "factory-update" as its repo, then 12.1 would be an update\add-on\upgrade, the same for 12.2, etc. preferably still on 9 month cycle and released as a delta iso (smaller bandwidth) Using a "Delta" or cumulative type release format could take most of the work out of bug-fixing the "boxed" release. Joe, doesn't have to think much , he goes straight for "11 boxed" and can stay there until "13 boxed"(or "12 boxed" if he really wants an upgrade), otherwise grab 12.x iso and work with us. I think we can all agree that the initial install is what the community(aka "joe" and some testers)most dislike, I am told this is mostly do to kernel and major desktop changes. By scheduling these things early in our release development and with the "boxed" being built from a known kernel and desktop, this issue should disappear. Yes? When applications fail during release it's usually because there wasn't enough testing. Yes? I believe it's causing to many issues to add or wait to add a new kernel or desktop release just because it happens to be close to our next release. These need to done in the early (i.e.12.0.x-12.1.x)releases. The goal for boxed is for "Joe" who simply wants to replace Windows with ease.( a growing group of people according to Apples sales numbers). He doesn't care about a stale Gnome,KDE or openOffice if it works. He does care that if his HD dies he can reinstall everything including peripheral applications provided for, but not included in, the distro. By Defining a "dev" level, we invite people who literally develop openSUSE and components specific to openSUSE to contribute to sub-releases, which lets them test small changes on a faster pace. By defining a layer as "tester", we invite those who want to be part of the development and expect issues. Sysadmins and Application Engineers looking to make a specific application work better. By defining a "Boxed" version, we invite more of the general public to use openSUSE with confidence. By making these definitions clear, we take away the reviewers ability to complain about our missteps if he is reviewing "tester" or "dev" releases. Changing the release cycle and the release itself to a more reliable and consistent product would look like this: 12.0 -security fixes until 12.1 there is no need to support the testing layer any longer than the next release. 12.0.X - no more than 3 months and no less then 1.5 months from 12.0 - Repo only - no patches provided. (Quarterly releases) 12.1 - no more then 9 months from 12.0 - Repo and "Add-On"\Patch CD\Delta ISO - same support as 12.0 12.2 - "" 18 months"" 12.3 - ""24 months"" 12 "boxed" \ openSUSE 13- no more then 27 months from 12.0 - ISO and retail box - subscription updates and installation support for no less than 24 months. Realistically not a big change, but the change to a structured cumulative development cycle with early kernel and desktop updates as well as 3 months dedicated to "boxing" would go a long way politically. -- James Tremblay openSIS Product Specialist http://www.os4ed.com CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/education -- James Tremblay openSIS Product Specialist http://www.os4ed.com CNE 3,4,5 MCSE w2k CLE in training Registered Linux user #440182 http://en.opensuse.org/education -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org