[2071] in athena10
Re: LTS support policy
daemon@ATHENA.MIT.EDU (Evan Broder)
Sun Apr 5 10:55:36 2009
Message-ID: <49D8C631.8090506@mit.edu>
Date: Sun, 05 Apr 2009 10:54:41 -0400
From: Evan Broder <broder@MIT.EDU>
MIME-Version: 1.0
To: Tom Fitzgerald <tfitz@mit.edu>
CC: Greg Price <price@mit.edu>, Debathena <debathena@mit.edu>
In-Reply-To: <49D8BE11.6010407@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Tom Fitzgerald 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.
>
> This is great, but where will the start of Athena support on the
> new LTS fall in this schedule? What I'd care about more is the
> interval from when Athena packages are pretty well tested and
> supported on it and changes documented, to when the previous
> version is desupported.
>
> If the clock starts running on the day the LTS appears and y'all
> start updating Athena packages, then 6 months might be tight. We'd
> like to see installations with Athena changes stable for a month
> or so before we start upgrading in bulk.
>
> One concern is that we can really only do some upgrades during the
> summer or January. If an LTS appears in June (like Dapper) and
> Athena changes don't stabilize until late July, we won't want to
> do a rush of upgrades during August or see support for the
> previous version end in December.
>
> If an LTS appears in April (like Hardy) and Athena is stable on it
> by June, that's ideal. (I'm hoping that'll be the trend for future
> LTS releases.)
I'm having a hard time coming up with a concrete answer for you, largely
because I've only been through 2 new releases so far, so it's hard for
me to generalize.
First of all, Dapper's June release seems to be an anomaly. Every other
release of Ubuntu has happened in April/October. Also, the April/October
releases are usually around the 18-25th of the month, while Dapper was
released June 1, so it was only about 5 weeks late, not two months.
I still don't really have a good feel for what our
new-release-engineering looks like going forward. We totally dropped the
ball on getting Intrepid ready, but they also made some substantial
changes to PAM configuration, which of course we interact with heavily.
Debathena Intrepid was fine for debathena-standard, but debathena-login
and debathena-formerly-known-as-workstation didn't work for about a
month after the Intrepid release.
We start trying to build packages for a new release at least a month or
two before it's released. We've had packages for Jaunty in the apt repo
since the beginning of March, and the only reason we didn't have it
sooner is because we needed to do some cleanup of that infrastructure,
which has now been done. I think that everything but debathena-cluster
already works on Jaunty.
In general, it's definitely our goal to have Debathena working for
everything (except maybe full-fledged cluster) by the time a new Ubuntu
version releases. But it's always a function of what the new release has
changed, how hosed we are in the month beforehand, etc, etc. I expect to
find that debathena-standard consistently works, since that's largely
just rebuilding our own software (although I guess I already know that
won't be the case for Karmic...). As you move up the metapackage chain,
things become less likely to Just Work.
- Evan
