Follow Up from "Let's Discuss Interim Releases"

[Robert Collins]

On 12 March 2013 23:07, Thierry Carrez <ttx at ubuntu.com> wrote:
> I'm not saying you can't use dailies to care for "getting an install
> media". You were listing what, technically, a release means today. I'm
> just saying that as of today, "releases" also mean a reference install
> media.

Ack.


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

> Or are you saying that Gnucash 3.0, like all other packages in the
> archive, should have a config option that says compatibility=2.x that
> would preserve any past behavior, letting the security team happily only
> patch Gnucash 3.0 ?

Not *all other packages*. *all packages that are supported*. There is
a hugely long tail of packages. It doesn't make sense to me that we
pay an overhead premium to provide no-regression behaviour on packages
used by 0.01% of the userbase. Such users can band together and
request that we provide no-regression behaviour in a few ways: they
can contribute the fixes themselves to upstream; they can contribute
them to us, or they can hire a proxy to do that.

Providing totally seamless behaviour across versions isn't /hard/ - it
is straight forward engineering most of the time, the real issue is
deciding that:
 - it is worth doing
 - who is going to do it.

>> I don't understand what you mean by 'point in time' here. Could you
>> expand on that?
>
> I mean keeping the association between a name and a period in time.
> "Raring is the development cycle that started in November 2013 and ends
> in April 2014".
>
> Then you can anchor a number of things to that artificial "rhythm" you
> created: sets of API versions for your API deprecation policy, reference
> install media if you still want them, common community development
> cycle, etc.

Sure, thanks for clarifying. I was thinking database PITR, which is a
very different thing :).

> My point is that there is value in having a cadence, and the cost of
> special-casing a few dates is not that high to pay.

It depends a *great* deal on the implications of that special casing.
LEAN teaches that your cycle time - the time it takes do your
plan-execute-learn-plan loop is the big definer for your agility -
your ability to respond to changing needs from your users. 6 months is
a very long interval for responding in a software project delivering
products for the cloud. 4-6 weeks would be a much better interval, I
think. But thats a different discussion :).

-Rob

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