Mailinglist Archive: opensuse-project (142 mails)
| < Previous | Next > |
Re: [opensuse-project] End of life - what does it mean ?
- From: Andreas Vetter <vetter@xxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 16 Apr 2008 18:12:50 +0200 (CEST)
- Message-id: <Pine.LNX.4.64.0804161801350.1376@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Wed, 16 Apr 2008, James Tremblay wrote:
So you want all openSUSE users to upgrade every 8 months?
That is impossible. 2 years is acceptable and sometimes even that is too
short.
Another use of e.g. 10.1 is as a additional repo for SLES10, because you
don't get all the software you need on a Server from the SLES, SLED and
SLE SDK repos.
You said x.1 should be x.0+SP. But it is hopefully not.
A SP for a SLE product does not change the kernel and probably glibc.
A newer openSUSE version always had newer Kernel, glibc, gcc, X, KDE, ...
A possible way to go is enlarging the time between releases even more. We
already moved from 6 months to 8 months. Maybe even more.
--
Mit freundlichen Gruessen,
Andreas Vetter
Fakultaet fuer Physik und Astronomie
Universitaet Wuerzburg
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx
This whole thread brings back a point I've been trying to make for over
a year now. The point, openSUSE should not bother itself with LTS(long
term support) for 3 (4 if SLE counted) distributions. I say, starting
with 11.0 provide only support and fixes until 11.1(which should be an
online upgrade via zypper)then only support 11.1 until 11.2, then 11.2
until 11.3 then give 11.3 a full three years support bringing us around
to 12.3, this means that the team is only ever supporting 2 community
distro's and one enterprise at a time and the *.3s can become new
releases for SLE. This would make it clear that the other versions are
truly community and that, to get the 5+ years a server should have, a
person needs to subscribe to SLE. This should not offend openSUSE\SUSE
customers and it should please and even entice non-enterprise
subscribers to look more closely at SLE. While allowing more resources
to be available to packaging a really nice retail box for the *.3s.
Can anyone estimate the energy used to patch 10.3 that could have been
avoided if the Devs were not back porting fixes to 10.1 and 10.2, but
already working full-time on only 10.2+ when 10.3 was due to begin?
These interim releases aren't much different than a SP anyway why not
release them that way? openSUSE has a patch disk mechanism.
Does anyone else see the wheel being reinstalled every time we take the
car for a drive? Isn't a Distro that upgrades rather than replaces more
flexible for the enthusiast and more reliable to the consumer? How much
Alpha testing can be removed if *.2 truly is *.1 plus fixes?
My vision in practice:
Joe Consumer running 9.3: "Hey cool, 10.3 is out, I can't wait to see
the new .....I have been hearing a lot of cool stuff about 10 and 9 has
been so good to me!"
Joe Enthusiast running 10.2: "Hey cool, 10.3 is out, I wonder if they
included that new version of .... the one I'm running now is so buggy."
How many sour moments, defections and poor reviews concerning 10.0 could
we have been avoided? I see those reviews going from utter condemnation
to "hey guys, the new interim from openSUSE has a few bugs, but, these
guys really fix this stuff quick. check back later."
Maybe, I've just been reading to much stuff like this;
http://en.wikipedia.org/wiki/IT_Service_Management
or I could just be nuts, let me know.
So you want all openSUSE users to upgrade every 8 months?
That is impossible. 2 years is acceptable and sometimes even that is too
short.
Another use of e.g. 10.1 is as a additional repo for SLES10, because you
don't get all the software you need on a Server from the SLES, SLED and
SLE SDK repos.
You said x.1 should be x.0+SP. But it is hopefully not.
A SP for a SLE product does not change the kernel and probably glibc.
A newer openSUSE version always had newer Kernel, glibc, gcc, X, KDE, ...
A possible way to go is enlarging the time between releases even more. We
already moved from 6 months to 8 months. Maybe even more.
--
Mit freundlichen Gruessen,
Andreas Vetter
Fakultaet fuer Physik und Astronomie
Universitaet Wuerzburg
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx
| < Previous | Next > |