Mailinglist Archive: opensuse-project (189 mails)
| < Previous | Next > |
[opensuse-project] Release Cycle Changes
- From: James Tremblay aka SLEducator <fxrsliberty@xxxxxxxxxxx>
- Date: Tue, 06 Jan 2009 07:49:38 -0500
- Message-id: <49635362.7030006@xxxxxxxxxxx>
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx
| < Previous | Next > |