Skip to content

Commit

Permalink
Start moving WASI to a CG-style phases process. (WebAssembly#252)
Browse files Browse the repository at this point in the history 
Adapt the WebAssembly CG's phases process for WASI, and make an
initial mapping of current WASI proposals to phases within this
process. This is quite rough at this time, and not everything
fits in quite yet, and we can adjust things. This is a first
step, and we'll work for greater harmonization as we proceed.
  • Loading branch information
@sunfishcode
sunfishcode authored Apr 13, 2020
1 parent 490a406 commit ef3c605
Show file tree
Hide file tree
Showing 3 changed files with 109 additions and 24 deletions.
37 changes: 37 additions & 0 deletions docs/Process.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# WASI Standardization Process

WASI follows the [WebAssembly CG Phases process], with the following adaptations:

- Entry into Stage 2 requires [witx] specifications.

- Starting in Stage 2, proposals may follow WASI's [ephemeral/snapshot/old] process
to provide a balance between the need for stability so that toolchains and engines
can sync up, and the need for evolution.

- The Phase 4's entry requirements for "Two or more Web VMs implement the feature",
"At least one toolchain implements the feature", and "The formalization and the
reference interpreter are usually updated (though these two can be done as part
of step 3 at the Working Group chair's discretion)." are waived.

In their place, as an additional entry requirement into Phase 2, champion(s) must
include a set of entry criteria into Phase 4 in their proposal, which the Subgroup
will vote on as part of Phase 2 approval.

Phase 4 criteria will vary depending on the API and its expected use cases,
but may include things like multiple independent production implementations,
implementations on multiple host platforms, polyfill implementations, and
bindings in toolchains and libraries. Note that, portability requirements may
vary between proposals, as not all features will necessarily make sense in all
host environments.

- The specific process in Phases 4 and 5 will be determined when we have a
proposal ready for them.

- Requirements around the reference interpreter don't apply.

- WASI proposals don't require formal notation. Formal notation may be used in the
documentation of a feature, but it isn't expected to be practical for all APIs.

[WebAssembly CG Phases process]: https://github.com/WebAssembly/meetings/blob/master/process/phases.md
[witx]: https://github.com/WebAssembly/WASI/blob/master/docs/witx.md
[ephemeral/snapshot/old process]: https://github.com/WebAssembly/WASI/blob/master/phases/README.md
59 changes: 59 additions & 0 deletions docs/Proposals.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
# WASI proposals

This page is under construction. The intent is to follow the CG's
[proposals page], but adapted for [WASI]. Some of the proposals predate our
adoption of this process and so don't fit exactly into the defined phases,
however our intention is to align them going forward.

[WASI]: https://github.com/WebAssembly/WASI
[proposals page]: https://github.com/WebAssembly/proposals/blob/master/README.md

## Active proposals

Proposals follow [this process document](https://github.com/WebAssembly/WASI/blob/master/docs/Process.md).

### Phase 4 - Standardize the Feature (WG)

| Proposal | Champion |
| ------------------------------------------------------------------------------ | -------------------------------------- |

### Phase 3 - Implementation Phase (CG + WG)

| Proposal | Champion |
| ------------------------------------------------------------------------------ | -------------------------------------- |

### Phase 2 - Proposed Spec Text Available (CG + WG)

| Proposal | Champion |
| ------------------------------------------------------------------------------ | -------------------------------------- |
| [I/O][wasi-io] | Dan Gohman |
| [Filesystem][wasi-filesystem] | Dan Gohman |
| [Command-Line][wasi-command-line] | Dan Gohman |
| [Clocks][wasi-clocks] | Dan Gohman |
| [Random][wasi-random] | Dan Gohman |
| [Misc][wasi-misc] | Dan Gohman |

### Phase 1 - Feature Proposal (CG)

| Proposal | Champion |
| ------------------------------------------------------------------------------ | -------------------------------------- |
| [Crypto][wasi-crypto] | Frank Denis and Daiki Ueno |

### Phase 0 - Pre-Proposal (CG)

| Proposal | Champion |
| ------------------------------------------------------------------------------ | -------------------------------------- |
| [proxy-wasm][wasi-proxy-wasm] | Piotr Sikora |

### Contributing new proposals

Please see [Contributing to WebAssembly](https://github.com/WebAssembly/WASI/blob/master/Contributing.md) for the most up-to-date information on contributing proposals to standard.

[wasi-io]: https://github.com/WebAssembly/WASI/phases
[filesystem]: https://github.com/WebAssembly/WASI/phases
[wasi-command-line]: https://github.com/WebAssembly/WASI/phases
[clocks]: https://github.com/WebAssembly/WASI/phases
[random]: https://github.com/WebAssembly/WASI/phases
[misc]: https://github.com/WebAssembly/WASI/phases
[wasi-crypto]: https://github.com/WebAssembly/WASI-crypto
[wasi-proxy-wasm]: https://github.com/WebAssembly/WASI
37 changes: 13 additions & 24 deletions phases/README.md
View file
Original file line number Diff line number Diff line change
@@ -1,6 +1,17 @@
# WASI development process
# WASI's ephemeral/snapshot/old Process

## WASI uses a 3-phase process:
For the standardization process, WASI overall uses a [process]
modeled after the WebAssembly CG's phased process.

For development of features in Phase 2 and later of that process, WASI
has a ephemeral/snapshot/old process, which is designed to allow
for a balance between the need for stability to allow people to build
compatible implementations, libraries, and tools and gain implementation
experience, and the need for proposals to evolve.

[phases process]: https://github.com/WebAssembly/WASI/blob/master/phases/README.md

## The ephemeral/snapshot/old Phases

- [`ephemeral`](ephemeral): The development staging area. New API
proposals API-changing fixes to existing APIs should be submitted
Expand Down Expand Up @@ -37,25 +48,3 @@
versions, the old API modules are moved to the `old` directory. When
possible, `old` APIs may be accompanied by polyfill modules which
implement their API in terms of newer versions of the API.

## Rationale

### Relationship to the CG's phases

When WASI becomes more mature, such that we have an established base
and we're adding incremental functionality to it, we may want to adopt
a process like [the CG's phases]. However, right now, everything in
WASI is undergoing changes, so we have a greater need to iterate with
flexibility.

### Relationship to standards

WASI should eventually become a standard at the level of WebAssembly
itself. Right now, it needs a lot of work before it's ready. The
`snapshot` tree is meant to serve a practical purpose for people who
want to work with APIs today, with the understanding that everything
is still evolving. It's not meant as a replacement for proper
standardization, which will happen once the overall API is more
mature.

[the CG's phases]: https://github.com/WebAssembly/meetings/blob/master/process/phases.md

0 comments on commit ef3c605

Please sign in to comment.