[2050] in athena10
Re: LTS support policy
daemon@ATHENA.MIT.EDU (Greg Price)
Sat Apr 4 20:35:48 2009
Date: Sat, 4 Apr 2009 20:35:19 -0400
From: Greg Price <price@MIT.EDU>
To: Evan Broder <broder@mit.edu>
Cc: Debathena <debathena@mit.edu>
Message-ID: <20090405003518.GY21912@vinegar-pot.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49D7FA1D.5010501@mit.edu>
On Sat, Apr 04, 2009 at 08:23:57PM -0400, Evan Broder wrote:
> Normally I would say that it seems poor to desupport Dapper on <2 weeks
> notice, but since nobody's using it, I don't think I actually care. I
> propose desupporting Dapper on April 18, at the same time as Gutsy.
From these data, sounds good.
> Generalizing that to a general LTS policy, I'd suggest that we declare
> that we will support LTS releases for no less than 2 years, and so long
> as there is continued use, we will support them for up to 3 years.
> However, after the next LTS release comes out, we reserve the right to
> terminate support on limited notice if we determine that an LTS release
> is literally unused.
Sounds basically good. I think this can be reformulated a little.
Say,
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.
The differences are
- promising concretely the 6-month margin may make people more
comfortable in advance, and costs us little if we would have
supported it 5 months anyway while they kept using it;
- I'd rather not promise we'll definitely go farther for one or a
handful of users;
- the part about limited notice sounds scary, and won't be necessary
if we set a policy we like to begin with.
I think the 6-month margin is what Canonical uses for ordinary
releases? If not we could adjust it to match the same terms.
Greg
