Hotspot Express (HSX)

[Mikael Vidstedt]

> On Feb 28, 2020, at 7:28 AM, Hohensee, Paul <hohensee at amazon.com> wrote:
> 
> Re flags/features and compiler upgrades, my current HSX investigation covers delivering it only wrt to the latest LTS release, so I'm only thinking about 3 years, not forever, though process would the similar in the forever case.
> 
> When HSX was policy, flag and feature changes were handled much the same way they are now in JSX. I.e., deprecated and eventually removed, though physical removal was usually deferred to an LTS release. New features started out experimental, were default disabled until production ready, and when enabled, old flags became either nops or were translated to the nearest new equivalent. Once the new feature was in production and had possibly been made the default, we kept the now-deprecated old feature around for a transition period whose length varied with the feature. For CMS, I'd have proposed removing it in an LTS release: if people wanted it, they could use the previous LTS release, which would now be off HSX.
> 
> Timing of C++ compiler upgrades depends on whether it's just a toolchain upgrade or involves using new language features. Tool chain upgrades for tip aren't that big a deal (we're doing this already) and can be checked for in the most recent LTS release's makefiles: mostly they involve more-pedantic error checking, for which source changes are accepted by earlier versions. If the intent is to use more recent C++ language features, I'd propose allowing those only starting with an LTS release and provide lots of notice. Three year intervals seem to me short enough for this kind of change, though I realize some may disagree. If HSX were extended to earlier LTS releases, a potential solution would be to upgrade their tool chains, backport non-HSX source code changes as needed (i.e., to satisfy more-pedantic compilers), and restrict builds using old toolchains to security patches only (i.e., take them out of HSX).

If I understand you correctly, you’re suggesting holding up many of the significant changes until the next LTS. That sounds like to opposite of what we want. Doing so would introduce significantly more risk in the LTS releases, which are the exact ones we'd ideally *minimize* risk in since we’ll be maintaining them much longer. Theoretically we should really make the significant changes in the very first release after an LTS to get the maximum amount of feedback in time for the next LTS.

Also, one of the beauties of the new model is that we don’t really have to care about when releases happen or what kind of release they are, and in particular we don’t have to hold things up. When things are ready they get integrated. No need to sit on changes, keep side branches up to date, or do any flag dancing. Not having to care about which release a feature “must” go into is a true win - developer/planning/stress. Getting those features integrated early means we can move on and work on the next thing, building on top of it.

Unless I’m missing something I think your proposal would add risk to all releases, and slow down innovation in mainline, and I think that’s the wrong tradeoff.

Cheers,
Mikael