2026-04-02
[07:43:25.0406] <nicolo-ribaudo>
So, times for the new editor call:
- Every thursday at 8:00 am pacific time, starting from next week
- Every 4 mondays at 14:00 am pacific time (current meeting time), starting from April 27th

[07:43:39.0204] <nicolo-ribaudo>
* So, times for the new editor call:

- Every thursday at 8:00 am pacific time, starting from next week
- Extra meeting every 4 mondays at 14:00 am pacific time (current meeting time), starting from April 27th

[07:44:11.0314] <nicolo-ribaudo>
Could somebody that has access to the calendar update it?

[09:09:31.0523] <Chris de Almeida>
presuming "14:00 am pacific time" means 14:00, e.g. 2 pm

[09:10:41.0304] <Chris de Almeida>
remember the F5 zoom meeting will need to be updated too

[09:11:25.0339] <Chris de Almeida>
they both currently have the same meeting link, I'm guessing one will need to change?

[09:20:15.0885] <Michael Ficarra>
no, the Zoom meeting links can be used at any time and as many times as you want

[09:20:21.0435] <Michael Ficarra>
it's like Meet, not Webex


2026-04-03
[11:24:14.0994] <Michael Ficarra>
ES2026 intro summary PR is up: https://github.com/tc39/ecma262/pull/3793

[11:24:53.0621] <Michael Ficarra>
also this PR removes Kevin from the editors list: https://github.com/tc39/ecma262/pull/3794

[11:25:24.0800] <Michael Ficarra>
editors: please send PRs adding yourself to the current editors list

[11:27:33.0342] <linus>
do we have to censor our emails like that? seems silly

[11:31:08.0691] <Michael Ficarra>
whatever you like

[11:31:36.0755] <Michael Ficarra>
I still get spams from it 😅

[11:33:34.0763] <Richard Gibson>
how shall we order? Alphabetical by family name is conventional, but even with two names we're already not doing that

[12:18:49.0137] <Michael Ficarra>
doesn't matter to me, maybe just PR open time lol 


2026-04-04
[21:45:19.0052] <ljharb>
rbuckton: heads up, please don't merge things into the spec; i handle all the merging.


2026-04-06
[11:48:06.0869] <jmdyck>
editor call has officially moved to Thursday?

[12:01:55.0026] <Michael Ficarra>
yes

[12:08:58.0813] <shu>
did you also decide how often and when to have the afternoon PT meeting?

[12:41:33.0987] <Chris de Almeida>
https://matrix.to/#/!nSLHQtIRJQxUJbEuGt:matrix.org/$h1p_Tz_KBnzqafVZUoJihq6K-lAUjYHQnxT1WTT0TZA?via=matrix.org&via=igalia.com&via=mozilla.org

[13:21:00.0261] <shu>
great, thank you


2026-04-08
[08:30:13.0580] <Michael Ficarra>
if we have time at one of the next few editor calls, I think we should do some PR prioritisation

[08:30:38.0954] <Michael Ficarra>
a couple of @jmdyck:matrix.org's model-everything-as-records PRs are high priority IMO

[08:30:44.0231] <Michael Ficarra>
also ERM and Temporal of course

[14:29:50.0216] <Michael Ficarra>
oops: I accidentally just pushed a commit to `main` (why does GitHub let me do that?!)

[14:30:03.0443] <Michael Ficarra>
anyway, I pushed a revert immediately and I'll open a PR for it instead

[14:42:06.0813] <Michael Ficarra>
btw, @ljharb:matrix.org is there a way we can make the "publish PR preview" job so that no more than one is running at the same time?

[14:42:29.0244] <Michael Ficarra>
whenever 2 or more are running at the same time, 1 will succeed and the others will all fail and then I have to re-run them one by one

[15:10:05.0407] <ljharb>
not easily 

[15:10:24.0677] <ljharb>
the proper way would be to have the PR workflow write to a queue, and a dispatched workflow process the queue

[15:10:58.0943] <ljharb>
also i can force push out the mistaken commit, nbd

[15:42:30.0899] <Michael Ficarra>
that sucks, other CI systems I've used make that super easy to do

[15:42:49.0228] <rbuckton>
Branch protection is enabled, but `@tc39/ecma262-editors` has the admin role so it can probably bypass it.

From https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches?utm_source=copilot.com#about-branch-protection-rules

> By default, the restrictions of a branch protection rule don't apply to people with admin permissions to the repository or custom roles with the "bypass branch protections" permission. You can optionally apply the restrictions to administrators and roles with the "bypass branch protections" permission, too. For more information, see Managing custom repository roles for an organization.

[15:43:28.0016] <Michael Ficarra>
@rbuckton:matrix.org I *do* want to be able to bypass it from the UI when I click the checkbox if I need to do that, but I don't want it to just auto-bypass it from a push at the CLI!

[15:44:01.0422] <Michael Ficarra>
there's almost no point in having branch protections at that point

[15:45:21.0856] <rbuckton>
Also, github has merge queues, we just don't have it enabled in our branch protection rules: 


[15:46:11.0030] <rbuckton>
ah, here's the branch protection rule about administrators: 

[15:46:52.0081] <Michael Ficarra>
that's not what I'm looking for @rbuckton:matrix.org, the "publish PR preview" job is part of CI, not part of merging

[15:47:05.0237] <rbuckton>
Ah, true

[15:47:10.0748] <Michael Ficarra>
I need a CI semaphore

[15:54:31.0429] <rbuckton>
https://dev.to/mktcode/make-github-workflows-run-consecutively-265f

[15:56:18.0088] <Michael Ficarra>
I think this does what I want: https://github.com/marketplace/actions/mutex-action

[16:01:48.0725] <Michael Ficarra>
🤞 https://github.com/tc39/ecma262/pull/3821

[16:16:13.0191] <Michael Ficarra>
also, should we periodically purge the closed PRs from the gh-pages branch to keep the repo size down?


2026-04-09
[17:06:53.0296] <bakkot>
do we care about repo size?

[17:11:20.0657] <Michael Ficarra>
I dunno, whenever I pull, it takes forever to update gh-pages

[17:11:26.0419] <Michael Ficarra>
maybe I just need to not pull all branches

[17:15:04.0596] <bakkot>
yeah ok

[17:15:10.0789] <bakkot>
claude can probably figure this out

[17:15:40.0069] <bakkot>
I think it's probably fine to do as soon as the PR lands?

[17:20:31.0809] <bakkot>
https://github.com/tc39/ecma262/pull/3824

[08:27:18.0077] <ljharb>
I’ll land all the pendings this morning

[08:59:09.0976] <Michael Ficarra>
Rebased https://github.com/tc39/ecma262/pull/3602

[08:59:41.0048] <Michael Ficarra>
@ljharb:matrix.org Also, don't forget to backport https://github.com/tc39/ecma262/pull/3793 to the 2026 branch

[09:00:42.0369] <ljharb>
is that the only one i should backport? i could pull in all the editorials that have landed since

[10:14:03.0049] <Michael Ficarra>
no I don't think that's necessary

[10:47:12.0397] <ljharb>
it's certainly not necessary :-) but is there any reason not to?

[10:47:43.0596] <ljharb>
(until the last year or two, we always pulled everything non-normative in whenever making any updates to RCs)

[10:52:53.0252] <ljharb>
i feel like our "living standard" position should prefer minimal diff between a snapshot and the spec

[11:28:31.0489] <Michael Ficarra>
given the sensitivity of the whole patent opt-out thing, I'd personally not want to include anything that we don't absolutely have to

[11:28:59.0539] <Michael Ficarra>
if we find a terrible bug that was introduced between 2025 and 2026, sure, but otherwise I wouldn't backport anything

[11:43:53.0861] <ljharb>
why is that sensitive? it only applies to normative things and it's been largely a formality for decades

[12:46:21.0806] <Michael Ficarra>
it's sensitive IMO because it's associated with a legal obligation, and I like to keep those as uncomplicated as possible

[12:46:53.0104] <Michael Ficarra>
there's just no reason to include anything *unless* it's a last-minute normative change, and only to avoid introducing a bug that didn't exist in a previous edition

[12:57:04.0469] <Michael Ficarra>
we should use more named records

[12:57:18.0513] <Michael Ficarra>
there's no reason that FinalizationRegistry cells are anonymous records

[13:04:44.0194] <ljharb>
i understand the argument, but it's been done for dozens of years and it's never caused as much as a mention ¯\\\_(ツ)_/¯ 

[13:07:12.0833] <Michael Ficarra>
I'm aware that I am especially risk averse when it comes to those things

[13:18:39.0591] <Michael Ficarra>
https://github.com/tc39/ecma262/pull/3806 is one I would consider backporting if it wasn't already broken in the 2025 release


2026-04-15
[00:49:08.0024] <Michael Ficarra>
FYI I won't be able to attend this week's editor call as I'll be in the middle of boarding a plane. If you need anything from me, just message me here and I'll get to it when I land.


2026-04-16
[08:02:10.0091] <nicolo-ribaudo>
Richard Gibson meeting time :)

[12:11:50.0245] <rbuckton>
nicolo-ribaudo: since you asked earlier, I took a closer look and there is no semantic difference between `ContainsUsing` and `HasUnterminatedUsingDeclaration`. I'm fine with dropping the latter in favor of the former as it's a better name and easier to read.

[15:41:50.0645] <Michael Ficarra>
I just realised that if we break the spec into multiple documents (such as with Temporal), we're going to have to figure out how to get that to work with esmeta

[15:42:11.0547] <Michael Ficarra>
or possibly ask the esmeta maintainers to add support

[15:43:36.0894] <Richard Gibson>
that could be as simple as making the single file generated code rather than the source of truth


2026-04-17
[17:33:45.0367] <ljharb>
i thought we decided not to do that

[17:35:05.0603] <jmdyck>
decided not to break the spec into multiple documents, or decided not to generate a single file?

[18:00:55.0335] <Michael Ficarra>
@ljharb:matrix.org We did not decide whether they would be separate source files.

[18:01:49.0822] <jmdyck>
so when's that going to be decided

[18:02:46.0492] <jmdyck>
because I'll have to change ecmaspeak if it's multiple files

[18:08:45.0084] <ljharb>
i thought we did - it wasn’t just about the built representation that we discussed, we also talked about the source files.

[18:09:25.0616] <ljharb>
(I assume a ton of tools will need to adapt if the source files are split - i have a few too)

[01:35:43.0717] <nicolo-ribaudo>
I had understood that the previous editors group already decided that Temporal would be merged as separate files

[07:18:16.0728] <Michael Ficarra>
We definitely *wanted* to, but it wasn't a "decision" because we may run into issues like the ones we've all been pointing out 

[16:02:40.0960] <ljharb>
i also continue to maintain that something that big isn't the sole purview of the editor's group


2026-04-18
[20:57:00.0673] <Michael Ficarra>
I couldn't imagine anything that would be more within the realm of editorial discretion


2026-04-20
[08:03:12.0811] <Chris de Almeida>
if the change is purely internal to the editors, then it seems well within the bounds of editorial discretion.  if it affects how others will interact with the spec, then that seems at least close to the boundary of editorial discretion

[12:48:16.0158] <ljharb>
as far as i'm aware, every group's discretion only holds until the broader committee has an objection to it, including the chair group and CoC group

[14:41:49.0034] <Michael Ficarra>
that is correct

[15:25:08.0805] <Chris de Almeida>
agreed.  and I did not mean to imply that groups with delegated authority can do whatever they want so long as they are operating within their scope.  issues raised should be discussed and addressed


2026-04-23
[01:49:04.0836] <nicolo-ribaudo>
shu Do you want to review https://github.com/tc39/ecma262/pull/3806?


2026-04-24
[10:37:05.0505] <ljharb>
the mutex doesn't seem to be working (for the preview builds(

[10:37:09.0633] <ljharb>
* the mutex doesn't seem to be working (for the preview builds)

[10:45:11.0457] <Michael Ficarra>
I wish there was a good way to test it without creating a bunch of noise

[10:45:17.0156] <Michael Ficarra>
I guess we could make a separate repo

[10:51:17.0683] <bakkot>
what is this operation https://tc39.es/ecma262/multipage/executable-code-and-execution-contexts.html#sec-module-environment-records-getbindingvalue-n-s

[10:51:29.0270] <bakkot>
> 3. If the binding for name is an indirect binding, then
>    a. Let module and targetName be the indirection values provided when this binding for name was created.


[10:52:52.0139] <nicolo-ribaudo>
Yeah, how we do live bindings for imports is... something 😅

[10:53:28.0952] <bakkot>
I guess this is https://github.com/tc39/ecma262/pull/2288

[10:58:11.0313] <Michael Ficarra>
yes, I've been trying to get eyes on that PR for forever

[10:58:16.0624] <Michael Ficarra>
looks like we'll finally be getting to it soon

[10:59:49.0268] <Michael Ficarra>
FYI I've moved all issues on the ecma262 "project" below all PRs, since I figure we should always get to high-priority work that has already been done before high-priority work that is yet to be done


2026-04-25
[18:01:38.0445] <Michael Ficarra>
Good name for an alias of type `property key or Private Name`? `propertyName`?

[19:49:35.0953] <Richard Gibson>
I might use just _key_. _propertyName_ is more like https://tc39.es/ecma262/multipage/ecmascript-data-types-and-values.html#property-name , which implies **exclusion** of symbols and private names.

[20:04:12.0440] <Michael Ficarra>
I just remembered that we need to include recent ecmarkup improvements (https://github.com/tc39/ecmarkup/releases/tag/v24.1.0) in our editor update slides for the next plenary

[20:04:19.0890] <Michael Ficarra>
let's collectively try not to forget to do that

[20:08:20.0578] <Michael Ficarra>
it looks like we actually already have quite a bit of precedent for just using `name` for this

[20:53:14.0070] <Michael Ficarra>
I screwed up and briefly pushed a commit to main again, but then force-pushed it off as quickly as I could

[20:53:31.0586] <Michael Ficarra>
I wish we had a way to prevent that from happening...

[00:18:37.0853] <nicolo-ribaudo>
You can locally set a different pull and push URL for your "upstream" remote

[00:19:00.0477] <nicolo-ribaudo>
Putting something invalid for pushing

[03:34:22.0785] <Michael Ficarra>
only for the main branch?

[03:37:39.0884] <Michael Ficarra>
my problem is that I usually create a branch before starting to work, but sometimes I just start to work on main and then forget to create a branch when I'm done, hurry to get things pushed because I've gotta leave or something, then accidentally push to main and it just allows it, no questions asked

[03:51:55.0849] <nicolo-ribaudo>
1. create a new remote that only allows pulling: `git remote add upstream-pull-only https://github.com/tc39/ecma262.git && git remote set-url --push upstream-pull-only cannot-push`
2. fetch the main branch from it: `git fetch upstream-pull-only main`
3. make your local `main` branch use that remote: `git checkout main && git branch --set-upstream-to=upstream-pull-only/main`

[14:05:36.0869] <ljharb>
just delete your main branch entirely, you don't need it

[14:05:45.0552] <ljharb>
when you want to make a new one, `git checkout origin/main` and go from there

[15:11:14.0643] <Michael Ficarra>
that's also not a bad suggestion

[15:12:12.0963] <Michael Ficarra>
so if I accidentally do work in the detached head state, it wouldn't work if I try to push without naming a branch

[15:23:25.0978] <ljharb>
correct


2026-04-27
[10:54:31.0672] <jmdyck>
There's an editor call in ~3 hours?

[11:00:48.0040] <Michael Ficarra>
yes

[14:57:13.0403] <Michael Ficarra>
@ljharb:matrix.org Can you move the May 25th editor call (US Memorial Day) to June 1st?

[14:58:10.0359] <ljharb>
done


2026-04-28
[18:56:28.0608] <jmdyck>
https://github.com/tc39/ecma262/pull/3839 is the quick fix


2026-04-29
[12:23:49.0879] <jmdyck>
In https://tc39.es/ecma262/#sec-serializejsonproperty, step 11.b.i (from PR #3826) is "Assert: value is an Array. value is not a Proxy." This is odd for a couple reasons: (a) It's odd to have an Assert followed by two separate assertions. (Normally we'd connect them with "and" or make them to separate Asserts.) Note that esmeta is also confused by this construction. (b) Once you assert that value is an Array, then by definition it's not a Proxy.

[12:24:05.0719] <jmdyck>
(That step wasn't there when I reviewed the PR.)

[12:58:31.0587] <Richard Gibson>
it's from https://github.com/tc39/ecma262/pull/3826 , and I don't see a review from you there at all

[13:27:12.0335] <bakkot>
I also don't believe that assertion

[13:29:01.0887] <bakkot>
`value` starts out as an arbitrary ES value (just a Get on a user-supplied object, or the return of a user-supplied `toJSON` or reviver), and none of the subsequent narrowings rule out a Proxy

[13:46:50.0573] <Richard Gibson>
yeah, good point. That assertion fails for e.g. `JSON.stringify(new Proxy([], {}))`

[14:26:33.0320] <jmdyck>
I ran it through ecmaspeak, but didn't have any comments.

[15:02:21.0176] <ljharb>
isn't a proxy for an array also an array? meaning you'd need both assertions to rule out a proxied array

[15:03:32.0385] <jmdyck>
a proxy for an array satisfies "IsArray", but it doesn't satisfy "is an Array"


2026-04-30
[22:27:03.0908] <ljharb>
i suppose that's true, it's "an Array exotic object" and that's not what a Proxy is

[06:03:53.0927] <jmdyck>
editor call in 2 hours?

[07:28:07.0979] <Michael Ficarra>
yes

[08:05:11.0283] <nicolo-ribaudo>
linus Richard Gibson both busy?

[08:31:57.0188] <linus>
skipping today due to 🤧

[09:47:10.0966] <Michael Ficarra>
FYI we decided at editor call today to prioritise the ERM PR over the Temporal PR

[12:47:47.0705] <jmdyck>
PR #3000?

[12:58:57.0439] <Michael Ficarra>
correct, #3000 before #3759