- Where: zoom.us
- When: May 10, 4pm-5pm UTC (April 12, 9am-10am Pacific Time)
- Location: link on calendar invite
None required if you've attended before. Send an email to the acting WebAssembly CG chair to sign up if it's your first time. The meeting is open to CG members only.
The meeting will be on a zoom.us video conference. Installation is required, see the calendar invite.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (acting chair to volunteer)
- Adoption of the agenda
- Proposals and discussions
- Update on Memory64 (Sam Clegg) [10 min]
- Wasm WG followup on Spec versions, see relevant WG meeting notes [15 mins]
- Poll: Adopt new versioning scheme to bump minor version after each stage 5 feature
- Discuss a WebAssembly Research organization
- Closure
None
None
To be added after the meeting.
- Yurii Rashkovskii
- Francis McCabe
- Yury Delendik
- Zalim Bashrov
- Ezzat Chamudi
- Eric Prud’Hommeaux
- Ashley Nelson
- Jeff Charles
- Dan Gohman
- Francis McCabe
- Sam Clegg
- Yuri Iozzelli
- Chris Fallin
- Paolo Severini
- Slava Kuzmich
- Rick Battagline
- Ilya Rezvov
- Jacob Abraham
- Michal Kawalec
- Charles Vaughn
- Keith Miller
- Ryan Hunt
- Asumu Takikawa
- Ben Titzer
- Luke Wagner
- Mingqui Sun
- Igor Iakovlev
- Johnnie Birch
- Heejin Ahn
- Andreas Rossberg
- Sebastien Deleuze
- Peter Heune
- rrw
- Sean Jensen-Grey
- Deepti Gandluri
- Kevin Moore
- Andrew Brown
- Paul Schoenfelder
- Charles Vaughn
- Sergey Rubanov
- Alex Chricton
- Jakob Kummerow
- George Kulakowski
Update on Memory64 (Sam Clegg) [10 min]
SC Presenting Slides
RH: SpiderMonkey has implemented the proposal as-is, and should be up to date, can check to make sure, but will probably be minor tweaks.
SC: the major tools have support. There’s a fair bit of work on the JS boundary in emscripten. We can also lower away all the 64 bit memory operations into wasm32
SC + DS: Let’s do a unanimous consent poll for Sam Clegg to take over as champion for the Memory64 proposal.
No objections
SC: Are there any issues the current champion should be aware of?
None
Wasm WG followup on Spec versions, see relevant WG meeting notes [15 mins]
LW: background: a year or so ago, when wasm 1.0 reached REC status. What do we do? Start a new REC with a new version? Another option is “evergreen”, a new thing in the W3C used by HTML now. Once vetting is done, we just have the WG publish a Candidate Recommendation that reflects the live status in the CG. It reduces the delay between CG and WG publication. Fits with the goal of making the CG be where the interesting stuff happens. It means that the choice of version number is done by the CG, not that there are not versions at all. We do have a changelog with a monotonic version number (that happens as a result of how we merge things into the spec in the CG).
About half a year ago, we chose to adopt the EverGreen model, but didn’t actually release versions. In the mean time the WG charter expired and we needed to put up a new one quickly. So since we agreed to evergreen before, we wanted to decide what version to call it. It couldn’t be 1.0, that was the REC number. Could we take the current CG number (1.4 currently) and bump it when we bump the evergreen version. But that doesn’tw ork because of the WG process and tooling, the WG version has to stay the same.
The version used by the WG would be a major version, and we update the minor version when a feature is bumped, 1.0 is already taken, so we decided to go ahead with a 2.0 major version. The version is 2.x, and everytime we merge a feature, a minor version would be updated. So it’s a version 2 that’s live, but not an explicit 2.0
If we want to, the evergreen model allows us to stamp an REC spec. That would cause us to bump the major version to 3. If there’s some process reason we wanted to do that. The WG discussion happened quickly because of the charter expiration, but we do want to discuss here.
BT: I support having linear versions, what does that mean for engines that have to ship features one by one?
LW: That story is unchanged. You can always enable a feature independently. The discussion of what the version numbers mean? For ane engine to support a version, it includes all the features in the version but there can be other things too.
EP: I would expect that there’s not a huge gap between all the versions having the same feature, when we’re ready to release a REC, as a nominal endpoint for the process, the time required is usually short
SC: is there a 2.0 REC then?
EP: Just a first public working draft, and then it has to start the process from the beginning, we would have to do that even without transition to Evergreen
SC: so 2.0 is just a draft then?
EP: It’s just how the W3C communicates with the rest of the world
SC: and when it’s released it will be called 2.0 or 2.1 or whatever we call it?
LW: the idea is that there will be a CR that always stays. It will always have a major version of 2, it will be baked into the URL and such and won’t change. And when we add to it in the CG we can bump the numbers in the doc, but the version of 2 in the WG won’t change.
EP : An interplay between, anytime you publish a working draft, you get a dated draft, if we coordinate the minor versions between those, we could have a dated version for small constellation of minor versions.
LW: Any other questions?
POLL: Adopt new versioning scheme to bump minor version after each stage 5 feature
DS: Any concerns or objections about this?
EP: There’s some text that we changed as we had said version in the first public working draft, someone submitted an issue to say it’s version
AR: yeah, release. So “version” is teh W3C term, so we can keep that reserved and update the doc itself to say “release”
FM: Are there any significant changes to the charter?
EP: there was a small interim charter to let us publish the working draft. We’ve got a charter (https://github.com/w3c/charter-drafts/blob/0bfabf552a6418b1e29628d47e887dc8d00c5dd1/wasm-2019.html is the old draft charter, new one is TODO) that’s benign circulated with the advisory committee. It’s pretty much teh same. The template is changed a bit,b ut the section that matters (the deliverables) are similar. I took the previous deliverables, removed the ones we’ve already done, and added some proposals that were in flight in the CG.
AR: In terms of the process, do we intend to automate when we push something to merge into the spec? Can we automatically merge or is this a separate decision for the WG?
EP: We’re probably going to not want to make it a git hook to avoid minor fixes bumping the versions. We could automate it as a button that releases when we want it. I ‘Ve tried to automate it before, pretty close to being automated right now
AR: I guess we just have to decide whether we want to view it as being automatic, or say that we push one out whenever we add a new feature
EP: Right.
DS: We’ve been thinking about this certainly as whenever a new proposal makes it all the way to Phase 5, the idea is someone would push it out, we can decide on a case by case for smaller changes.
AR: Decision connected to bumping minor versions, i.e. is this worth bumping the version?
LW: Like this being the CG choice, whether this change is worth bumping this etc?
AR: YEah, there’s just not a way to change it in all the places that it needs to be
DS: There’s a way to publish minor changes without increasing the minor versions, and then only decide when we want to bump for significant changes
AR: is there any reason not to push minor corrections as they come?
EP: probably not. That’s what they do in the HTML WG, they are sort of the model for this.
AR: We might as well automate it. IS there any point where we have something that’s not a draft anymore? To say this is a recommendation now?
DS: Other way around, only evergreen but not draft
LW: When we publish a new rec.
EP: We have to do it at least once a new charter cycle. IT’s sort of our contract with the W3C
AR: how long is the charter cycle?
EP: Typically 2 years, link dropped is the draft charter for review, anyone here can propose that the charter be longer, intended to do that but didn’t.
AR: so you’re saing we’ll have to bump to version 3 in 2 years?
EP: Gave wrong link, we’ll have to publish the REC at some point, we’ll want it to correspond to some set of features, also to present some subset of features as an atomic versions. Release is entirely our own thing, and we can change it when we want, i.e. bump the major version at the point
AR: so you’re saing we don’t have to bump version even if we push a REC
FM: scanning the charter, another question?
EP: before you go into that, let me fix the link
FM: Small warning that this may be a longer discussion, on the JS side there are two deliverables, the JS API & the Web API, I’m in the middle of drafting something for JS Promise integration API, and it seemed like neither of the two was the right place for it, the JS API doc has grown, this may need reorganization, can we change this without needing a new charter?
EP: yes we can say “here are new doc” we can just publish a new working draft with the new organization. We’ll have to come up with naes to go in the URLs, but it should be OK.
SC: curious about the level of detail we’ll have in the changelog. Do we have that now, how much detail is there?
EP: Very coarse details are required, beyond that it’s upto Andreas and us AR: You are talking about the changes in the spec itself.
SC: As a reader of the spec, what has changed?
AR: yeah what I added in the appendix, lists all the instructions and types added but doesn’t go into details. Usually it’s linked. It doesnt give you a detailed diff of the spec. If you really need that as an implementer, we’d have to produce that separately. There’s HTML diff, not sure how useful that would be for this. The appendix just gives an overview, e.g. the constructs but no extra info other than links.
EP: HTML diff tools are more useful on single page docs, this might take more.
AR: I’m not sure what a better answer to this would be, we don’t want the spec itself to have the diff info, that would be cumbersome,
SC: You can actually do a git diff in the spec repo
AR: That’s going to be a lot, and harder to read the spec as well
FM: ergonomically, having something that says “features since v1.1” on hover would ben ice. But not not trivial to implement.
AR: We could annotate some of these.. Yeah not easy.
EP: It’s not always that the versions correspond to a new versions of the document.
DS: Do we have any implications on the W3C side? That’s the only thing we have to do decide now
POLL again:
No objections.
BT: I’m interesting in doing research on wasm in a lot of context. There are over 100 publications in ACM DL tha mention wasm or use it. I think this is healthy. Academics have a relationship with the CG, comment on varous language features, potential uses, in particular stack switching.
There’s a value add of people having academics also look at this and use. The particular thing I want to discuss isl what is their mode of interaction with the CG, and is there space for another type of organization that might be under the CG umbrella. We could have something called “webassemly research”. There are several sub organizations or teamson github. What would people think about having another organization or team that is focused on research
IT would host the things people that on the research suite would find useful, like benchmarks for example, or research tools to do dynamic tools. IF we want academics to share tools, data and information for research, this would be a place for it. What does the CG think about that?
AR: is there actually a clear distinction between production and research things? Ideally things would cross over. It seems maybe suboptimal to separate them into different organizations? Also, I’d love to see under the wasm organization is the mechanization efforts, e.g. Coq and isabel? Also researchers don’t always want to give over their hard work.
BT: That’s something I’m wrestling with, my particular area of research is engine research, I’d like to be able to bring that under the Wasm org, definitely the mechanization stuff would be a good candidate
AR: Conrad’s stuff is in the open, it’s a fairly large project with its own repo
BT: I’ll mention Jikes, open source, 100s of students worked on it, the VM itself was open source, so people would make their own changes, it’s not clear what it looks like these days?
DS: Maybe the concern I have with that is, everything starts out as a repo/research group etc. at some point they say I’m willing to share this with the broader public, there has to be some criteria to say what belongs in the organization. The two extreme options are that we take everything Wasm related, or only take them if there’s an official Wasm publications, we don’t have a good criteria for what we have under the organization
BT: that's true. Also there's no clearinghouse for wasm research, where everyone knows what people are working on. Groups do their own thing. So it’s not clear how we go from them having their own internal things to having shared things.
EP: We could do something like github ?? that people could link their own work too
BT: yeah there is also a list of e.g. interesting languages. We could start with something like that and when things are interesting enough that people can use them, they could even be moved.
EP: Two criteria there - we have a sample URL to give for citation, if they are playing around with some implementation of it, if there’s a diff with a spec then that sounds like we want to adopt it
DG: there’s also a 3rd category, tools that don’nt have impact on the spec but are useful for research purposes, useful to share work instead of reinvent the wheel. There’s a place for that too even without an official spec diff
EP: Would a Wiki solution work for them?
BT: It’s a good start, there’s definitely things that need to be up leveled, there’s lots of engines we can modify, we have to reason by analogy, something like SPIM, there’s a lot of papers that came from that, maybe Wasabi is a thing like that, here’s this thing that we want to analyze something like that
DS: What is it that an organization like the CG provide? Researchers can always find/form repos. In the initial phases, bringing information to the CG actually just slows them down, but maybe at the point where you want a framework in which you want to work across organizations, that’s what the CG helps with. Do we want the CG for that? Or do we want another organization that has a separate charter that can produce useful things.
BT: i see it as a potential for giving a singal boost, not necessarily a blessing like the CG blesses the spec. But if we want to attract researchers, any kind of boost is great for them. If there’s something official even if it just a research org, that makes research of wasm more attractive for research, which can lead to more work on production or proposals.
KW : “One service it would be nice to have is a place for researchers to discuss work-in-progress and get early feedback from (a) other researchers, and (b) the Wasm experts on the CG. The CG meetings don't seem to be quite the place for that.”
BT: I agree, it would be great to have a place to discuss this early stuff.
FM: There’s a related thing, general outreach, if this is the place that people come to for information, we could have some curated source for information
BT: yeah
FM but we are a natural place for someone who want to find out more to go, the reason may vary, how to do research, or just general info.
BT: I see it also as a researchers are interested in getting a transfer of ideas, so this is a good place for that. For example, what are concurrency primitives for the GC proposal? There has tpo be a big enough payoff for senior folks to devote resources for that, so I’m trying to find the carrots that we can offer to those people?
EP : is that the discord channel?
KW: Not in my experience -- I think it's probably too much to expect that from a 24/7 chat group (few researchers I think have the time to hang out there in case somebody else pops up and wants to talk about work in progress, and honestly not that many Wasm experts do that either) BT: yeah it’s hard to know who will show up in something like discord.
FM: Would like to endorse what you are suggesting, and lift the game a bet, the CG is the locus, we’ve been focusing on building the thing, there’s going to be more in the future, there will be other kinds of connectivity we want to establish. Agnostic about where it should be, but it would be useful.
BT: I do like the question, What are the criterea by which we take in projects? We should think more about that
DS: and what is it that we can offer that nobody else can?
BT: They have no expectation that the actual Wam people notice, being approachable, and potentially getting the big signal boosts. I think it’s a pretty big value add
SJG: Access to collaborators, major engine authors, open questions in wasm? Researchers could show up here and do a 5 minute poster?
KW: one service it would be nice to have if you maybe designated a CG meeting every couple of months or something as a research day, where you invite people, can give talks and get feedback etc
DG: TC39 does something similar called “incubation calls” where they discuss new ideas and that sor tof t thing, that aren’t proposals yet, things people are thinkigna bout. One thing i’ve heard feedback on is kind of in this visibility into what kinds of problems people are working on even if there aren’t proposals yet.
BT: yeah its definitely related. When I think of incubation i think about things that could use some help getting a long. Something like e.g. a new language port, that could have a big impact if it brings all those languages’ users to wasm.
YR: Definitely value to have a research day, basically open to everyone that’s trying to push the boundaries, and explore ideas. IT m ight help directing people to information that isn’t charted yet, because there’s not a single map of things, often times I have to socialize the work, and that’s a day to find what people are working on. A research day might have tremendous value.
SJG, YR: +1 research day
DS: Thanks for bringing this up, sounds like we want to kick off a discussion on github or think of bringing this back at a future meeting