Follow Up from "Let's Discuss Interim Releases"

[Thierry Carrez]

Robert Collins wrote:
> On 12 March 2013 23:07, Thierry Carrez <ttx at ubuntu.com> wrote:
>> I'm not sure I understand how this "configuration" would work,
>> especially with security updates. I'm probably missing something, so
>> let's have an example. Let's say I install "Ubuntu" on January 1st, 2014
>> and set it to "LTS mode". I get Gnucash 2.5. Alice does the same on
>> February 1st, 2014 and grabs Gnucash 2.6. Bob does the same on March
>> 1st, 2014, gets Gnucash 3.0, which introduces a very large behavior
>> change. In May, a vulnerability is discovered that affects all versions
>> up to 3.0.1. The security team has to backport the fix to 2.{5,6} and
>> 3.0 because all those LTS users expectation is that they will get "keep
>> me secure with my behavior unchanged" mode ?
> 
> So, if gnucash is supported - that is, if its part of the APIs and
> behaviour we have *committed* to preserving, that 3.0 upload wouldn't
> happen *until* we had figured out how to preserve behaviour for the
> users that had started on 2.x.
> 
> If gnucash isn't supported, if its just in universe, then the security
> team isn't on the hook, and we would just have uploaded 3.0.1 with the
> fix.
> 
> So lets assume it is supported: There are two broad avenues to
> preserving the behaviour it had with the 3.0 introduction.
> a) versioned installs. We do a little transition dance and end up with
> gnucash2 and gnucash as separate packages. In this approach nearly no,
> or even no code changes are needed to gnucash, but we pay a
> maintenance cost indefinitely.
> b) feature flags. We (or upstream) restore (or keep in the first place
> - much easier to do it that way) the 2.x behaviour when this 'large
> change' is coming in 3. The default is the latest upstream behaviour,
> but a user/system wide config can easily tell gnucash to revert to the
> 2.x behaviour. In this approach we only have one package, and we just
> update it with the security release.

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.

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).

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

-- 
Thierry Carrez (ttx)
Ubuntu core developer