[opensuse-project] release as an add-on?

older
[opensuse-project] Boxed editions...

James Tremblay aka SLEducator

22 Dec 2008 22 Dec '08

18:59

Hey guys, What are the obstacles to the idea of marketing a full release at X.0 and then releasing\marketing "patch CD updates" instead of full community sub-releases(still a fully installable dvd if desired, specifically for the x.3)? We would definitely be doing something different than the rest of the distro's (good PR) and if the patch cd could accomplish the same kinds of updates that we offer in our current sub-releases with less work and more stability for the end user, it would be a win\win\win: openSUSE team gets to show off YaST and Build Service, marketing gets to differentiate openSUSE, the end users need for a fresh install could be reduced. Extra possible "win" - "long term support "could more easily be moved to x.3 releases citing the x.1\x.2 as support levels for x.0. with the bonus side effect of reducing update channel bandwidth. i.e. security only on x.0 then nothing unless x.1 is applied (This is nothing new to major software vendors, can't tell you how many times I've heard "we only support that product at x.1.2.3, please upgrade.") then x.3s could also be easily translated to SLEs. It seems a waste that SuSE built YaST with all this functionality to not let openSUSE benefit from it's heritage. Any way , openSUSE is yet again filled with many exciting things while still delivering the hope of many more. I'm happy to play with 11.1, while drooling for 11.2 , just as I was the day after 11.0 released. Thanks for all the fun! JT -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Show replies by date

Kevin Dupuy

22 Dec 22 Dec

20:23

On Mon, 2008-12-22 at 13:59 -0500, James Tremblay aka SLEducator wrote:

...

Hey guys, What are the obstacles to the idea of marketing a full release at X.0 and then releasing\marketing "patch CD updates" instead of full community sub-releases(still a fully installable dvd if desired, specifically for the x.3)?

I want to address that idea, but there's something else I've been seeing lately in the mailinglists as we talk about the future of openSUSE development, etc. and that is the idea that we have "main releases" (10.0, 11.0) and "sub-releases" (11.1, 10.2, etc.), as if to say the big change is in the xx.0 release, and the .1, .2, & .3 releases are all just "add-ons" to that. IIRC, the numbers are just a branding thing, all releases are given the same amount of importance no matter their number (in other words, we could decide tomorrow to call openSUSE 11.2 "openSUSE 12.0", and although it would be a break with the normal versioning system, it would still be appropriate and the same level of attention and development would be given to it. I'm not saying I'd be totally against the idea of doing it the way you describe, which is basically the SLED & Windows strategy, release a main product (let's say openSUSE 12) then in 9 months issue a Service Pack for it (openSUSE 12 SP1), etc. The problem I'd see is that development wouldn't slow down, and we can't completely redesign or add tons of new features in an update to an already-released OS, as users wouldn't expect anything to change much as long as they're using the same product. This is where some of the "continual update" ideas for releases fall apart: normal, home users don't expect things to massively change in a typical system. Once they install one version, they learn it and know it. If they choose to upgrade to the next *version* of openSUSE a year or so down the road, then they expect some things to change, but not as a normal update for the system with the same version number. Now, on the topic of removing the need for users to have to fresh-install, I'm with you on that idea, but how would your proposal be any different than doing a Upgrade from the openSUSE disc now? Trust me, if Upgrades worked reliably, (and I'm not saying they don't, I haven't tried it in a while), then I would love the ability to give the disc to my family and say "choose Upgrade, wait for it to install, then BAM!". -- Kevin "Yeaux" Dupuy - openSUSE Member Public Mail: Merry Christmas & Happy Holidays from the Yeaux! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Rob OpenSuSE

20:39

2008/12/22 Kevin Dupuy :

...

On Mon, 2008-12-22 at 13:59 -0500, James Tremblay aka SLEducator wrote:

...

if Upgrades worked reliably, (and I'm not saying they don't, I haven't tried it in a while), then I would love the ability to give the disc to my family and say "choose Upgrade, wait for it to install, then BAM!".

Looking at the mail lists, and forum it doesn't. Not from 11.0 nor 10.2 to 11.1. There's problems with PAM, non booting, all issues which require good CLI to troubleshoot and fix. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Marcus Meissner

20:42

On Mon, Dec 22, 2008 at 08:39:35PM +0000, Rob OpenSuSE wrote:

...

2008/12/22 Kevin Dupuy :

...
On Mon, 2008-12-22 at 13:59 -0500, James Tremblay aka SLEducator wrote:

...
if Upgrades worked reliably, (and I'm not saying they don't, I haven't tried it in a while), then I would love the ability to give the disc to my family and say "choose Upgrade, wait for it to install, then BAM!".

Looking at the mail lists, and forum it doesn't. Not from 11.0 nor 10.2 to 11.1.

But you don't see the ones that succeeded in there.

...

There's problems with PAM, non booting, all issues which require good CLI to troubleshoot and fix.

Upgrade worked fine for me btw ;) Ciao, Marcus -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Rob OpenSuSE

20:54

2008/12/22 Marcus Meissner :

...

On Mon, Dec 22, 2008 at 08:39:35PM +0000, Rob OpenSuSE wrote:

...
2008/12/22 Kevin Dupuy :

...
On Mon, 2008-12-22 at 13:59 -0500, James Tremblay aka SLEducator wrote:

...
if Upgrades worked reliably, (and I'm not saying they don't, I haven't tried it in a while), then I would love the ability to give the disc to my family and say "choose Upgrade, wait for it to install, then BAM!".

Looking at the mail lists, and forum it doesn't. Not from 11.0 nor 10.2 to 11.1.

But you don't see the ones that succeeded in there.

...
There's problems with PAM, non booting, all issues which require good CLI to troubleshoot and fix.

Upgrade worked fine for me btw ;)

A good point, failure is loud, success often silent. But ... the ppl helping do say if things "worked for me". The phrase "I had that to" is actually more common. Part of it, is ppl trying "zypper dup" however. I'll try and look harder to find ppl discussing the new features, and how easy it was to install. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Alex Rodriguez

21:02

2008/12/22 Rob OpenSuSE :

...

A good point, failure is loud, success often silent. But ... the ppl helping do say if things "worked for me". The phrase "I had that to" is actually more common. Part of it, is ppl trying "zypper dup" however.

Just done that .... 1285 updates 1.3Gb to download :O -- Ing. Alejandro Rodriguez || @LeX Usuario Linux # 379802 openSUSE 11.0 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Boyd Lynn Gerber

23:39

On Mon, 22 Dec 2008, Rob OpenSuSE wrote:

...

2008/12/22 Marcus Meissner :

...
On Mon, Dec 22, 2008 at 08:39:35PM +0000, Rob OpenSuSE wrote:

...
2008/12/22 Kevin Dupuy :

...
On Mon, 2008-12-22 at 13:59 -0500, James Tremblay aka SLEducator wrote:

...
if Upgrades worked reliably, (and I'm not saying they don't, I haven't tried it in a while), then I would love the ability to give the disc to my family and say "choose Upgrade, wait for it to install, then BAM!".

Looking at the mail lists, and forum it doesn't. Not from 11.0 nor 10.2 to 11.1.

But you don't see the ones that succeeded in there.

...
There's problems with PAM, non booting, all issues which require good CLI to troubleshoot and fix.

Upgrade worked fine for me btw ;)

A good point, failure is loud, success often silent. But ... the ppl helping do say if things "worked for me". The phrase "I had that to" is actually more common. Part of it, is ppl trying "zypper dup" however.

I'll try and look harder to find ppl discussing the new features, and how easy it was to install.

zypper dup can be good, but one of my last updates/upgrades to 11.1 from 11.0 has so far taken more than 72 hours from a local 11.1/packman 11.1 set of repos'. It is still chugging away. at 16:00 it was 72 hours doing the zypper dup and it is still running. I think a lot of people have been having a lot of sucess. I have completed 67 installs. I have this zypper dup and 3 other machines left. I will ask my questions in an other thread. I did successul zypper dup to 11.0 fro 10.0, 10.1, 10.2, 10.3. I only did 4 zypper dup's of 11.0 to 11.1. So far everything has worked well. I think this release have been good. -- Boyd Gerber 801 849-0213 ZENEZ 1042 East Fort Union #135, Midvale Utah 84047 -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Cristian Rodríguez

23 Dec 23 Dec

00:42

Rob OpenSuSE escribió:

...

There's problems with PAM, non booting,

I have seen only two major upgrade complains: a) the PAM thingy. b) jexec stuck at boot (good luck! ;P) Anyway, I upgraded and it worked somewhat fine. -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/

Stephan Binner

22 Dec 22 Dec

23:11

On Monday 22 December 2008 21:23:53 Kevin Dupuy wrote:

...

IIRC, the numbers are just a branding thing, all releases are given the same amount of importance no matter their number (in other words, we could decide tomorrow to call openSUSE 11.2 "openSUSE 12.0", and

Looking forward to "openSUSE 13". Best marketing release version ever! :-) Bye, Steve -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Rob OpenSuSE

20:32

2008/12/22 James Tremblay aka SLEducator :

...

Extra possible "win" - "long term support "could more easily be moved to x.3 releases citing the x.1\x.2 as support levels for x.0. with the bonus side effect of reducing update channel bandwidth. i.e. security only on x.0 then nothing unless x.1 is applied (This is nothing new to major software vendors, can't tell you how many times I've heard "we only support that product at x.1.2.3, please upgrade.") then x.3s could also be easily translated to SLEs. It seems a waste that SuSE built YaST with all this functionality to not let openSUSE benefit from it's heritage.

That would also have a nice consistent story for the version numbers. If most of the destabilising and experimental stuff, came into an X.0 release, I don't think it's really viable to just have security fixes. So actually it'd be better to say that the X.3 version is the "stable", and have X.0, X.1 and X.2 getting updated for bug fixes, and new package versions, with the difficulty of introducing new features increasing greatly as the X.3 release approaches. Most openSUSE users will probably track the newer code then, but those who want to avoid the dislocation of the more developmental versions, can stop at X.3 until they feel comfortable, installing X+1.2 for example and then getting updates to X+1.3. How if X.3 is basically the same as SLED/SLES avoid the problem of internal competition, if it has LTS? OTOH if X.3 is freely copiable and effectively evaluation, developers would be encouraged to use it, and then later on their customers, would be deploying SLED/SLES most likely? An easy switch to get LTS, or to subscribe to updates, when X.3 is past it's short term support, might increase revenue. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

James Tremblay aka SLEducator

23 Dec 23 Dec

15:58

Rob OpenSuSE wrote:

...

2008/12/22 James Tremblay aka SLEducator :

...
Extra possible "win" - "long term support "could more easily be moved to x.3 releases citing the x.1\x.2 as support levels for x.0. with the bonus side effect of reducing update channel bandwidth. i.e. security only on x.0 then nothing unless x.1 is applied (This is nothing new to major software vendors, can't tell you how many times I've heard "we only support that product at x.1.2.3, please upgrade.") then x.3s could also be easily translated to SLEs. It seems a waste that SuSE built YaST with all this functionality to not let openSUSE benefit from it's heritage.

That would also have a nice consistent story for the version numbers.

If most of the destabilising and experimental stuff, came into an X.0 release, I don't think it's really viable to just have security fixes.

So actually it'd be better to say that the X.3 version is the "stable", and have X.0, X.1 and X.2 getting updated for bug fixes, and new package versions, with the difficulty of introducing new features increasing greatly as the X.3 release approaches.

Most openSUSE users will probably track the newer code then, but those who want to avoid the dislocation of the more developmental versions, can stop at X.3 until they feel comfortable, installing X+1.2 for example and then getting updates to X+1.3.

How if X.3 is basically the same as SLED/SLES avoid the problem of internal competition, if it has LTS?

I was thinking, LTS would only be the time between x.3s plus one dev cycle (approx. 24 months). so on the release of the next x.0 LTS would end.

...

OTOH if X.3 is freely copiable and effectively evaluation, developers would be encouraged to use it, and then later on their customers, would be deploying SLED/SLES most likely? An easy switch to get LTS, or to subscribe to updates, when X.3 is past it's short term support, might increase revenue.

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

Rob OpenSuSE

17:34

2008/12/23 James Tremblay aka SLEducator :

...

...
How if X.3 is basically the same as SLED/SLES avoid the problem of internal competition, if it has LTS?

I was thinking, LTS would only be the time between x.3s plus one dev cycle (approx. 24 months). so on the release of the next x.0 LTS would end.

But then support engineers, support buggy unstable releases for a long time. My thinking was to try and simplify things, so there's more "make sure your system is up to date" rather than having to support umpteen versions of things, on lots of releases. If you call the next release openSUSE 12, make 12.0 (early adopter) 12.1 and 12.2 mainly about bringing in updates from outside and bug fixing. Then openSUSE 12 would be 12.3 with the support, the media that actually works and installs, and needs fewer updates after installation. It's a change of perspective, the real release is the last one, that should be solid. Everything before is there to get that wide spread testing, that the beta & rc versions are not, on lots of hardware out in the field. Most users hate releases, because it's a big change, that can go wrong in ways they don't understand, and leaves them struggling to fix. Whilst it's a good point that you don't want updates doing a KDE 3 to KDE 4, change on you, in general things are evolving around a fairly stable stuff. Remember we used to get excited about libc updates, and big changes to gcc, now fewer and fewer ppl are having to care about things like that. Of course the key is, avoiding breakage when changes occur. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

James Tremblay aka SLEducator

18:46

Rob OpenSuSE wrote:

...

2008/12/23 James Tremblay aka SLEducator :

...
...
How if X.3 is basically the same as SLED/SLES avoid the problem of internal competition, if it has LTS?

I was thinking, LTS would only be the time between x.3s plus one dev cycle (approx. 24 months). so on the release of the next x.0 LTS would end.

But then support engineers, support buggy unstable releases for a long time. My thinking was to try and simplify things, so there's more "make sure your system is up to date" rather than having to support umpteen versions of things, on lots of releases.

If you call the next release openSUSE 12, make 12.0 (early adopter) 12.1 and 12.2 mainly about bringing in updates from outside and bug fixing. Then openSUSE 12 would be 12.3 with the support, the media that actually works and installs, and needs fewer updates after installation.

I must have misrepresented my thoughts, I was thinking this exact thing. 11.3 should be the only fully supported release in the 11.x series. 11.3 should remain supported until 13.1. 11.3-13.1 = 36 months which is about half of SLE life cycle and enough time to make SLE based on x.3s very stable without alot of extra work, while providing a very reasonable release cycle for SLE. so our model would look like this; 12.0 major revamp and early adopter aka factory = full dvd 12.1 version updates,bugfixes,security = upgrade dvd and\or patch cd 12.2 major bugfixes and security updates = upgrade dvd and\or patch cd 12.3 stable lts version and SLE RC1= full dvd or 12.0 stable lts version and SLE RC1 = dvd 12.1 major revamp and early adopter aka factory = dvd 12.2 version updates, bugfixes, security = upgrade dvd and\or patch cd 12.3 major bugfixes and security updates = upgrade dvd and\or patch cd with this second choice we get an extra 9 months to make 11.3 onto 12.0 and to advertise the change. In the end, I want my SLE's to upgrade with Zenworks schedules rather than be re-imaged. i.e. drop upgrade ISO onto installation server and schedule with Zenworks.

...

It's a change of perspective, the real release is the last one, that should be solid. Everything before is there to get that wide spread testing, that the beta & rc versions are not, on lots of hardware out in the field.

Most users hate releases, because it's a big change, that can go wrong in ways they don't understand, and leaves them struggling to fix. Whilst it's a good point that you don't want updates doing a KDE 3 to KDE 4, change on you, in general things are evolving around a fairly stable stuff. Remember we used to get excited about libc updates, and big changes to gcc, now fewer and fewer ppl are having to care about things like that. Of course the key is, avoiding breakage when changes occur.

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

Rob OpenSuSE

20:32

2008/12/23 James Tremblay aka SLEducator :

...

Rob OpenSuSE wrote:

...
2008/12/23 James Tremblay aka SLEducator : I think it was suggesting only security fixes for X.0 which misrepresented it.

The ppl on net who early adopt, need something in return, that would be bragging rights about the 'hottest' kernel, glibc and what ever else can be got out the door, and be of 'beta' quality.

...

so our model would look like this; 12.0 major revamp and early adopter aka factory = full dvd 12.1 version updates,bugfixes,security = upgrade dvd and\or patch cd 12.2 major bugfixes and security updates = upgrade dvd and\or patch cd 12.3 stable lts version and SLE RC1= full dvd

Factory helps produce 12.0, so those able to run that, have the newest stuff first. 12.0 - introduces things that are destabilising and new distro developments that need field testing (if poss) ; No DVD needed, just small size download and good net access. Anyone without could not keep up with the likely updates. Follow on releases, would provide iso's, 12.1, 12.2 would add things like KDE 4.3, GNOME 2.28 You do them to suit, not set in stone. Anyone who installed a previous 12.x series, ought to get the updates, so things are changing on them. That's a reward, for being 'brave' and trying the latest. Also you get ppl off versions of things, noone wants to support.

...

or 12.0 stable lts version and SLE RC1 = dvd 12.1 major revamp and early adopter aka factory = dvd 12.2 version updates, bugfixes, security = upgrade dvd and\or patch cd 12.3 major bugfixes and security updates = upgrade dvd and\or patch cd

with this second choice we get an extra 9 months to make 11.3 onto 12.0 and to advertise the change. In the end, I want my SLE's to upgrade with Zenworks schedules rather than be re-imaged. i.e. drop upgrade ISO onto installation server and schedule with Zenworks.

...
It's a change of perspective, the real release is the last one, that should be solid. Everything before is there to get that wide spread testing, that the beta & rc versions are not, on lots of hardware out in the field.

On option 2 style, I am concerned that you lose flexibility and end up delivering software that's 'stale'. 12.0, 12.1, 12.2 could follow relatively quickly, but be lower key, than 11.1 was. They'd be more focussed. The real release, the biggie would be that one in November, 12.3 becoming openSUSE 12, and the basis for SLES/SLED. The whole point is, you have the maximum number testing the same release, and you'ld get a gradual migration awaay from older release to the 'current' one, depending on their like of stability. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

James Tremblay aka SLEducator

24 Dec 24 Dec

03:23

Rob OpenSuSE wrote:

...

2008/12/23 James Tremblay aka SLEducator :

...
Rob OpenSuSE wrote:

...
2008/12/23 James Tremblay aka SLEducator :

I think it was suggesting only security fixes for X.0 which misrepresented it.

The ppl on net who early adopt, need something in return, that would be bragging rights about the 'hottest' kernel, glibc and what ever else can be got out the door, and be of 'beta' quality.

...
so our model would look like this; 12.0 major revamp and early adopter aka factory = full dvd 12.1 version updates,bugfixes,security = upgrade dvd and\or patch cd 12.2 major bugfixes and security updates = upgrade dvd and\or patch cd 12.3 stable lts version and SLE RC1= full dvd

Factory helps produce 12.0, so those able to run that, have the newest stuff first. 12.0 - introduces things that are destabilising and new distro developments that need field testing (if poss) ; No DVD needed, just small size download and good net access. Anyone without could not keep up with the likely updates.

Follow on releases, would provide iso's, 12.1, 12.2 would add things like KDE 4.3, GNOME 2.28 You do them to suit, not set in stone.

Anyone who installed a previous 12.x series, ought to get the updates, so things are changing on them. That's a reward, for being 'brave' and trying the latest. Also you get ppl off versions of things, noone wants to support.

...
or 12.0 stable lts version and SLE RC1 = dvd 12.1 major revamp and early adopter aka factory = dvd 12.2 version updates, bugfixes, security = upgrade dvd and\or patch cd 12.3 major bugfixes and security updates = upgrade dvd and\or patch cd

with this second choice we get an extra 9 months to make 11.3 onto 12.0 and to advertise the change. In the end, I want my SLE's to upgrade with Zenworks schedules rather than be re-imaged. i.e. drop upgrade ISO onto installation server and schedule with Zenworks.

...
It's a change of perspective, the real release is the last one, that should be solid. Everything before is there to get that wide spread testing, that the beta & rc versions are not, on lots of hardware out in the field.

On option 2 style, I am concerned that you lose flexibility and end up delivering software that's 'stale'.

I'm not sure an extremely polished 12.0 would be viewed as "stale", considering KDE4's status and the impending GNOME 2.28, we might even get kudo's for taking the extra time to solidify 12.0 while we make a "programatic" change to our delivery system. This could even gain us ground in terms of the "it just worked" comments. With this increase we would really be converting users to openSUSE that see Ubuntu as having more "user acceptance" before release. Bottom line, time taken to gain ground against the bugs isn't ever bad.

...

12.0, 12.1, 12.2 could follow relatively quickly, but be lower key, than 11.1 was. They'd be more focussed.

The real release, the biggie would be that one in November, 12.3 becoming openSUSE 12, and the basis for SLES/SLED.

The whole point is, you have the maximum number testing the same release, and you'ld get a gradual migration awaay from older release to the 'current' one, depending on their like of stability.

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

Rob OpenSuSE

12:39

2008/12/24 James Tremblay aka SLEducator :

...

Rob OpenSuSE wrote:

...
2008/12/23 James Tremblay aka SLEducator :

...

I'm not sure an extremely polished 12.0 would be viewed as "stale", considering KDE4's status and the impending GNOME 2.28, we might even get kudo's for taking the extra time to solidify 12.0 while we make a "programatic" change to our delivery system. This could even gain us ground in terms of the "it just worked" comments. With this increase we would really be converting users to openSUSE that see Ubuntu as having more "user acceptance" before release. Bottom line, time taken to gain ground against the bugs isn't ever bad.

It was later on in the 12 series, I was concerned about. Then having 12.0 as a stable release, then doing a big revamp for 12.1, and restabilising for a 'final' at 12.3, seems to be mixing messages. And KDE, well the missing functionality and useability issues are hopefully going to be solved by new development releases 4.3, rather than by bug fixes to 4.1 series say. There's no guarantee that taking time, will result in something deliverable, that has both the functionality expected, and is solid without need for many bugfix updtes. How often is openSUSE meant to be 'delivering' a base for SLES/SLED? The issues mentioned in the 11.2 schedule were : - Need more testers, earlier - Stability of release alpha releases was sometimes better than RC - Need for development cycle time - Trouble scheduling to avoid just missing releases of KDE & GNOME - Some reviewers & testers, find 11.1 GM would have benefited from more fixes for things found testing and feedback on usability - openSUSE release, needs new cool things and up to date packages to interest the Press - users want it to "'just work" I think I've understood this right, that 11.2 isn't destined for SLES/SLED but in future - good basis for SLES/SLED would be a requirement Looking at all that, I think a possible solution, is a radically different release model, one not based on evenly spread "releases" throughtout the calendar year. For 11.2, to summarise suggested proposal, as stands : - development ongoing - whole load of alpha's - whole load of beta's - 2 RC late in cycle (GNOME 2.28 not ready yet) - Big Bang 11.2; releasing late autumn I don't know why (apart from being helpful to openSUSE) I'd use an alpha, or a beta there. Nor, whether I have to throw an install away. Is it testing the installation process? New software versions? Alternative "Creshendo" System, aims : - more testing, more inclusion of changes based on user feedback - more convenient for most users, 1 install or big uprade per year to get to latest release - each release of ISO's has a main focus, and the beta label can be removed based on quality - allows shipping stuff when it's ready, based on quality - simple marketing message, you're using openSUSE 12. - objective is to deliver up to date (latest KDE/GNOME), best tested distro in Novemember - 2 supported releases in 2 years, not 3 A hybrid of "Rolling Release" and traditional planned date based release, to try and get the advantage of both. Everyone on the same better tested version, at end of year; one that would "just work" on wider range of hardware, and be a solid release that can have better focussed support, during the 'development' cycle. Where only Factory is unstable. - Net Install ISO 12.0 early for early adopters, after couple Alpha's, and Q1 Development - "Current release" has rolling updates, so the user base grows organically - ISO & Live CD 12.1beta with a KDE 4.3 beta? For installation testing - ISO & Live CD 12.1, new KDE 4.3 (12.0 -> 12.1 via updates) Net Release CD/DVD for K-er's - ISO & Live CD 12.2beta with a GNOME-2.28 beta? For installation testing - ISO & Live CD 12.2, new GNOME 2.28 (12.1 -> 12.2 via updates) Net Release CD/DVD for G-er's - 12.3 - usability improvements developed with feedback, bug fixes (12.2 -> 12.3) Net & Physical Media Very well tested upgrade 11.1 -> 12.3. In that system, to upgrade "Release Version" (this needs changes to Update Tools) - apply all updates - unlocks the upgrade to next Release Version, option (edit /etc/issue and upgrade packages from new version) When your system is not up to date, you are informed that there's a new release, but online updates must be applied first. Via the "updater" tool that tells you when there's security patches, and updated software available. The 12.0, 12.1, 12.2 only get short term support, once next release is out, because every user is a net user who's accepting the "Current" release, if they want support. Those who want "stability" and minimum changes, ought to go with 11 series + security patches; until they're ready for OS 12.3. Because the majority of development is done by, 12.1/12.2 stage, then the development cycle for next release, can begin in the Autumn, with aim to make it available for 13.0 late spring. That's a lot of time, without worrying about general users, so should allow big changes. Psychologically, I think more ppl will use the current version because of "Rolling Release", and you're spreading out the load of end user migration, by appealing to sub-sections of the user base. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Gerald Pfeifer

7 Jan 7 Jan

14:05

On Tue, 23 Dec 2008, James Tremblay aka SLEducator wrote:

...

I must have misrepresented my thoughts, I was thinking this exact thing. 11.3 should be the only fully supported release in the 11.x series. 11.3 should remain supported until 13.1.

openSUSE is not officially supported at all (at least not by Novell, apart from installation support for the box).

...

11.3-13.1 = 36 months

If the community wants to provide security and whatever updates for that long, that's fine. It is _extremely_ unlikely Novell is going to fund that; already those 24 months are a stretch. Gerald -- Dr. Gerald Pfeifer E gp@novell.com SUSE Linux Products GmbH Director Inbound Product Mgmt T +49(911)74053-0 HRB 16746 (AG Nuremberg) openSUSE/SUSE Linux Enterprise F +49(911)74053-483 GF: Markus Rex -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Joe 'Zonker' Brockmeier

14:14

On Wed, Jan 7, 2009 at 9:05 AM, Gerald Pfeifer wrote

...

On Tue, 23 Dec 2008, James Tremblay aka SLEducator wrote:

...
I must have misrepresented my thoughts, I was thinking this exact thing. 11.3 should be the only fully supported release in the 11.x series. 11.3 should remain supported until 13.1.

openSUSE is not officially supported at all (at least not by Novell, apart from installation support for the box).

For purposes of this conversation, I think supported == "still is updated" and receives security updates. It should be (I hope) understood that is what's (I think) actually being discussed. See the last "end of life" notice here: http://lists.opensuse.org/opensuse-security-announce/2008-08/msg00004.html "It is now officially discontinued and out of support."

...

...
11.3-13.1 = 36 months

If the community wants to provide security and whatever updates for that long, that's fine. It is _extremely_ unlikely Novell is going to fund that; already those 24 months are a stretch.

Indeed. Just to add to that -- I wouldn't recommend it. Previous efforts to support community releases long term (i.e., Fedora Legacy, IIRC) tend to falter because that's just not popular work. Best, Zonker -- Joe 'Zonker' Brockmeier openSUSE Community Manager jzb@zonker.net http://zonker.opensuse.org/ http://blogs.zdnet.com/community/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Christian Boltz

16:53

New subject: Security updates (was: Re: [opensuse-project] release as an add-on?)

Hello, on Mittwoch, 7. Januar 2009, Gerald Pfeifer wrote: ...

...

If the community wants to provide security and whatever updates for that long, that's fine. It is _extremely_ unlikely Novell is going to fund that; already those 24 months are a stretch.

I understand that the security updates need lots of resources, but please keep the 24 months. Otherwise openSUSE will have less chances to be used on servers - I consider 24 months the lowest-possible timeframe. (I know that you recommend SLES for servers ;-) but lots of "root servers" come with openSUSE preinstalled. The "big" providers I know don't offer root servers with SLES preinstalled.) Maybe Novell could even make some money without much additional work ;-) The idea is to offer paid security updates for the X.1 releases (aka those that are the SLES base - the updates are created for the SLES customers anyway) after X.1 goes out of support. This would mean: method a) - a supported way for openSUSE 11.1 -> SLES 11 "migration" when openSUSE 11.1 goes out of support (shouldn't be too hard IMHO since most package versions should be identical) - offer paid security updates for those systems - which are now SLES systems - and a list that shows which packages are supported (aka SLES packages) and which aren't (aka packages not contained in SLES) method b) - don't "migrate" the whole system to SLES 11, just - provide paid securicy updates as needed - this might include version updates to the SLES package version - and also here: a list showing which packages are supported and which aren't Both methods would be OK for customers - I'd say SUSE could just choose the way that is easier to handle internally. This offer might attract people who don't want to upgrade to a newer openSUSE release on their live server. And maybe these people even choose SLES for their next server from the beginning. I don't see a real risk that companies don't buy SLES from the beginning since it has more added value (support etc.) than just security updates. BTW: I already discussed this with some SUSE/Novell people at the last LinuxTag in the hotel, and the feedback was quite positive. However, I didn't hear/read anything about this afterwards, so maybe it got lost. Regards, Christian Boltz -- .: Schneewittchen & die Pfälzer Waldconnection :. Ein polit-kabarettistisches Märchenstück mit viel Musik gesungen & gespielt von Mitgliedern der Landjugend RheinhessenPfalz 18.1.2009 Berlin - 6.2.2009 Neustadt - Infos: www.LJ-RheinhessenPfalz.de -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Joe 'Zonker' Brockmeier

22 Dec 22 Dec

21:17

On Mon, Dec 22, 2008 at 1:59 PM, James Tremblay aka SLEducator wrote:

...

Hey guys, What are the obstacles to the idea of marketing a full release at X.0 and then releasing\marketing "patch CD updates" instead of full community sub-releases(still a fully installable dvd if desired, specifically for the x.3)? We would definitely be doing something different than the rest of the distro's (good PR) and if the patch cd could accomplish the same kinds of updates that we offer in our current sub-releases with less work and more stability for the end user, it would be a win\win\win: openSUSE team gets to show off YaST and Build Service, marketing gets to differentiate openSUSE, the end users need for a fresh install could be reduced.

In my opinion, patch CD updates aren't desirable from a marketing standpoint at all. Very hard to interest journalists in a story about a patch CD. Different is sometimes good, but not always. This is separate from whether people should be able to update the system using YaST / Zypper. That's very desirable, and I think it's something that the team is working towards.

...

Any way , openSUSE is yet again filled with many exciting things while still delivering the hope of many more. I'm happy to play with 11.1, while drooling for 11.2 , just as I was the day after 11.0 released. Thanks for all the fun!

That's what we want, more people drooling. :-) (Wait, that doesn't sound quite right...) Best, Zonker -- Joe 'Zonker' Brockmeier openSUSE Community Manager jzb@zonker.net http://zonker.opensuse.org/ http://blogs.zdnet.com/community/ -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

Kevin Dupuy

23 Dec 23 Dec

03:52

On Mon, 2008-12-22 at 16:17 -0500, Joe 'Zonker' Brockmeier wrote:

...

That's what we want, more people drooling. :-)

C'mon Zonker, I just got finished mopping up the place from Thursday! -- Kevin "Yeaux" Dupuy - openSUSE Member Public Mail: Merry Christmas & Happy Holidays from the Yeaux! -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org

5589

Age (days ago)

5605

Last active (days ago)

List overview

Download

20 comments

11 participants

participants (11)

Alex Rodriguez
Boyd Lynn Gerber
Christian Boltz
Cristian Rodríguez
Gerald Pfeifer
James Tremblay aka SLEducator
Joe 'Zonker' Brockmeier
Kevin Dupuy
Marcus Meissner
Rob OpenSuSE
Stephan Binner