First, you need to get the CG on board.
-
Present the proposal at a CG meeting.
-
Have a successful poll for moving it to phase 1.
You need admin rights for the GitHub WebAsssembly organisation to execute this step. If you don’t have that, you will need to ask one of the maintainers (@binji, @rossberg, @lukewagner) to do it for you.
-
Pick a repository name for the proposal, e.g.,
multi-bulklets
- in the rest of this document, replace all occurrences of
<<proposal>>
with that name
- in the rest of this document, replace all occurrences of
-
Create the repository on GitHub:
-
Click “New”
-
Enter "Repository name":
<<proposal>>
-
Enter “Description”: the repository title, e.g.,
Multiple Bulklets Proposal
-
Click "Create repository”
-
If you are a maintainer and not the champion, make the champion an admin for this repo:
-
Click "Settings”
-
Go to the "Manage Access" settings
-
Click "Add people" and enter the champion’s GitHub user name
-
Select the "Admin" role and add the champion to the repository
-
Every proposal repository is supposed to be a fork of the main spec
repo. Unfortunately, GitHub does not allow to fork within the same organisation (for whatever reason), so this has to be wired up manually.
-
Set spec as upstream repository:
- Run:
git clone https://github.com/WebAssembly/<<proposal>>.git cd <<proposal>> git remote add upstream https://github.com/WebAssembly/spec.git git fetch upstream git merge upstream/main
- Run:
-
If your proposal has dependencies on another active proposal, whose repository is named
<<parent-proposal>>
, then add that as an additional remote repository:- Run:
git remote add <<parent-proposal>> https://github.com/WebAssembly/<<parent-proposal>>.git git fetch <<parent-proposal>> git merge <<parent-proposal>>/main
Note: If you connect to github using SSH, and run into authentication failures, use the SSH url for the repository instead of the HTTPS url above.
- Run:
-
Create Overview:
-
Run
mkdir proposals/<<proposal>> touch proposals/<<proposal>>/Overview.md git add proposals/<<proposal>>/Overview.md
-
Edit
proposals/<<proposal>>/Overview.md
, e.g., with contents as follows:# Multiple Bulklets Proposal ## Summary This proposal extends Wasm with the ability to define multiple bulklets within a module. ## Motivation * Bulklets are very cool. * They are even better when they come in multiples. ## Overview Here is a sketch of what we wanna add.
-
-
Adjust toplevel readme:
- Edit
README.md
, replacing the first two lines with the following:where[![CI for specs](https://github.com/WebAssembly/spec/actions/workflows/ci-spec.yml/badge.svg)](https://github.com/WebAssembly/spec/actions/workflows/ci-spec.yml) [![CI for interpreter & tests](https://github.com/WebAssembly/spec/actions/workflows/ci-interpreter.yml/badge.svg)](https://github.com/WebAssembly/spec/actions/workflows/ci-interpreter.yml) # <<Title>> Proposal for WebAssembly This repository is a clone of [github.com/WebAssembly/spec/](https://github.com/WebAssembly/spec/). It is meant for discussion, prototype specification and implementation of a proposal to add support for <<Feature Description>> to WebAssembly. * See the [overview](proposals/<<proposal>>/Overview.md) for a summary of the proposal. * See the [modified spec](https://webassembly.github.io/<<proposal>>/) for details. Original `README` from upstream repository follows...
<<Title>>
is the title picked for the repository and<<Feature Description>>
a healf-sentence summary
- Edit
-
Adjust document configuration:
-
Edit
document/core/conf.py
, changing the line definingproposal
to say:proposal = '<<proposal>>'
-
If your proposal has another proposal as a dependency, then it should be included as well:
proposal = '<<parent-proposal>> + <<proposal>>'
-
Change the line defining
repo
to say:repo = '<<proposal>>'
-
-
Turn off running tests with node.js in CI:
- Edit
.github/workflows/ci-interpreter.yml
, changing the line sayingto- run: cd interpreter && opam exec make JS=node all
- run: cd interpreter && opam exec make all
Note: You can revert this once the proposal has been implemented in V8 and downstreamed to node.js, but that can take a long time.
- Edit
-
Commit (
README.md
,proposals/<<proposal>>/Overview.md
,document/core/conf.py
):- Run:
git commit -am "Inital setup and overview" git push
- Run:
Add the proposal to the list of active proposals by creating a respective PR.
-
Edit
README.md
in UI:-
Add line for the proposal in table for Phase 0
-
Create a PR
-
This step makes sure that every commit runs through continuous integration tests. The spec CI scripts also automatically rebuild the spec document and publish it on the repo’s github.io page.
CI is currently done with Github Actions (documentation). When you merge from the upstream spec directory, git should also pull in yml files in .github/workflows
that specify the CI behavior. These files should automatically set up CI actions that run on both commit and on pull requests.
While the CI action will automatically build the spec document and push it to the gh-pages
branch, you may also need to configure the repository to publish this branch to the web:
-
Click "Settings”.
-
Go to the "Pages" settings.
-
Under "Source", click the drop-down button and choose the
gh-pages
branch. -
Click "Save".
This should publish the document to https://webassembly.github.io/<<proposal>>
.
On some pull requests, there may be an additional approval needed from a user with write-access to run the CI actions. See the documentation page on this for details.
Once in a while you will need to merge in changes from the main spec repo.
(Merging changes from possible parent proposals works the same way, but with upstream
replaced by <<parent-proposal>>
.)
-
Merge upstream:
-
Make sure you are on the
main
branch -
Run:
git fetch upstream git merge upstream/main
-
Resolve merge conflicts if necessary
-
Run:
git push
-
If the merge conflicts are complex, you may want to have it reviewed. In that case:
-
Merge upstream with code review:
-
Make sure you are on the
main
branch -
Pick a new
<<branch-name>>
for performing the merge and run:git checkout -b <<branch-name>> git fetch upstream git merge upstream/main
-
Resolve merge conflicts
-
Run:
git commit -m "Merge from upstream spec" git push
-
Create a nicer diff:
The GitHub UI will display this as a list of all the changes added from the spec to this repo, which is not very easy to review. Instead, you can create a diff between this repo and the spec merge base.
-
Run:
git diff upstream/main..origin/<<branch-name>> > <<branch-name>>.diff
-
Go to gist.github.com
-
Paste the contents of
<<branch-name>>.diff
into the edit box -
Name the file
<<branch-name>>.diff
. This will make the diff have proper syntax highlighting. -
Click "Create public gist"
-
Copy the URL
-
-
Create a new pull request
-
Go to
https://github.com/WebAssembly/<<proposal>>/compare
-
Click the right branch button and choose
<<branch-name>>
-
Click "Create pull request"
-
Fill out the details, and make sure to include the URL of your gist
-
-
Once approved, commit
-
Do not use GitHub's "Squash and merge" option for committing upstream changes! That will ruin the history and reiterate all merge conflicts the next time.
-
Instead, select "Merge pull request" (or "Create a merge commit") in GitHub!
-
Alternatively, you can push manually:
git checkout main git merge --ff-only <<branch-name>> git push
This assumes that
main
has not changed in the mean time. If it has, you will have to mergemain
into<<branch-name>>
first.
-
-
Progress needs to be voted on by the Wasm CG meeting.
When the CG agrees to advance a proposal, update its status by creating a respective PR modifying README.md
on the https://github.com/WebAssembly/proposals repo.
Once a proposal has progressed to Stage 5, it is ready to be merged into the main spec. Before doing so:
-
Make sure that all possible parent proposals have been merged.
-
Sync with upstream changes, as described above.
-
Undo the changes to
README.md
anddocument/core/conf.py
that have been made when populating the repo. -
Make sure that Travis is green.
-
Make sure that the changes to the document are rendered correctly.
After merging, archive the proposal repository:
-
Go to "Settings" -> "Options"
-
Click "Archive repository" and follow instructions.
Finally, update the proposals list:
Add the proposal to the list of active proposals by creating a respective PR.
-
Edit
README.md
andfinished-proposals.md
:-
Move the proposal from the former to the latter.
-
Create a PR
-