Stream: rfc-notifications

Topic: rfcs / issue #14 RFC: Wasmtime 1.0

view this post on Zulip RFC notifications bot (Sep 08 2021 at 21:34):

alexcrichton commented on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 08 2021 at 21:36):

tschneidereit edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 08 2021 at 21:45):

cratelyn commented on issue #14:

:heavy_check_mark: this sounds quite fine to me, thank you for putting this together!

view this post on Zulip RFC notifications bot (Sep 08 2021 at 21:46):

alexcrichton edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 08 2021 at 21:52):

sunfishcode edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 08 2021 at 22:42):

cfallin edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 08 2021 at 22:48):

pchickey edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 09 2021 at 07:40):

bnjbvr edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 09 2021 at 08:17):

sparker-arm commented on issue #14:

So I'm not sure I can agree that the code base is 'production ready'... People are writing hand written tests which make the backends fall over on, or produce incorrect code, on a weekly basis. Full SIMD support has only been in, for Intel and Arm, for a month or so and I think we can now all agree that the Wasm spec tests haven't been good enough at catching bugs. So, I imagine there's still quite a few lingering around and I wouldn't want to be the one backporting the fixes for an LTS release. At least, I think we'd need a caveat in the notes about SIMD support. And generally the lack of aarch64 fuzz testing, continues to make me nervous and without it I would struggle to have faith, at least, in the aarch64 backend in a production environment.

view this post on Zulip RFC notifications bot (Sep 09 2021 at 08:22):

sparker-arm edited a comment on issue #14:

So I'm not sure I can agree that the code base is 'production ready'... People are writing hand written tests which make the backends fall over on, or produce incorrect code, on a weekly basis. Full SIMD support has only been in, for Intel and Arm, for a month or so and I think we can now all agree that the Wasm spec tests haven't been good enough at catching bugs. So, I imagine there's still quite a few lingering around and I wouldn't want to be the one backporting the fixes for an LTS release. At least, I think we'd need a caveat in the notes about SIMD support. And generally, the lack of aarch64 fuzz testing continues to make me nervous and without it I would struggle to have faith, at least, in the aarch64 backend in a production environment.

view this post on Zulip RFC notifications bot (Sep 09 2021 at 08:39):

afonso360 commented on issue #14:

So I'm not sure I can agree that the code base is 'production ready'... People are writing hand written tests which make the backends fall over on, or produce incorrect code, on a weekly basis.

This is true for Cranelift. However, its worth point out that the issues we are opening are for instructions / type combos that are pretty much never emitted from the wasm layer (at least for the ones I checked). We are probably finding about them now exactly because the wasm layer never emits those.

So I think this would be similar to the situation @alexcrichton was mentioning where we have bugs in cranelift which are never exposed to wasmtime.

I haven't used wasmtime too much directly, so I'm not really the best person to comment on its stability as a whole.

view this post on Zulip RFC notifications bot (Sep 09 2021 at 09:16):

sparker-arm commented on issue #14:

Yes, sorry, I was forgetting that this is for wasmtime as a whole.

My concerns over SIMD still stand though generally, it seems most development has been done relying on the wasm spec tests (which has had bugs it in) and for which we haven't had the time or infrastructure to really test it.

view this post on Zulip RFC notifications bot (Sep 09 2021 at 09:34):

tschneidereit commented on issue #14:

My concerns over SIMD still stand though generally, it seems most development has been done relying on the wasm spec tests (which has had bugs it in) and for which we haven't had the time or infrastructure to really test it.

I think these are very valid concerns for SIMD, and we should make sure that they're addressed before enabling SIMD by default. The RFC has a section discussing feature stability, which I think applies here. It seems like right now SIMD doesn't pass the test for items 3 and 4 of the list in that section.

Do you think that that view makes sense, and does that alleviate your concerns?

view this post on Zulip RFC notifications bot (Sep 09 2021 at 09:55):

sparker-arm commented on issue #14:

It seems like right now SIMD doesn't pass the test for items 3 and 4 of the list in that section.

Do you think that that view makes sense, and does that alleviate your concerns?

Ah, thanks. Yes, this seems fair enough to me.

view this post on Zulip RFC notifications bot (Sep 11 2021 at 13:29):

uweigand commented on issue #14:

I'm OK with this proposal.

From the perspective of the s390x architecture, I would really like to see the public CI enabled before we call wasmtime "production ready". As of right now, qemu 6.1 contains all changes needed to run CI in emulation. With PR https://github.com/bytecodealliance/wasmtime/pull/3330 and the dependencies mentioned there, the tree builds and passes CI testing on s390x again, so it should now be possible to enable CI once everything is merged.

view this post on Zulip RFC notifications bot (Sep 13 2021 at 14:09):

alexcrichton edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 14 2021 at 21:15):

alexcrichton commented on issue #14:

I think the discussions about LTS have good points, and I agree at this time with taking the suggestion of just dropping LTS entirely from this proposal. That would mean that there would be no LTS release channel and bug/security fixes would only go to the most-recent-released Wasmtime version.

Does anyone forsee this being an issue? Do users today have a good motivating use case for the LTS releases? (either 1 or 2 or with different schedules) One of the main reasons for dropping them is the lack of concrete motivation for them at this time. We can always add LTS later but removing it is probably going to be much harder.

view this post on Zulip RFC notifications bot (Sep 16 2021 at 14:47):

alexcrichton commented on issue #14:

Ok I've updated the wording here to remove the LTS channels, so we'll just have one version every 4 weeks and the current version receives bugfixes and backports.

Given that we also have additionally sign-offs at this time I'm going to go ahead and...

Entering Final Call Period

https://github.com/bytecodealliance/rfcs/blob/main/accepted/rfc-process.md#making-a-decision-merge-or-close

Once any stakeholder from a different group has signed off, the RFC will move into a 10 calendar day final comment period (FCP), long enough to ensure that other stakeholders have at least a full business week to respond.

The FCP will end on Monday September 27.

view this post on Zulip RFC notifications bot (Sep 17 2021 at 10:44):

tschneidereit edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 27 2021 at 15:57):

alexcrichton commented on issue #14:

Ok with no major objections having been raised, I'm going to merge this. Thanks all!

view this post on Zulip RFC notifications bot (Sep 28 2021 at 08:30):

ulan commented on issue #14:

Thanks for driving this @alexcrichton. The final version of the RFC looks great!

I have only one comment (sorry for missing the main discussion and posting it after the merge): would it be possible to always backport security fixes to the previous version in addition to the current version?

At DFINITY we need at least two weeks to incrementally roll out a new version to production. If there are breaking API changes, then we may need even more time. Guaranteed backporting of security fixes to the previous version would give us more predictable upgrade schedule. Otherwise, in case of a security issue we would need to quickly upgrade to the current version sacrificing testing/canary coverage, which may be problematic if the current version has some regression.

view this post on Zulip RFC notifications bot (Sep 28 2021 at 15:35):

mingqiusun edited a comment on issue #14:

Motion to finalize with a disposition to merge

This hasn't seen some discussion in some time and has been open for awhile to peruse, so I'm gonna try to hit the button and propose that this RFC is merged.

Stakeholders sign-off

This model for a 1.0 for Wasmtime will affect just about everyone using Wasmtime so I've been generous with the tags here for sign-off.

Arm

DFINITY

Embark Studios

Fastly

Google/Envoy

Intel

Microsoft

Mozilla

IBM

wasmCloud

Unaffiliated

view this post on Zulip RFC notifications bot (Sep 30 2021 at 17:34):

alexcrichton commented on issue #14:

We talked about that in today's wasmtime meeting and yeah @ulan we all felt it was reasonable to backport fixes to the latest 2 releases instead of only the latest release. When I get around to implementing all the automation for this I'll write up our release process and such in the wasmtime repo, and I'll be sure to update this when I write it down.

view this post on Zulip RFC notifications bot (Sep 30 2021 at 21:31):

ulan commented on issue #14:

Thank a lot @alexcrichton!

Last updated: Oct 23 2024 at 20:03 UTC