January 2009 - openSUSE Project - openSUSE Mailing Lists

[opensuse-project] Release Cycle Changes
by James Tremblay aka SLEducator 06 Jan '09

06 Jan '09

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

1 0

[opensuse-project] Buildserver for OSS on AIX
by Hans-Joachim Ehlers 05 Jan '09

05 Jan '09

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

2 1

[opensuse-project] GCC RPMs and symbolic links
by Ian Nelson 05 Jan '09

05 Jan '09

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

2 1