Skip to content

Commit

Permalink
Simplify main WASI repo (#451)
Browse files Browse the repository at this point in the history
  • Loading branch information
linclark committed Feb 2, 2022
1 parent db4e3a1 commit 117e163
Show file tree
Hide file tree
Showing 27 changed files with 301 additions and 973 deletions.
47 changes: 0 additions & 47 deletions .github/workflows/main.yml

This file was deleted.

11 changes: 0 additions & 11 deletions .gitignore

This file was deleted.

55 changes: 54 additions & 1 deletion Contributing.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,61 @@
# Contributing to WebAssembly
# Contributing to WASI

Interested in participating? Please follow
[the same contributing guidelines as the design repository][].

[the same contributing guidelines as the design repository]: https://github.com/WebAssembly/design/blob/master/Contributing.md

Also, please be sure to read [the README.md](README.md) for this repository.

## Championing a Proposal

If you want to champion a new proposal, here's what you need to do in each phase:

### Phase 0: Gauge interest

You have an idea for an API. To see whether others are interested in pursuing the idea, you should work up a rough description of the API and post it somewhere that is publicly visible. This could be in the WASI issue queue, or in a gist or as its own repo. You can use the [proposal template] if you like, but it's not required in this phase.

Once you've done this, you can optionally have the subgroup discuss the idea by adding a discussion item to the [WASI meeting agenda].

Once you feel ready, you can add a vote to the [WASI meeting agenda] to move to the next stage.

### Phase 1: Write spec text

At this point, the WASI SG chair will create a new repo for the proposal in the WebAssembly GitHub org. This will follow the conventions of the [proposal template]. If you have any questions about how to fill in the spec template, you can reach out to the WASI SG chair.

As part of moving to the next phase, the champions need to define the acceptance criteria for Phase 4. This is because WASI includes APIs that cover a diversity of different domains and use cases, so the .

Some examples of potential criteria:

- multiple independent production implementations
- implementations on multiple host platforms
- polyfill implementations
- bindings in toolchains and libraries

Note: portability requirements may vary between proposals, as not all features will necessarily make sense in all host environments.

With all this in place, you can add a vote to [WASI meeting agenda] to move to the next stage.

### Phase 2: Work with implementers to prototype and refine the design

At this point, you should be prototyping the API to make sure it works in practice, and you should develop a test suite which can be used by other implementations to validate their spec compliance.

Once the implmentation has stabilized, it's again time to add a vote to [WASI meeting agenda] to move to the next stage.

### Phase 3: Validate the design through multiple implmentations

At this point, you'll need to get more implementers involved. How many implementations you need depends on the Phase 4 acceptance criteria that you set in Phase 2.

You may need to make changes in response to implementer feedback, but we expect the API to be pretty stable by this point. If implementors uncover especially challenging design issues, the proposal may be sent back to Phase 2 for more development.

Once the implementations are in place, you can add the final WASI SG vote to [WASI meeting agenda]. After this, the proposal advances to a vote in the broader WebAssembly CG.

### Phases 4 & 5: Push it over the finish line

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

Note: While we mostly follow the [WebAssembly CG's Phase Process], the requirements around Web VM implementation, formal notation and the reference interpreter don't apply in the context of WASI.

[proposal template]: https://github.com/WebAssembly/wasi-proposal-template
[WASI meeting agenda]: https://github.com/WebAssembly/meetings/tree/main/wasi
[WebAssembly CG's Phase Process]: https://github.com/WebAssembly/meetings/blob/main/process/phases.md
86 changes: 86 additions & 0 deletions Proposals.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
# WASI proposals

WASI APIs are developed as proposals. These proposals go through 5 phases of development (following the [WebAssembly CG's Phase Process]).

You can learn more about contributing new proposals (and other ways to contribute) in our [Contributing] guide.

[WebAssembly CG's Phase Process]: https://github.com/WebAssembly/meetings/blob/main/process/phases.md
[Contributing]: https://github.com/WebAssembly/WASI/blob/main/Contributing.md

## Active Proposals

### Phase 5 - The Feature is Standardized (WG)

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

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

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

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

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

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

| Proposal | Champion | Versions |
| ------------------------------------------------------------------------------ | -------------------------------------- | -------- |
| [I/O][wasi-io] | Dan Gohman | |
| [Filesystem][wasi-filesystem] | Dan Gohman | |
| ["Classic" Command-Line][wasi-classic-command] (Legacy, to be deprecated in Q4 2022)| Dan Gohman | |
| [Clocks][wasi-clocks] | Dan Gohman | |
| [Random][wasi-random] | Dan Gohman | |
| [Handle Index][wasi-handle-index] | Dan Gohman | |
| [Poll][wasi-poll] | Dan Gohman | |
| [Machine Learning (wasi-nn)][wasi-nn] | Andrew Brown and Mingqiu Sun | |

### Phase 1 - Feature Proposal (CG)

| Proposal | Champion | Versions |
| ------------------------------------------------------------------------------ | -------------------------------------- | -------- |
| [Crypto][wasi-crypto] | Frank Denis and Daiki Ueno | |
| [HTTP][wasi-http] | Piotr Sikora | |
| [Parallel][wasi-parallel] | Andrew Brown | |

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

**Note:** The pre-proposal phase is simply meant as a way to share ideas. This means that there may be overlap between pre-proposals. It also means that the WASI subgroup has not yet decided that the pre-proposal is in scope for WASI.

| Proposal | Champion | Versions |
| ------------------------------------------------------------------------------ | -------------------------------------- | -------- |
| [singlestore-labs/wasi-data][wasi-data] | Bailey Hayes | |
| [proxy-wasm/spec][wasi-proxy-wasm] (will advance as multiple, smaller proposals) | Piotr Sikora | |
| [badeend/WASI-Networking][wasi-networking] | Dave Bakker |

## Versioning

Once a proposal reaches Phase 3, we expect the champions to start creating releases, following the conventions of semantic versioning (semver). Releases for active proposals are linked in the chart above.

Proposals remain in the 0.x semver range until they reach Phase 5 and are fully standardized. At that point, a 1.0 release should be made available.

For some APIs, it makes sense to add new features after the API itself has reached Phase 5. These feature additions should go through the same standardization process. Once they have reached Phase 5, the minor version number of the release should be incremented.

Some APIs may require backwards-incompatible changes over time. In these cases, we allow proposals to increment the major version number _only if_ the old API can be implmented in terms of the new API. As part of the new version, champions are expected to provide a tool that enables this backwards-compatibility. If that is not possible, then a new API proposal with a new name should be started. The original API can then be deprecated over time if it makes sense to do so.

[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

[wasi-clocks]: https://github.com/WebAssembly/wasi-clocks
[wasi-classic-command]: https://github.com/WebAssembly/wasi-classic-command
[wasi-crypto]: https://github.com/WebAssembly/wasi-crypto
[wasi-data]: https://github.com/singlestore-labs/wasi-data
[wasi-filesystem]: https://github.com/WebAssembly/wasi-filesystem
[wasi-io]: https://github.com/WebAssembly/wasi-io
[wasi-misc]: https://github.com/WebAssembly/wasi-misc
[wasi-nn]: https://github.com/WebAssembly/wasi-nn
[wasi-proxy-wasm]: https://github.com/proxy-wasm/spec
[wasi-random]: https://github.com/WebAssembly/wasi-random
[wasi-handle-index]: https://github.com/WebAssembly/wasi-handle-index
[wasi-http]: https://github.com/WebAssembly/wasi-http
[wasi-parallel]: https://github.com/WebAssembly/wasi-parallel
[wasi-poll]: https://github.com/WebAssembly/wasi-poll
[wasi-networking]: https://github.com/badeend/WASI-Networking
Loading

0 comments on commit 117e163

Please sign in to comment.