There has been a lot of discussion recently on the viability of a Long Term Support release for openSUSE. Some have proposed a separate LTS version, some a rolling release called Tumbleweed. Some have shown support for both, suggesting they coexist as separate sub-projects. Yet others have suggested we create an openSLES, a "free as in free beer"(to think that this phrase even exists) version for SUSE Enterprise, much like what the CentOS people do with RedHat Enterprise Linux.
This discussion has spiralled into multiple threads on the opensuse-project list. The threads have been linked to at the end of this post.
My reply in regards to the discussion is summed up below:-
1. I have a feeling the two being analogised to CentOS is a bit unfair. openSUSE's relation with SLE has always been more the Fedora to RHEL kind. We, as a project, form a base, not a copy of SUSE's enterprise offerings, if typically more conservatively than competition.
2. openSUSE has the direct primary sponsorship of Novell. CentOS has no official affiliation with RH. An openSLES may antagonise Novell/SUSE/Attachmate's friendly approach.
3. Offering of an LTS version alternately with a couple of normal versions has not been discussed. I wonder why. Ubuntu does that quite appreciably, (though I have never personally encountered an Ubuntu-powered server).
From Wikipedia, "To date every fourth release, in the second quarter of even-numbered years, has been designated as a Long Term Support (LTS) release, indicating that it has updates for three years for desktop use and five years for server"
To say what that means, let's say we have 12.0 as LTS(5 release cycle support), then 12.1, 12.2 and 12.3 with normal 2.2 cycle support. Then again 13.0 as LTS, and so on. This will cause an LTS version to be perennially active, while having a "cutting edge" version for systems here stability is not primary.
This would help a only one extra already present older version needs to be maintained, reducing stress on the developers.
4. The point mooted in (3) can also help on standardising a versioning scheme, the need for which was discussed but never finalised some time earlier, probably on the marketing and project lists.
5. Nelson Marques has a point. Too many offerings would cause confusion. Normal openSUSE vs openSUSE LTS vs openSUSE Tumbleweed vs openSLES has already confused me to an extent.
6. Someone suggested binary compatibility with SLES would make people recommend SLES for paid-for-support Linux. While I appreciate Novell's roles in what openSUSE is today, I personally feel SLES sales figures are not supposed to be the concern of the openSUSE project.
Furthermore, even openSUSE can be paid-for-support Linux, considering people pay for 90 day support or something like that when they buy the box.
Threads
[1] Announcing openSUSE Tumbleweed project Nov '10 Dec'10
[2] openSUSE LTS Nov '10 Dec'10
[3] Packman for Tumbleweed
This discussion has spiralled into multiple threads on the opensuse-project list. The threads have been linked to at the end of this post.
My reply in regards to the discussion is summed up below:-
1. I have a feeling the two being analogised to CentOS is a bit unfair. openSUSE's relation with SLE has always been more the Fedora to RHEL kind. We, as a project, form a base, not a copy of SUSE's enterprise offerings, if typically more conservatively than competition.
2. openSUSE has the direct primary sponsorship of Novell. CentOS has no official affiliation with RH. An openSLES may antagonise Novell/SUSE/Attachmate's friendly approach.
3. Offering of an LTS version alternately with a couple of normal versions has not been discussed. I wonder why. Ubuntu does that quite appreciably, (though I have never personally encountered an Ubuntu-powered server).
From Wikipedia, "To date every fourth release, in the second quarter of even-numbered years, has been designated as a Long Term Support (LTS) release, indicating that it has updates for three years for desktop use and five years for server"
To say what that means, let's say we have 12.0 as LTS(5 release cycle support), then 12.1, 12.2 and 12.3 with normal 2.2 cycle support. Then again 13.0 as LTS, and so on. This will cause an LTS version to be perennially active, while having a "cutting edge" version for systems here stability is not primary.
This would help a only one extra already present older version needs to be maintained, reducing stress on the developers.
4. The point mooted in (3) can also help on standardising a versioning scheme, the need for which was discussed but never finalised some time earlier, probably on the marketing and project lists.
5. Nelson Marques has a point. Too many offerings would cause confusion. Normal openSUSE vs openSUSE LTS vs openSUSE Tumbleweed vs openSLES has already confused me to an extent.
6. Someone suggested binary compatibility with SLES would make people recommend SLES for paid-for-support Linux. While I appreciate Novell's roles in what openSUSE is today, I personally feel SLES sales figures are not supposed to be the concern of the openSUSE project.
Furthermore, even openSUSE can be paid-for-support Linux, considering people pay for 90 day support or something like that when they buy the box.
Threads
[1] Announcing openSUSE Tumbleweed project Nov '10 Dec'10
[2] openSUSE LTS Nov '10 Dec'10
[3] Packman for Tumbleweed