Plumbers Summit 2026 - Zoom Chat · Events

I'll be talking a bit as well about parallelization of implementation and a general path for how features are implemented too

Alex Crichton (Feb 25 2026 at 16:42):

Mendy Berger (Feb 25 2026 at 16:43):

Alex Crichton (Feb 25 2026 at 16:44):

My impression for enums is that'd be more-or-less under the "function subtyping" category which has a number of open questions, but would probably end up being that moniker (e.g. as a form of WIT evolution)

Till Schneidereit (Feb 25 2026 at 16:44):

in the Zoom chat, @Victor Adossi jokingly said "The bikeshedding starts now right?"

I think there's an important kernel of truth here: the idea for a Component Model 1.0 is to achieve stability for decades, not years. So we certainly want to get things as right as possible, and very much appreciate input!

Victor Adossi (Feb 25 2026 at 16:45):

Great point -- so far it's a small miracle that no showstopping design issues have occurred, thanks to collaboration and good careful painting.

Mendy Berger (Feb 25 2026 at 16:53):

Till Schneidereit (Feb 25 2026 at 17:01):

Not entirely, no: JS doesn't have the ability to suspend entire stacks (instead of single frames for async functions), so if you need to suspend an entire call stack, you have to build that in-content yourself. JSPI does integrate stack suspension for Wasm into the JS event loop

Bailey Hayes (Feb 25 2026 at 17:05):

For Sy: Are there places that folks can start on work? Like for the guest languages? Is it about ready for that?

Joel Dice (Feb 25 2026 at 17:06):

I'm expecting wasi-libc pthread support will be the foundation for most guest toolchains

Joel Dice (Feb 25 2026 at 17:07):

(i.e. those toolchains will need to wait for at least an experimental, thread-enabled wasi-sdk release)

Bailey Hayes (Feb 25 2026 at 17:07):

Joel Dice (Feb 25 2026 at 17:08):

Till Schneidereit (Feb 25 2026 at 17:08):

for preemptively scheduled, parallel multi-threading, this proposal and this paper are relevant

Sy Brand (Feb 25 2026 at 17:13):

I gotta run but look forward to watching the rest of the sessions later! Folks can feel free to ping me here with and coop threading questions

Joel Dice (Feb 25 2026 at 17:19):

Per Alex's presentation: componentize-py does also use the same steps, but mostly hides them behind the scenes for a simple UX

Oscar Spencer (Feb 25 2026 at 17:45):

Reminder for folks: feel free to take a 15 minute break now! Otherwise, stick around for some watercooler chat :sunglasses:

Bailey Hayes (Feb 25 2026 at 17:45):

When will we opt to break apart wasi and CM versions (right now coupled to decrease release/maintainer/stability overhead)?

Bailey Hayes (Feb 25 2026 at 17:48):

where is map in this iteration/feedback process? What will be the point where we say it's "shipped"?

Joel Dice (Feb 25 2026 at 17:51):

David Bryant (Feb 25 2026 at 17:55):

From Zailm in Zoom chat: "I don’t know if it’s the right/best session for that, but I’m wondering about plans re eh and gc in wasmtime. When we can expect it moved to tear 1 (on by default)?"

Joel Dice (Feb 25 2026 at 17:56):

fitzgen (he/him) (Feb 25 2026 at 17:56):

Bailey Hayes (Feb 25 2026 at 17:56):

for alex -> but exception-handling is experimental in wasi-libc on LLVM patch. Will you share some status there?

Alex Crichton (Feb 25 2026 at 17:57):

Bailey Hayes (Feb 25 2026 at 17:58):

(basically in your flow diagram, I think we're essentially at the guest language stage + wasmtime hardening)

fitzgen (he/him) (Feb 25 2026 at 17:59):

correct, although this isn't necessarily a blocker for turning it on in wasmtime

fitzgen (he/him) (Feb 25 2026 at 18:01):

Alex Crichton (Feb 25 2026 at 18:01):

@Chris Fallin yeah that issue ^ is what I was thinking of in terms of we may want to tune things if we ship exceptions w/o GC but definitely not a major new implementation

Alex Crichton (Feb 25 2026 at 18:02):

and if it's a huge amount of work to ship exceptions w/o GC I also don't think it'd be worth it

Lann Martin (Feb 25 2026 at 18:02):

Chris Fallin (Feb 25 2026 at 18:02):

Yosh Wuyts (Feb 25 2026 at 18:08):

Browser JSPI support also made it to interop 2026, which means browsers are like very publicly committing to implementing it this year. (See e.g. WebKit: Interop 2026 - JSPI)

David Bryant (Feb 25 2026 at 18:09):

From Zalim in Zoom chat: "There’s implementation for stack switching in v8. Also, we have PoC in Kotlin."

Yosh Wuyts (Feb 25 2026 at 18:11):

By the way: what chat should we be posting in? There's both this one and #Events > Plumbers Summit - February 2026 , but I don't know what the difference is :sweat_smile:

Oscar Spencer (Feb 25 2026 at 18:12):

Yosh Wuyts (Feb 25 2026 at 18:12):

Alex Crichton (Feb 25 2026 at 18:12):

Sorry I think I added confusion... I figured the other was more logistics-related so made this for ad-hoc stuff

Till Schneidereit (Feb 25 2026 at 18:12):

Chris Fallin (Feb 25 2026 at 18:12):

@Joel Dice I'm happy to talk to you about wevaling Python at some point; I played with this a little bit when writing the paper after doing the initial SpiderMonkey work. I think it's possible, requires a few refactors in the interpreter

Oscar Spencer (Feb 25 2026 at 18:12):

Chris Fallin (Feb 25 2026 at 18:13):

(the usual caveats about dynamic types as a limit of non-JIT approaches still apply -- I don't remember if CPython has ICs or not)

Till Schneidereit (Feb 25 2026 at 18:14):

In addition to the status descriptions Joel is just talking through, I gave an update on StarlingMonkey yesterday. It's not just about WASIp3, but that is part of it

David Bryant (Feb 25 2026 at 18:14):

(I'm keeping an eye on both the Zulip chat topics, and the Zoom one, so we have one unified conversation here recorded for posterity. Asking anywhere is fine!)

Alex Crichton (Feb 25 2026 at 18:15):

Question for Joel: Can you speak more to the C++ exceptions requirement for Python? That part wasn't clear to me

Chris Fallin (Feb 25 2026 at 18:15):

re: weval in StarlingMonkey, yep, Tomasz's rebase of my patches appears to be passing everything now (the bug I had been seeing earlier wrt LLVM changes has gone away)

Till Schneidereit (Feb 25 2026 at 18:16):

@Alex Crichton IIUC Python C Extensions fundamentally require exceptions support. Either that, or some of the most important ones simply use exceptions in their implementation

Lann Martin (Feb 25 2026 at 18:18):

Yosh Wuyts (Feb 25 2026 at 18:20):

Chris Fallin (Feb 25 2026 at 18:21):

re: Java, do we have any info about Google's efforts to compile Java to WasmGC in the browser? Is it a subset/dialect?

Bailey Hayes (Feb 25 2026 at 18:21):

David Bryant (Feb 25 2026 at 18:23):

From Zalim in Zoom chat: "JFTR: Kotlin: we resumed our work on CM support, have prototype, working a new modernized version, aimed to ship it"

Brett Cannon (Feb 25 2026 at 18:26):

Yosh Wuyts (Feb 25 2026 at 18:28):

Till Schneidereit (Feb 25 2026 at 18:31):

Oscar Spencer (Feb 25 2026 at 18:32):

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:39):

Offtopic: Any plans to provide an ability to load multiple wasm modules/files in wasmtime and other standalone VMs? Maybe something like esm-integration?

Alex Crichton (Feb 25 2026 at 18:40):

Alex Crichton (Feb 25 2026 at 18:42):

Most of our existing use cases are primarily embedding-driven in the sense of we don't have a lot of major users of the wasmtime CLI outside of hobby/test/etc things. That effectively doesn't motivate a lot of feature-development work just for the CLI, which this would fall under, but doesn't mean we wouldn't want it

Bailey Hayes (Feb 25 2026 at 18:45):

another interesting place to extend could be jco serve where something like ESM integration would be easy

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:46):

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:48):

In Kotlin, in the long term, we consider moving into generating multiple wasm modules instead of a monolithic one. And a lack of such a possibility in standalone VMs is one of the blockers.

Alex Crichton (Feb 25 2026 at 18:49):

The general shape that this would have is that wasmtime would, via import names, auto-compose a bunch of components together and then run that final component. To the extent that this would be useful for embedders it would be to share this composition functionality, but otherwise I believe some hosts already do this where native host APIs are implemented in terms of host-provided components.

Alex Crichton (Feb 25 2026 at 18:49):

I'd love to chat more though about your use case though, would you be up for opening an issue on Wasmtime for this?

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:50):

Till Schneidereit (Feb 25 2026 at 18:54):

to emphasize a key point Alex is making: the solution to linking multiple modules and components is the component model! Adding support for another ad-hoc system for setting up compositions wouldn't really help the ecosystem overall, unless it's also standardized. But it's not entirely clear why we'd need that on top of the CM—with the ability to load external .wasm files references from within a component being a key thing we need to make turn-key and usable from wasmtime serve, etc

fitzgen (he/him) (Feb 25 2026 at 18:55):

I have wanted --preload for components in the wasmtime CLI before in certain situations, seems reasonable to support for local/incremental dev situations

Alex Crichton (Feb 25 2026 at 18:56):

I'd envision this personally as a sort of filesystem/import-string driven auto-composition which wasmtime would then run, which I agree would be useful to have

Joel Dice (Feb 25 2026 at 19:00):

@Zalim Bashorov (Kotlin_, JetBrains) when you talk about multiple modules, are you thinking of runtime instantiation (i.e. loading and instantiating a module on-the-fly from an already-running Wasm app)? If so, that's something that the component model _will_ address, but doesn't yet (nor does any other standard AFAIK).

If all the modules are known ahead of time and instantiated at the same time, then the component model as it exists today should be sufficient.

Till Schneidereit (Feb 25 2026 at 19:01):

yeah, that's what I mean. I think a --preload wouldn't quite work in the same way as for core modules, since you need the instructions how to do instantiation and linking and such

Mendy Berger (Feb 25 2026 at 19:02):

Thanks to all speakers and organizers! Great sessions packed with interesting information!

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 19:13):

@Joel Dice in general, we want to have both static and dynamic loading, but for outside of the browser, it's mainly static (known ahead of time).

Does wasmtime support loading components from multiple files, or should they be merged first?

Alex Crichton (Feb 25 2026 at 19:14):

Currently they're required to be composed (merged) first into a single component, the CLI only knows how to run components which import WASI interfaces. If a component imports something else then it won't be runnable

fitzgen (he/him) (Feb 25 2026 at 19:19):

I still think something like --preload would be nice because it requires less activation energy than creating a directory tree of the exact right shape

regarding instantiation and linking and --preload, I'd think that every --preload would just insert into the wasmtime::component::Linker and we would ultimately just propagate any linking errors if any

I don't think it would need to have the full expressivity power of the CM, but it would be really nice for simple, quick-and-dirty cases

Till Schneidereit (Feb 25 2026 at 19:21):

oh, I see! Yeah, adding any exported interfaces to the linker would make --preload make a ton of sense, and indeed quite useful!

Joel Dice (Feb 25 2026 at 19:21):

@Zalim Bashorov (Kotlin_, JetBrains) See Linking.md for a detailed discussion of the various ways the component model supports linking (today and in the future).

Mendy Berger (Feb 26 2026 at 16:01):

Till Schneidereit (Feb 26 2026 at 16:02):

Yosh Wuyts (Feb 26 2026 at 16:09):

Joel Dice (Feb 26 2026 at 16:10):

Till Schneidereit (Feb 26 2026 at 16:10):

it can be used for that. But also for things like get-pixel(x, y) -> u32, used in a tight loop

Chris Fallin (Feb 26 2026 at 16:10):

it's made to expose the host buffers we have in our embedding -- the core engine manages buffers that network devices DMA into and out of, and we want to use those directly, for zero copy from wire to wire

Joel Dice (Feb 26 2026 at 16:11):

you can also potentially do io_uring-style zero-copy with CM streams by using guest memory for io_uring buffer allocation

Yosh Wuyts (Feb 26 2026 at 16:11):

Chris Fallin (Feb 26 2026 at 16:12):

Yep, if you control the host side and buffer allocation, you can indeed do that. In our embedding (and in I suspect other use-cases as well) we're slotting into an existing system where we can't take over buffer allocation -- we are just given a pointer -- so this is designed to allow for that flexibility

Dave Bakker (badeend) (Feb 26 2026 at 16:14):

Maybe noob question: What's preventing the (unsafe) Rust host code from being inlined directly? Opposed to rewriting it in a custom IDL

Chris Fallin (Feb 26 2026 at 16:15):

that's a really interesting holy grail! right now, different compilers. one could see a future where cg_clif is used to build host code into CLIF that we keep around to inline, maybe -- but there are lots of caveats there wrt ABIs, etc, and also Wasmtime API design (we opted not to expose CLIF as an IR that we take for now)

Joel Dice (Feb 26 2026 at 16:20):

Sy Brand (Feb 26 2026 at 16:20):

Joel Dice (Feb 26 2026 at 16:20):

Till Schneidereit (Feb 26 2026 at 16:24):

the zero-copy-buf interface would require hosts to support compile-time builtins to implement, right?

Dave Bakker (badeend) (Feb 26 2026 at 16:24):

Chris Fallin (Feb 26 2026 at 16:27):

zero-copy-buf without inlining is "zero-copy" in a weird sense because it's giving you the u8s one call at a time; the "money transfer structuring" cheat of the buffering world

Till Schneidereit (Feb 26 2026 at 16:27):

I wonder if lazy-lowering could introduce support to lower stream chunks into a zero-copy-buf like thing, as a canon-opt?

Till Schneidereit (Feb 26 2026 at 16:29):

Joel Dice (Feb 26 2026 at 16:31):

Again, though, if you _can_ just allocate your buffers from guest memory to begin with and let the host use that directly, no fanciness required, that should be the default choice IMHO.

Joel Dice (Feb 26 2026 at 16:31):

Till Schneidereit (Feb 26 2026 at 16:32):

that requires much more massive change to everything around it, though, and isn't always feasible at all

Till Schneidereit (Feb 26 2026 at 16:36):

(e.g., IIUC Tokio/Hyper don't make this possible, so the "massive change" here would be moving to another async runtime)

Joel Dice (Feb 26 2026 at 16:37):

Yeah, Tokio/Hyper will need a different API to take proper advantage of io_uring anyway, nevermind the Wasm aspect.

Dave Bakker (badeend) (Feb 26 2026 at 16:38):

Question: How optimized is the current async state transition stuff? Is it at a "first implementation" level that satisfies the spec as cleanly as possible (i.e. optimized for spec compliance rather than performance). Or is it already optimized decently?

Given the huge different in bar heights on the graph, I'm just trying to understand if the "big bar" just a effect of the current implementation, or it is necessary by design

fitzgen (he/him) (Feb 26 2026 at 16:47):

fitzgen (he/him) (Feb 26 2026 at 16:50):

Joel Dice (Feb 26 2026 at 16:59):

Erik Rose (Feb 26 2026 at 17:04):

Yosh Wuyts (Feb 26 2026 at 17:06):

Mendy Berger (Feb 26 2026 at 17:12):

Sy Brand (Feb 26 2026 at 17:12):

fitzgen (he/him) (Feb 26 2026 at 17:12):

Chris is only implementing it for Wasmtime (afaik) but there is nothing in principle from stopping another engine from also implementing it

fitzgen (he/him) (Feb 26 2026 at 17:13):

long-term it may make sense to standardize, or add to tool conventions, but I'd be hesitant to do that too early

Mendy Berger (Feb 26 2026 at 17:15):

Yosh Wuyts (Feb 26 2026 at 17:16):

LLDB struggles representing things like Rust enums during debugging; how well is this able to represent items like that?

fitzgen (he/him) (Feb 26 2026 at 17:16):

for the time being, languages won't be implementing this interface themselves (unless they are really excited to)

Mendy Berger (Feb 26 2026 at 17:16):

Chris Fallin (Feb 26 2026 at 17:18):

fortunately (?) that problem is orthogonal to the guest-debugging work -- LLDB gets a view of Wasm memory and locals at a low level, and uses the same logic to interpret that into source-language values that it does on native platforms. So if it gets better on (say) x86, it'll get better on Wasm too

Zalim Bashorov (Kotlin_, JetBrains) (Feb 26 2026 at 17:19):

I'd expect producers and debugger UIs (IDE?) to first focus on common/standardized ways, and only then adopt custom things to implement advanced features if required.

Joel Dice (Feb 26 2026 at 17:30):

Alex Crichton (Feb 26 2026 at 17:31):

Support for fallible allocations is unfortunately a pretty hairy ball of questions in upstream Rust so while any one particular API is probably not too bad the general story for OOM-handling is likely to stymie much progress

Yosh Wuyts (Feb 26 2026 at 17:32):

Ryan Hunt (Feb 26 2026 at 17:35):

Yosh Wuyts (Feb 26 2026 at 17:35):

If you want I can put you in touch with the Rust for Linux folks; they have very similar fallible allocation needs as Wasmtime and might be interested in collaborating on something like "try-std"

Joel Dice (Feb 26 2026 at 17:39):

FuturesUnordered mostly ~~just wraps a hashmap, data structure-wise, IIRC,~~ (EDIT: maybe not, just looked and it's more complicated than that) so maybe we could start by forking our own version and making it OOM safe?

Ryan Hunt (Feb 26 2026 at 17:39):

oomTest works great for finding a lot of OOM handling issues. The hardest ones to find are the cases where you are allowed to retry an action after an OOM. You can end up in a situation like:

1. First call to a method:
a. Mutate some fields
b. Try to allocate something and it fails with OOM
c. Fail to unwind the first mutations

2. Second call to a method:
a. Observes inconsistent state where some fields were mutated, but not allowed

Yosh Wuyts (Feb 26 2026 at 17:39):

If y'all switch to futures-concurrency, I'd be happy to add support for fallible allocation behind a flag: https://docs.rs/futures-concurrency

Yosh Wuyts (Feb 26 2026 at 17:40):

Bailey Hayes (Feb 26 2026 at 17:40):

I wonder how much work the wasmtime-wasi-io step is and if it's worth considering scoping to just p3.

Dave Bakker (badeend) (Feb 26 2026 at 17:41):

Reimplementing std for fun and profit
minus the "fun" part and minus the "profit" part :face_with_open_eyes_and_hand_over_mouth:

Yosh Wuyts (Feb 26 2026 at 17:41):

Pat Hickey (Feb 26 2026 at 17:41):

small compared to a lot of the other stuff nick has done as part of this effort, imo

Pat Hickey (Feb 26 2026 at 17:42):

at any rate, for the embeddings nick is targeting, we will be shipping p2 so we will need a wasmtime-wasi-io solution even after we also offer p3

Ryan Hunt (Feb 26 2026 at 17:46):

A little bit off-topic to the agenda, but of interest to folks here. We (Mozilla) just published a blog post about Wasm Components on the Web:

Chris Fallin (Feb 26 2026 at 17:46):

one bonus bit of demo I forgot to show from my talk, for anyone curious -- disassembling and single-instruction-stepping (at the wasm bytecode level!) does work in LLDB too:

* thread #1, name = 'nobody', stop reason = breakpoint 2.1                        09:45:15 [42/1898]
       frame #0: 0x400000000000023e wasm`fib(n=<unavailable>) at test.c:12:9
   9
   10   __attribute__((noinline))
   11   int fib(int n) {
-> 12       int a = 1, b = 1;
   13       for (int i = 2; i < n; i++) {
   14           int sum = a + b;
   15           a = b;
(lldb) disas
wasm`fib:
[ ... ]
    0x4000000000000239 <+16>:  local.get 0
    0x400000000000023b <+18>:  i32.store 28
->  0x400000000000023e <+21>:  local.get 1

Till Schneidereit (Feb 26 2026 at 17:47):

Scott Waye (Feb 26 2026 at 17:47):

fitzgen (he/him) (Feb 26 2026 at 17:48):

fitzgen (he/him) (Feb 26 2026 at 17:54):

Chris Fallin (Feb 26 2026 at 17:55):

fitzgen (he/him) (Feb 26 2026 at 18:11):

idle question: should we allocate resource tables with the engine's InstanceAllocator? (which would allow pre-allocating them, with simple/obvious limits, in the pooling allocator)

longer-term, this seems related to the allocation combinator traits stuff I've been floating at various wasmtime meetings

Alex Crichton (Feb 26 2026 at 18:12):

Sort of sort of not I think, it's becoming more and more of a central resource which I think would make sense to put in there, but values in a table often have host-backed memory e.g. http::HeaderMap

Alex Crichton (Feb 26 2026 at 18:12):

fitzgen (he/him) (Feb 26 2026 at 18:12):

Paul Osborne (Feb 26 2026 at 18:12):

For our own hostcalls, I've gone the route of having a proxy in front of the ResourceTable that tracks allocations, but that can't extend to code reused from wasmtime for wasi calls as these depend on a concrete &mut ResourceTable.

Alex Crichton (Feb 26 2026 at 18:13):

Add something like that natively to Wasmtime I think would be reasonable as well, it's not something we could backport but I think would be reasonable to consider going forward

fitzgen (he/him) (Feb 26 2026 at 18:14):

Dave Bakker (badeend) (Feb 26 2026 at 18:16):

FYI: wasi-sockets' constructor is fallible, but doesn't have a "limit reached" error code

Chris Fallin (Feb 26 2026 at 18:17):

(weird brain tangent) somehow "888, 889, 890" sounded like a phone number at the end of Pat's talk -- "call this number if you think you may have resource exhaustion issues"

Oscar Spencer (Feb 26 2026 at 18:18):

Till Schneidereit (Feb 26 2026 at 18:18):

Joel Dice (Feb 26 2026 at 18:29):

Yan Chen (Feb 26 2026 at 18:31):

The Rust's syn crates is particular useful here, which gets us an AST that we can analyze.

Yan Chen (Feb 26 2026 at 18:32):

Yosh Wuyts (Feb 26 2026 at 18:41):

This is very very cool. I'd love for us to start using it to populate the specifications/ dir in the WASI repo

Yosh Wuyts (Feb 26 2026 at 18:41):

Yosh Wuyts (Feb 26 2026 at 18:42):

Bailey Hayes (Feb 26 2026 at 18:43):

Dave Bakker (badeend) (Feb 26 2026 at 18:44):

Question #1: How do you see the POSIX'y interfaces (like filesystem, sockets, ..) being specified? I like the level of detail of the web specs, but for those POSIX-like interfaces it ultimately boils down to: we expose whatever the OS does, with all its quirks and oddities.

Question #2: Do we need to maintain this separately from the WIT files or can it be integrated into the WITs themselves or vice versa? To remove the double bookkeeping

Yosh Wuyts (Feb 26 2026 at 18:44):

It's also interesting to consider the way this could link back to wasi-testsuite, where each step in the spec ends up referring back to a test and vice-versa.

Till Schneidereit (Feb 26 2026 at 18:49):

@Yosh Wuyts yeah, I've been thinking about that, but don't yet have a good answer for how exactly to do that in a low-overhead way

Scott Waye (Feb 26 2026 at 18:50):

Till Schneidereit (Feb 26 2026 at 18:51):

Yosh Wuyts (Feb 26 2026 at 18:52):

@Till Schneidereit you might like https://github.com/bearcove/tracey - it has some really good ideas for two-way linking between specifications and tests, and implementations and tests. The general approach is apparently modeled after some of the big fancy tools used in the safety-critical industry.

Yosh Wuyts (Feb 26 2026 at 18:55):

Till Schneidereit (Feb 26 2026 at 18:55):

oooh, I hadn't seen that; looks very relevant indeed! Thank you for sharing :heart:

Till Schneidereit (Feb 26 2026 at 19:23):

one thing I forgot to mention about specwit: the online editor uses JCO to run a componentized version of specwit in the browser—which worked on the first try :heart:

Stream: Events

Topic: Plumbers Summit 2026 - Zoom Chat

Alex Crichton (Feb 25 2026 at 16:01):

Till Schneidereit (Feb 25 2026 at 16:34):

Bailey Hayes (Feb 25 2026 at 16:39):

Bailey Hayes (Feb 25 2026 at 16:42):

Alex Crichton (Feb 25 2026 at 16:42):

Alex Crichton (Feb 25 2026 at 16:42):

Mendy Berger (Feb 25 2026 at 16:43):

Alex Crichton (Feb 25 2026 at 16:44):

Till Schneidereit (Feb 25 2026 at 16:44):

Victor Adossi (Feb 25 2026 at 16:45):

Mendy Berger (Feb 25 2026 at 16:53):

Till Schneidereit (Feb 25 2026 at 17:01):

Bailey Hayes (Feb 25 2026 at 17:05):

Joel Dice (Feb 25 2026 at 17:06):

Joel Dice (Feb 25 2026 at 17:07):

Bailey Hayes (Feb 25 2026 at 17:07):

Joel Dice (Feb 25 2026 at 17:08):

Till Schneidereit (Feb 25 2026 at 17:08):

Sy Brand (Feb 25 2026 at 17:13):

Joel Dice (Feb 25 2026 at 17:19):

Oscar Spencer (Feb 25 2026 at 17:45):

Bailey Hayes (Feb 25 2026 at 17:45):

Bailey Hayes (Feb 25 2026 at 17:48):

Joel Dice (Feb 25 2026 at 17:51):

David Bryant (Feb 25 2026 at 17:55):

Joel Dice (Feb 25 2026 at 17:56):

fitzgen (he/him) (Feb 25 2026 at 17:56):

Bailey Hayes (Feb 25 2026 at 17:56):

Alex Crichton (Feb 25 2026 at 17:57):

Bailey Hayes (Feb 25 2026 at 17:58):

fitzgen (he/him) (Feb 25 2026 at 17:59):

fitzgen (he/him) (Feb 25 2026 at 18:01):

Alex Crichton (Feb 25 2026 at 18:01):

Alex Crichton (Feb 25 2026 at 18:02):

Lann Martin (Feb 25 2026 at 18:02):

Chris Fallin (Feb 25 2026 at 18:02):

Yosh Wuyts (Feb 25 2026 at 18:08):

David Bryant (Feb 25 2026 at 18:09):

Yosh Wuyts (Feb 25 2026 at 18:11):

Oscar Spencer (Feb 25 2026 at 18:12):

Yosh Wuyts (Feb 25 2026 at 18:12):

Alex Crichton (Feb 25 2026 at 18:12):

Till Schneidereit (Feb 25 2026 at 18:12):

Chris Fallin (Feb 25 2026 at 18:12):

Oscar Spencer (Feb 25 2026 at 18:12):

Chris Fallin (Feb 25 2026 at 18:13):

Till Schneidereit (Feb 25 2026 at 18:14):

David Bryant (Feb 25 2026 at 18:14):

Alex Crichton (Feb 25 2026 at 18:15):

Chris Fallin (Feb 25 2026 at 18:15):

Till Schneidereit (Feb 25 2026 at 18:16):

Lann Martin (Feb 25 2026 at 18:18):

Yosh Wuyts (Feb 25 2026 at 18:20):

Chris Fallin (Feb 25 2026 at 18:21):

Bailey Hayes (Feb 25 2026 at 18:21):

David Bryant (Feb 25 2026 at 18:23):

Brett Cannon (Feb 25 2026 at 18:26):

Yosh Wuyts (Feb 25 2026 at 18:28):

Till Schneidereit (Feb 25 2026 at 18:31):

Oscar Spencer (Feb 25 2026 at 18:32):

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:39):

Alex Crichton (Feb 25 2026 at 18:40):

Alex Crichton (Feb 25 2026 at 18:42):

Bailey Hayes (Feb 25 2026 at 18:45):

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:46):

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:48):

Alex Crichton (Feb 25 2026 at 18:49):

Alex Crichton (Feb 25 2026 at 18:49):

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 18:50):

Till Schneidereit (Feb 25 2026 at 18:54):

fitzgen (he/him) (Feb 25 2026 at 18:55):

Alex Crichton (Feb 25 2026 at 18:56):

Joel Dice (Feb 25 2026 at 19:00):

Till Schneidereit (Feb 25 2026 at 19:01):

Mendy Berger (Feb 25 2026 at 19:02):

Zalim Bashorov (Kotlin_, JetBrains) (Feb 25 2026 at 19:13):

Alex Crichton (Feb 25 2026 at 19:14):

fitzgen (he/him) (Feb 25 2026 at 19:19):