Follow Up from "Let's Discuss Interim Releases"

[Robert Collins]

On 13 March 2013 03:57, Thierry Carrez <ttx at ubuntu.com> wrote:
> Robert Collins wrote:


> Understood. IMHO that "LTS mode" would significantly reduce the benefits
> compared to the current LTS. Current LTS promises to keep
> you secure with a behavior mostly unchanged. It gives you unchanged
> behavior for 99% of the packages in the archive, perfect security
> support for main, and best-effort-but-still-good security support for
> everything else.

I think that is overselling the current LTS. I would say it gives you
approximately no security support for 90% of the archive. Many smaller
projects don't issue CVEs when they have a defect, and the only way
you have security support is if you get a new release. The SRU process
is excruciatingly slow [by choice, it is an engineering tradeoff].

> It looks like to avoid turning it into a maintenance nightmare, your
> "LTS mode" would have to significantly reduce the scope of supported
> packages: only a very limited set of packages would both be preserving
> behavior *and* be security-supported. Everything else would have to drop
> one or the other (most likely deciding to abandon preserving behavior).

The thing about having a user base of millions of users is that those
incompatibilities become a massive force multiplier for packages used
by any significant % of the user base. Folk that proxy for large user
bases will naturally want to minimise the cost of accomodating such
changes - and the LTS cycle allows them to reduce repeated
incompatible changes to the same thing, by folding them all together.
However for distinct incompatible changes, the LTS cycle only serves
to bundle them together, making the time to adjust to a release larger
and slower (which provides backpressure on the frequency of releases,
but the further apart the releases are the greater the bundled
changes.... it is a vicious cycle).

And yet preserving behaviour over and above what upstream does is an
extraordinary thing to do. Backported security fixes are work upstream
didn't do, for instance.

Assertion: Generally speaking upstreams expect folk to upgrade every
time they release. And they are surprised and unhappy when folk don't
*and* they get bug reports from users running old releases. This isn't
just the web space - even old plumbing tools like gcc and automake
care about this (and you can tell, *because* they talk about backward
compat... if they didn't expect immediate upgrades and [transient]
skewed user populations, backwards compat becomes much less
important).

The /normal/ thing upstreams expect is that they do a release that is
compatible, with *perhaps* a small number of documented
incompatabilities, and users upgrade near immediately.

So I'm not suggesting more or less work, I'm suggesting that we *take
the work where it belongs* - in upstream, *when* the incompatible
change is being made.

Old: (N incompatible changes upstream, then M backported security
fixes for 5 years) per LTS
New: (N would-have-been-incompatible changes enhanced to be compatible
via a config option).

If N is larger than 3M(*) then it is a wash. If N is < 3M, then this
is clearly more efficient, and will also most folk that run trunk of
such projects have an easier time.

*) 3M because (LTS 2 years apart, 5 year life -> 2 LTS's, + 1 current
release under Mark's 7 month support proposal)

> Not saying that means this is unreasonable, just detailing how your LTS
> mode differs from what LTS currently provides :)

Yeah - it is good to spell it out.
-Rob

-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Cloud Services