- Where: zoom.us
- When: July 14, 2021 at 3pm-4pm UTC ( July 14th, 8am-9am PDT )
- Location: on calendar invite to registered attendees
- Contact:
- Name: Derek Schuff, Luke Wagner
If you are a Working Group member no registration is required.
If you are a Community Group member who would like to observe, please register here: https://goo.gl/forms/HD2kLCM0iSKk7AVl1
The meeting will be on a zoom.us video conference. See the calendar invite for link.
If no agenda items are added (after "Review of action items from prior meeting"), the meeting will be automatically canceled.
- Opening, welcome and roll call
- Opening of the meeting
- Introduction of attendees
- Find volunteers for note taking (chair to volunteer).
- Adoption of the agenda
- Proposals and discussions
- Review of action items from prior meeting.
- Fixed-width SIMD
- POLL: Advance proposal to Phase 5
- POLL: Publish First Public Working Draft for next version (possibly also auto-publish on merge to main)
- Closure
None.
None.
Luke Wagner
Derek Schuff
Deepti Gandluri
Eric Prud’Hommeaux
Conrad Watt
Ryan Hunt
Sergey Rubanov
DG: we’ve been testing implementations and tools, no issues have come up with implementations or users, so we thought it would be a good time to poll for phase 5. Should we do a consensus, or more detailed poll?
LW: I expect we can get consensus. Ryan, do yo have any comments from the Firefox side?
RH: I’m not actually a WG member but i’m here to answer questions about FF if anyone has them. We don’t have issues with our implementation, and we’re supportive of moving to phase 5.
DG: any objections then?
Consensus. Feature moves to phase 5
EP: For our purposes here, “TR” means https://www.w3.org/TR/; it means a doc that conforms to publication rules. The previous doc (the rec) is big and unwieldy. I decided to try to write a sphinx to TR tool to convert it automatically.
It takes a “fake” spec and runs it through ReSpec, which creates a valid TR doc. ReSpec has some material that shows editors, etc. It has a config that has to be edited from time to time. It generates the front matter and table of contents (richer that what sphinx generates)
LW: this looks very nice. The TOC looks actually useful.
EP: the TOC is more detailed, let you refer to numbered sections, etc. It’s scriptable, we can run it as a GH action, and can be integrated into W3C’s auto-publish. So if we get our action set up to output the sphinx, we can hook it up. To get this running we have to decide to move to first public working draft (starting over after our REC, basically), and then to decide to do automatic publication.
LW: how does that relate to using an evergreen standard?
EP: technically they are orthogonal. Auto-publication just lets you keep it up to date when you iterate on a working draft. Evergreen is that you can stay in CR, and only have to go to REC every couple years, etc.
LW: we don’t merge stuff too much, it’s mostly like we just did, with a “really done” chunk of work.
EP: yeah when you go to CR you stabilize for 3 months, to to give accessibility, internationalization etc. a chance to review, keep a summary of what’s changed, etc. With evergreen, the patent commitment and review process you did to get to CR, you want to make sure you don’t invalidate the previous patent/accessibility/i18n reviews etc by starting everything over or whatever. Once you have auto-publish you can just update the doc with git pushes.
LW: now that we have the tool, that seems quite easy.
EP: yeah if it needed a lot of manual manipulation, it would be slowed down, so this is more realistic. The value of evergreen is less if you need lots of doc work. Mathjax has a way to pickle its output, but there are some issues, that might need patching. Are there currently any scripts that change the content when you load the sphinx HTML output? If so, I haven’t caught them. (i did just include all the scripts that were in the old doc). If there are things we want to freeze that were from scripts that run from sphinx, they'd have to be made to work in JSDOM. In Firefox you can switch it to MathML and mathjax just does its thing. Do you know what it does when you do that? Is that output something you’d want to pickle to HTML, e.g. for other browsers? Do you know anything about mathML in the other browsers?
DS: the state of mathML in webkit browsers is... complicated.
EP: the mathml WG seems to be reanimated. It seems like maybe the browsers are back on board. It would be nice to be able to just do that once the support is there.
LW: is it possible to just dynamically generate HTML from the mathML if the browser doesn’t support it?
EP: sort of. It’s what the current version does with mathjax. In the future it might be possible to do it AOT. or we could have both mathML and mathjax markup.
LW: yeah dynamic fallback would be great. But what we have now seems like it works pretty well?
EP: we’ll see if there is anything cooler we can do for the first version. Otherwise we can start with what we have.
So the options are: Should we publish now with what we have? And do we want to auto-publish? And if we have auto-publish, do we switch to evergreen once we hit CR? (there’s no observable difference in evergreen until you get to CR).
LW: I think the answer to the first 2 is yes, right?
DS: yeah I agree.
EP: Is there a section in the doc that tracks changes since the last version?
LW: depends on the granularity. Mostly we have them in terms of features, which you can point to big sections. There is also sphinx diff, which might be more useful than an HTML diff.
EP: that might be useful actually e.g. for i18n. Then a reviewer would have to look for bits that would need review. If they can see the sphinx diff that would be the info they need. We could maybe even add an appendix with that.
LW: that would be convenient to do. It could align with a human-readable description.
EP: another question: the main spec that people use, with the sphinx HTML output. Does that get autogenerated?
LW: i think whenever people merge to the spec repo.
EP: that’s probably what we’d want for auto-publishing drafts. So the community expectation is for that doc to be the latest, there’s no other step for extra vetting?
LW: not really. The WG itself isn’t really supposed to do anything interesting.
EP: so that seems ready for auto-publishing again.
Are we ready to start that with SIMD?
LW: Yes, once someone gets the PR to merge.
EP: OK. So I formally propose that we publish FPWD with core, JS and web after merging SIMD.
DS: sounds good. Do we have consensus?
<no objections, proposal is accepted>
EP: Second proposal: set up autopublish of core spec, JS API, Web API, to be activated at chair's discretion.
DS: Do we have consensus on this, any objections?
<no objections, proposal is accepted>
DG: After merging SIMD, what do I need to do exactly?
EP: The decision means you just let me know when it’s merged and I’ll try to fix up the rest of the script, and get the webmaster to accept the publication request. There will be a 2 week wait for the director to approve the transition Oh, we also need to put down a name for it; i.e. a version number. Philippe had a proposal to just call the next version 1.1, we left room for that.
LW: do they show up in the doc or just in the URL?
EP: they’d show in a listing as “this version” and “latest public version”. We decide when to change it.
DS: implementations work in terms of features, not versions. But we do merge things in order, we could just bump the minor version with each proposal that gets merged.
LW: I like that idea. It can mean that we don’t have to decide what gets bundled together
EP I like that too.
LW: We could just start with 1.1 now (since we have several proposals merged since the first) but in the future each stage 5 merge gets a version bump.
DS: our current process uses proposals even for small things like bug fixes, so it should work with that.
EP: so each time we merge a stage 5 proposal, someone will edit the ReSpec config.
SR: Zalim Bashorov from JetBrains Kotlin team is asking to add him to WG meeting calendar as CG observer. He’s using form which is mentioned in WG meetings template here https://github.com/WebAssembly/meetings/blob/main/main/2021/WG-06-09.md#registration. I had the same issue earlier #339
DS: thanks for bringing that up. I can see those entries in the form data, but I think right now the problem is that it’s not set up so anyone gets notified when someone submits it. I’ll add those people to the calendar and see if I can fix the notification problem.