Re: Dreamhost dumps Debian
Excerpts from Pau Garcia i Quiles's message of 2013-08-20 04:15:12 -0700:
> On Tue, Aug 20, 2013 at 12:46 PM, Steve Langasek <vorlon@debian.org> wrote:
>
> > On Mon, Aug 19, 2013 at 11:48:13PM -0400, Michael Gilbert wrote:
> > > > Russ already replied and I agree with its reply. Just to say that
> > Debian
> > > > usually has a 3 year support. This is the kind of misguiding that I
> > > > usually hear when people promotes Ubuntu over Debian.
> >
> > > I know already that this isn't a popular idea, but another option
> > > would be to release less often. If releases were every 3 years, then
> > > the support window would be 4 years, which almost gets to the apparent
> > > sweet spot of 5.
> >
> > I think the more useful option would be for Debian to figure out how to
> > lengthen its security support window instead.
> >
>
> Agreed.
>
> I know many companies that see Ubuntu's non-LTS releases as release
> candidates with real-world testing and LTS's as stable releases. That's why
> Ubuntu is successful: when a company picks an LTS, they perceive it as
> something that has been properly stabilized (although often times it's not
> true, e. g. Mir in the next LTS).
>
I think the term used there, "properly stabilized", implies there is a
definite process that one can use to stabilize an operating system and
all of its integrated software.
I think it is reasonable for a company to expect that Ubuntu would
be more conservative with the LTS release, as it is in Ubuntu's best
interest given the cost of supporting a radical release for 5 years.
Debian is expected to be conservative as well. For a long time,
with stable being alive for much longer than 2 years, I think users
didn't have to make the kind of choice Dreamhost did. The release was
an uncommon event that would kick off a year of decisions. However,
with squeeze and wheezy coming so close together, I'm certain that the
Dreamhost engineers were still weary from the squeeze transition when
they were asked to evaluate wheezy.
> Maybe we should adopt a similar model:
> - Stable release every 12-18 months to avoid shipping rotten software
> - Alternate releases are LTS
> - LTS releases get 4-5 years support (to determine)
> - Non-LTS releases get 6 months support after the release of the next LTS
> version
> - LTS overlap in support for at least 1 year to give users ample time to
> move to the next LTS
>
>
> E. g:
> - In January 2014 we release Debian 8.0. We make this an LTS release,
> meaning it would get updates for, say 3 years (until January 2017), and
> security updates for 5 years (until January 2019).
> - In February 2015 we release Debian 9.0. Non-LTS release. It will get at
> least 1 year of support (because we won't release the next version until at
> least 1 year later) + 6 months
> - In April 2016 we release Debian 10.0. LTS release. It will get again 3
> years of updates and 5 years of security updates. This means support for
> Debian 9.0 will end in October 2016 (LTS release date + 6 months)
> - ...
>
> </ideastorm>
>
All great ideas. I'm more inclined to just suggest that Debian keep
oldstable security patched for an extra year. That is easy for users and
developers to remember, and would give big server users a chance to slow
down the treadmill a little. Of course, it also would put more burden
on DD's.
Reply to: