Design Review 2019-12-04 21:00 UTC (LTS/nightly releases, self hosting runtime)

[mrjoro]

Time: 2019-12-04 21:00 UTC (add to Google Calendar)
Location: Video conference via Google Meet

The AMP community holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc or issue by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

We rotate our design review between times that work better for different parts of the world as described in our design review documentation, but you are welcome to attend any design review. If you cannot make any of the design reviews but have a design to discuss please let mrjoro@ know on Slack and we will find a time that works for you.

[mrjoro]

The AMP4Email Working Group will be presenting their periodic updates at this Design Review (10-15 minutes).

/cc @ampproject/wg-amp4email @choumx

[honeybadgerdontcare]

@sbenz and I would like to discuss self-hosted runtime #25026

[sebastianbenz]

//cc @mattwomple

[danielrozenberg]

@rcebulko and I would like to discuss #25578 and #25616 respectively, two tangentially related but different change proposals to release process, to introduce a stable ("monthly") release flavour and to introduce automated nightly builds (respectively again)

[wassgha]

Would like to discuss amp-next-page v2 (shouldn't take too long) #25826

[mrjoro]

FYI we're pushing the Analytics WG update to next week. /cc @ampproject/wg-analytics @zhouyx

[davidstrauss]

Would like to discuss amp-next-page v2 (shouldn't take too long) #25826

I commented on the issue as well, but can you please make the design and tracker documents accessible to the public?

[sebastianbenz]

Links for the AMP Runtime Self-hosting Proposal:

• I2I
• Design Doc
• Presentation

[rsimha]

LTS release (led by @rcebulko):

Overview: A slower release cycle, requested by external partners like Ali express. Not meant to supplant existing weekly v0.js release. Websites will request /lts/v0.js instead of v0.js, and will receive a slower updating RTV.

Caching considerations: Google rewrites canonical urls (just v0.js) to RTV prefixed urls (RTV/v0.js) for caching benefits. This will continue to happen with lts as well. External caches do not currently do this for v0.js, but we will make a metadata file available to enable them to do so if they want.

Internal mechanism within Google: A set of bzl files that contain an RTV number for each release flavor are periodically updated. This will go on to include the LTS release as well.

@rcebulko: Weekly stable release has a release candidate that indicates what the upcoming stable release will be to enable folks to test. Do we need to do something like this for LTS as well? Downside: It necessarily means that LTS version is a few weeks (4) old.

@dvoytenko: How will partners use the lts release candidate?
@rcebulko: We can do this with an opt-in cookie, similar to how we opt in to the weekly stable release candidate.

@nainar: If I am a publisher who notices a bug in stable, can I immediately switch my website from stable to lts?
@rcebulko: LTS isn't strictly meant to work as a roll-back mechanism. Our messaging should encourage websites to use one of stable or LTS.

From diagram: With lts-rc, the time offset between code hitting HEAD and getting released could increase from ~2 weeks to ~8 weeks in the worst case.

@cramforce: It could become confusing if we have a heavyweight process to choose an lts-rc build based on a few weeks' build quality. Instead, we should just stick with a well known schedule. Partners care more about when they can do QA for their websites, rather than which build was chosen as rc.

@honeybadgerdontcare: Can we delay it further by a week to give folks time?
@rcebulko: That's basically what the diagram shows. If we aren't adding too much value by the "best release" process, we should just pick a release on a schedule.

@sebastianbenz: How does this affect platform support? Do platforms (like search viewer) now have to potentially support two versions at the same time?
@cramforce: The answer is yes. There will be some version skew, but platforms will have to live with a wider spread of features. Don't expect this to be a problem in practice.

[rsimha]

Nightly release (led by @danielrozenberg):

Overview: AMP is now receiving way more PRs / commits per release than 2 years ago, making it hard to determine the cause of P0 issues when they pop up. Nightly releases are a way of diverting a small amount of traffic to a new release pushed each weekday, and measure things like errors and performance regressions before releasing to stable.

Note: This will need CSI data to be available faster than today (3 days, down to a couple of hours)

@newmuis: Would it make sense to separate channels based on day of week? (thinking of the opt-in case)
@danielrozenberg: For that, we have a separate way of opting in to a specific RTV (discussed a few weeks ago)

@choumx: There's a recency problem, because P0s take a while to detect.
@danielrozenberg: This will increase the number of days between when code is checked in and when it is released, so we will have more time to detect P0 issues.

Proposal: Divert 1/10 of the amount of traffic that goes to rc to nightly. RC -> 0.5%, nightly: 0.05%.

@dvoytenko: Once we have a nightly, will we still be able to cherry pick changes to it? @danielrozenberg: Unless it's a serious issue, we should prefer to just wait for the next day's release. And if an issue is discovered in canary, we just roll it back to the previous nightly. Finally, the opt-in RTV cookie can help bisect / debug where an issue originated.

@dvoytenko: For P0s, we'll have to CP changes to canary, nightly, and prod.
@danielrozenberg: Yes, for P0s with older causes, we will have to do a triple cherry-pick.

@dvoytenko: In the P0 scenario, we'd have to kill any old nightly releases that don't have the fix.
@danielrozenberg: Gotcha. Will do.

@twifkak: We should document this in a more permanent way than just I2Is.

@dvoytenko: Will nightlies be subject to release freezes?
@danielrozenberg: They're still going to be promoted manually. Other than that, they shouldn't be subject to restriction.

@dvoytenko: Wouldn't mind promoting nightlies automatically.
@rsimha: That'd be good if we don't promote on holidays, and restrict it to just working days.
@danielrozenberg: Can do.

[rsimha]

Self hosting the AMP runtime (led by @sebastianbenz):

@sebastianbenz: <see intro / motivation / design in attached preso>

@dvoytenko: Is there a reverse look up to ensure the integrity of self-hosted RTV versions?
@twifkak: Downside: Publishers will have to update all their pages if they have to update their version of self-hosted AMP.

@sebastianbenz:

@alanorozco: With partial RTVs, what are you locking the RTV to?
@sebastianbenz: To whatever RTV the publisher chooses. Missing versions are downloaded from cdn.ampproject.org, and mismatches will be flagged as console errors.

@sebastianbenz:

@Gregable: There's an alternative where the validator can require that amp-geo is not self hosted.
@sebastianbenz; That could work. It'd be nice to have a better solution. European publishers need this for GDPR compliance.

@sebastianbenz: <see section on tool support, open questions in preso>

@choumx: Do you want to allow this on valid AMP? If so, this will allow publisher origins to not be evergreen AMP, and introduce large skew.
@sebastianbenz: Yes, we want this to be valid AMP.
@dvoytenko: We could limit this to a set of versions, maybe.

[dreamofabear]

wg-amp4email update: ampproject/wg-amp4email#12

Sorry for the delay.