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(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
Hi,
sorry for jumping in with a pretty off topic question but at least it’s a place to start.
I would like to create a build server for OSS running on AIX since the support from IBM for OSS on AIX is pretty marginal.
The software versions build for AIX shall be equal to a given SLES version. This gives the opportunity to run the same software on AIX and Linux.
An AIX server and compiler are available and reachable via the internet.
So the question I have:
- Is this the right group to ask question about the OpenSuse Build server and services ?
- Is there any documentation about the Suse Build Service ?
- Does the OpenSuse build system is sutiable /usable for such a task ?
tia
Hajo
--
Hans-Joachim Ehlers
Unix System Engineer
I see that the GCC package installs binaries with a version suffix and creates a link. gcc43 install /usr/bin/gcc-4.3 and gcc-4.3 installs the symbolic link gcc->gcc-4.3.
I've been hacking on an RPM for LLVM 2.4 and Ada has been giving me some issues, gnatmake and gnatlink and gnatbind are installed with a suffix but no link and the GCC frontend configure script doesn't work with that. Is this a defect? Against which package? It seems as if it is but I know that probably isn't that popular.
Ian
--
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org
