[2066] in athena10
Re: LTS support policy
daemon@ATHENA.MIT.EDU (Evan Broder)
Sun Apr 5 09:34:37 2009
Message-ID: <49D8B358.8000803@mit.edu>
Date: Sun, 05 Apr 2009 09:34:16 -0400
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Mitchell E Berger <mitchb@mit.edu>
CC: Tim Abbott <tabbott@mit.edu>, Greg Price <price@mit.edu>,
Debathena <debathena@mit.edu>
In-Reply-To: <200904051317.n35DHvCc010718@yaz-pistachio.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Mitchell E Berger wrote:
>> On Sat, 4 Apr 2009, Greg Price wrote:
>>
>>
>>> We will support an LTS release until 6 months after the next LTS.
>>> At our discretion we may support it longer if we see people are
>>> still using it.
>>>
>> I'm happy with this policy. It doesn't promise anything that could be
>> really inconvenient in 2 years, while still providing users with what they
>> likely want (having a sizeable upgrade window).
>>
>
> Just to make sure we're clear on this, Greg's proposal isn't just a
> reformulation of Evan's; it's a significant change. What Greg proposes
> is basically reasonable, though what Evan proposes wasn't (perhaps
> he meant to be suggesting the same thing that Greg did, though, and got
> the number wrong).
>
> Greg suggests "at least until 6 months after the next LTS." Evan
> suggested "at least 2 years." LTS releases are two years apart,
> so that would mean desupporting immediately when the next LTS is
> available, which I don't think we could get away with.
>
> In any case, while I think "at least 6 months past the next LTS, and
> longer if people are using it" is fine, I think you're basically
> guaranteed that you're going to have to support Hardy longer than
> 6 months past Karmic+1's release. Nobody's using Dapper, sure, but
> plenty of people have installed Debathena Hardy, several of them on
> servers, and many of them on XVM because they can't get a ParaVM with
> Intrepid yet. So, I don't think this policy is actually going to solve
> the nuisance in maintaining software for Hardy that Evan's forecasting.
>
Yeah, I realized that. The logic for mine was roughly that once a new
LTS comes out, we shouldn't see any /new/ installs for the old LTS, just
old installs that haven't been upgraded, so the number should always be
decreasing. So if it hit 0 at any point after the next LTS was released,
we could be relatively justified in killing it.
But I'm fine with Greg's proposal, too.
- Evan
