Design Review 2018-08-01 15:30 UTC (version numbers, form use outside AMP, handling flaky tests/build size)

[mrjoro]

Time: 2018-08-01 15:30 UTC (add to Google Calendar)
Location: Video conference via Google Hangouts

The AMP Project 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 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.

[alabiaga]

I would like to discuss #15583, primarily #16761. A proposal to allow the form element to be used outside of the context of AMP

https://docs.google.com/document/d/1qB16y1F_qh6ZgNIIH9hLkoFjlcYrhcGpJP6-JuWrPgw/edit#

[danielrozenberg]

I would like to discuss to issues:

• 🏗 Generate a consistent version number when building/disting #16631, a proposal to change release version numbers to be predictable and dependent on commit times, instead of the time that the release is being built (short, probably 5-10 minutes)
• I2I: AMP Build Artifacts Storage #17043 modifications to the Travis build process to make it easier to mark flaky tests as flaky, and to change the bundle-size max value, both without requiring changes to amphtml

[mrjoro]

Consistent version numbers

presenter: @danielrozenberg

• if developers have different local commits could they end up with the same id?
  • the last digits are 000 if there are uncommitted changes
• there are no major objections
• @cramforce: good change, but consider a minor variation--what if instead of seconds since epoch we just encode the time (20180801123456), still a number only format (not a string)
  • goal was to make sure that the version numbers we have is higher than any existing version number; that would be the case if we start with "2018"; could start with 18 instead of 2018 to limit the number of digits needed
  • our current format is hard for humans to compare
  • might be compatibility issues if we change from the 13 digit number e.g. for caches
• with random hash at the end there's no guarantee it will always be ascending
  • Daniel addresses this in a comment in the proposal issue

[mrjoro]

Allow form element use outside AMP

presenter: @alabiaga

• one use case is WordPress; content can appear in multiple views, so even if you have content that is on an AMP page it may appear in other non-AMP contexts (e.g. amp-mathml), but this doesn't work for forms today
• do we keep submit logic into the amp-form extension or v0.js?
• can we require users to use amp-form instead of form? it's very difficult to do in custom elements (including for reasons of accessibility)
  • this was something that was discussed originally (amp-form element around regular form element) and can be discussed
  • we'll have a design doc to talk about what we want to do here
• do we officially support AMP elements in non-AMP contexts?
  • no, it's mostly best effort today; long term we would like to support this

[mrjoro]

Better handle flaky tests and max build size

presenter: @danielrozenberg

• when we mark tests as flaky today do we have a process to get them fixed quickly
  • it depends on who cares about them unfortunately
• could just use one new repository for this rather than a new one for each
• @rsimha would like to see a proof of concept for bundle size first; it's easier to implement
• @choumx: seems like a good change
• @choumx: one of the most beautiful design issues he's seen! (@danielrozenberg: it's generated from a Google doc :))