Mailinglist Archive: opensuse-project (189 mails)

[James Tremblay aka SLEducator <fxrsliberty@xxxxxxxxxxx>]

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


-- 
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx