Skip to content

Latest commit

 

History

History
173 lines (134 loc) · 8.01 KB

CG-09-19.md

File metadata and controls

173 lines (134 loc) · 8.01 KB

WebAssembly logo

Agenda for the September 19th video call of WebAssembly's Community Group

  • Host: Google Hangouts
  • Dates: Tuesday September 19th, 2017
  • Times: 9:00am–10:00am Pacific Time
  • Location: same Google Hangouts link as before
  • Contact:

Registration

None required if you've attended before. Email JF Bastien to sign up if it's your first time. The meeting is open to CG members only.

Logistics

The meeting will be a Google Hangouts call.

Agenda items

  1. Opening, welcome and roll call
    1. Opening of the meeting
    2. Introduction of attendees
  2. Find volunteers for note taking (acting chair to volunteer)
  3. Adoption of the agenda
  4. Proposals and discussions
    1. Summary of the September 15th Working Group call (Brad Nelson).
    2. Discussion of coordination with Working Group (Brad Nelson)
      1. Discussion of draft phases proposal.
      2. POLL: We should revise the phases proposal to include recomendations on when browsers ship features.
      3. POLL: We should adopt the phases proposal.
  5. Closure

Agenda items for future meetings

  1. Versioning of external standard dependencies.
  2. Web platform test repository, discussion, and poll (Ben Titzer).

Schedule constraints

None.

Dates and locations of future meetings

Dates Location Host
2017-11-01 to 2017-11-02 Santa Clara, CA Intel
2017-11-06 to 2017-11-07 Burlingame, CA TPAC

Meeting notes

Roll Call

  • Arun Purushan
  • Bradley Nelson
  • Dan Ehrenberg
  • Deepti Gandluri
  • Derek Schuff
  • Edgar Pek
  • Eric Holk
  • Gabriel Dos Reis
  • Heejin Ahn
  • JF Bastien
  • Keith Miller
  • Luke Wagner
  • Michael Holman
  • Peter Jensen
  • Richard Winterton
  • Roberto Malatesta
  • Sergey Rubanov
  • Shiv Kishwaha
  • William Maddox
  • Paolo Severini
  • Marcos Diaz
  • Michael Ferris
  • Pat Hickey
  • Ulrik Sorber
  • Unbug Lee

Agenda items

  1. Opening, welcome and roll call

    1. Opening of the meeting
    2. Introduction of attendees

  2. Find volunteers for note taking (acting chair to volunteer)

Derek volunteers to take notes

  1. Adoption of the agenda

Derek seconds.

  1. Proposals and discussions
    1. Summary of the September 15th Working Group call (Brad Nelson).

  • In order to have W3C standard, we need a WG. WG has extra IP protections, and membership is restricted to W3C member organizations. However one of the first actions of the WG was to open the meetings to observation by CG members.

  • We will reuse the same mailing list (i.e. one list for CG and WG)

  • Wanted core language spec separate from JS/Web embedding. Had a poll on the agenda w.r.t. going ahead with the core spec even though JS/Web isn’t done yet. didn’t have poll. Need more discussion about the interrelationship of the various documents.

  • Scheduled next WG call for Monday sept 25

  • Tabled a couple items (one of which is now on the agenda below).

  • Note to the meeting

    1. Discussion of coordination with Working Group (Brad Nelson)
      1. Discussion of draft phases proposal.

  • Missing from PR is expectations on browsers and what they ship (make more explicit? Leave more wiggle room?)

  • Tried to be very explicit about entry/exit requirements (based on experience with TC39)

  • (explanation of stages from PR)

  • Phase 4 starts the patent clocks.

  • Is it sufficiently explicit?

  • Is this the process we want?

  • JF: which part of these phases can browsers ship in? Where do they know that they can ship and know that it won’t be changed/break? This doc leaves it a bit open, we should discuss/clarify.

  • Browsers should be OK to ship at state 4, but can WG introduce breaking changes?

  • BN: can imagine cases where someone finds something, but more likely there could be a patent issue.

  • But in that case we need lots of lawyers anyway.

  • JF: concrete comparison: C++ library-evolution/language-evolution vs library WG. New features come from evolution groups, then trickle to core groups, who make it fit with the rest of the language. They do sometimes throw stuff back to the evolution group, but they don’t do substantial changes. This separation of concerns is good. WG can hold the philosophy of what the standard is, and CG chooses where it goes.

  • BN: if you ship in stage 4, you expect things not to change.

  • JF: in C++, compilers ship, but with an opt-in command-line flag. Not really an equivalent with the web.

  • AR: we ship behind a flag, is this equivalent?

  • anyone can ship behind a flag, this is for without a flag. Do we need to really wait for WG? 150 days is a long time. We should make a very explicit choice.

  • threshold of how bad something can be broken to rewind?

  • need an expectation that browsers can count on

  • EH: how do other W3C standards handle this?

  • BN: sometimes there’s only 1 impl, very far through the process. We are more aggressive about getting prototypes/multiple impls.

  • JF: we also have non-browser embedders and tooling, which are more important for us. Tooling is not as tied to standards as the rest of the web.

  • LW: entry to 4 is too early, exit of 4 to 5 is too late. Should we split out a 4.5? In past we vetted among impls, tools, stakeholders, etc informally.

  • people shipping raises the bar to changes drastically.

  • JF: suggestion: add floating item in 4: WG holds a vote on shipping? Has a high bar, we can hold the vote more than once. Can happen anytime during 4

  • LW: SGTM

  • BN: WG hold periodic polls on ship-worthiness of feature? Q: why is this not implicit in entering 4?

  • LW: part of entry to 4 is CG consensus. Do we say WG really can’t do much at all?

  • BN we do want to keep as much as possible in CG

  • DE: analogy: no separation in TC39, but when something gets to stage 4, it waits for annual release, 90 day opt out, etc but nobody waits for that to ship. (just multiple impls, tests, spec, etc). There can still be editorial changes, tweaks, but browsers still expect stability. We can say that concerns should be brought up in CG.

  • BN: concern in past was that WG gets handed a thing, they haven’t voted at all

  • JF: balancing act between CG and WG: it could go back and forth as WG concerns about how things fit into web

  • BN: add a step in 3-4 transition, that WG votes

  • JF: you lose the clocks ticking in that buffer time. Now it’s baked into stage 4, and that doesn’t optimize the expected case of no issues (extra delay)

  • BN: current core format is in WG and is really pretty done, high shipworthiness. [add votes in stage 4?]

  • DE: DS got a phone call :(

  • JF: we want to bake our process assuming good intent

  • Proposal on table is, add to stage 4, periodic WG votes on shipworthiness of the feature, to inform shipping process of the browsers.

POLL: We should revise Phase 4 to add the requirement that the WG periodically hold polls to measure the sense of how "ship worthy" the feature is to allow browsers to make decisions about when to ship.

Unanimous consent

Action Item: Brad to do the pull request.

JF: we can always revisit the process, and should be willing to as we gain experience. Want to get a sense of how people feel about this, so that if we revisit we can see whether we have gotten better consensus.

JF: reminder: this process is documented in meetings GH repo.

POLL: We should adopt the phases proposal (with the modification above).

SF F N A SA
9 10 2 0 0

2 Neutrals: any comments?

MD: Don’t think it really matters, we aren’t going to need new stuff very soon? BN: threads is coming up. No other comments from neutrals.

  1. Closure

Adjourn