2022-06-02 [13:12:55.0776] @bakkot: done. [15:05:16.0310] jmdyck: thanks! gonna hold off on merging until after this meeting, I think, since we have a few regex proposals up at this meeting and they're written as diffs against the existing spec [15:05:27.0156] but will land after that, and get the proposals rebased [15:45:14.0804] ok 2022-06-07 [18:27:05.0306] anyone care to stamp https://github.com/tc39/ecma262/pull/2793? basically just check the preview to confirm the changes to user code for the promise machinery look right [09:27:00.0660] what was changed in 12.1.1 to change the UC propagation? [09:27:19.0182] https://github.com/tc39/ecmarkup/pull/455 [09:27:57.0985] ah ha [09:28:43.0171] stamped 2022-06-16 [17:24:22.0319] oops, totally forgot about the meeting. [13:31:38.0482] For a merge-to-main, is it possible for there to be one commit on the main branch, but multiple contributing commits still in the PR? (So that the main branch stays 'uncluttered', but if an archeologist wants to investigate/understand something, the detailed commits + commit messages are still available in the PR.) 2022-06-17 [17:36:29.0680] in theory, yes - that's what "squash and merge" does. but ljharb has a strong preference for force-pushing the PR branch to have exactly the commits which are going to land, for reasons I am now forgetting. [17:55:45.0377] Because the PR ref remains forever, and because if it deserves to be a separate commit in the PR, it deserves to be one in main. [19:47:21.0281] I disagree. I think it's useful to have different levels of commit granularity in main vs PR. [19:48:07.0239] (or at least, different levels of commit granularity available _some_where, and I'm not sure where that would be other than the PR) [19:48:50.0708] * (or at least, different levels of commit granularity available _some_where, and I'm not sure where that would be other than the PR) [20:20:12.0181] Moreover, "deserves" according to whom? *I* determine what deserves to be a separate commit in my PRs. Are you saying that my choices for the PR should determine what constitutes a commit for main? If so, there will be a lot more fine-grained commits in main, which (a) is probably not what the editors want, and (b) is probably not even what I want *in main*. [12:48:11.0657] E.g., re https://github.com/tc39/ecma262/pull/2716, I'd be fine with that being a single commit on main, because that seems like the appropriate level of detail for most people going through main's history. But if someone is interested in that particular commit (e.g., because they don't understand something, or find a possible bug), then I think it could be helpful to have the PR decompose that commit into a series of smaller commits, with more focused commit messages. (Not the 13 that are there now, but a tidied-up set of 6.) 2022-06-18 [08:09:27.0529] generally, git commits are supposed to be atomic, and often, PRs are also intended to be a single atomic change. If you want to combine multiples in a single PR instead of splitting them into a separate one, then presumably that's because it's more reviewable that way. Review needs to happen in the infinite future as well, and while git commits last forever, github won't. [08:09:52.0784] ecma is very concerned with long-term archival, so anything that's not stored in actual git won't meet that bar [08:10:06.0830] * ecma is very concerned with long-term archival, so anything that's not stored in actual git won't necessarily meet that bar (altho they do try to scrape github occasionally) [08:12:01.0008] (separately, typically repo maintainers, not PR authors, ultimately decide how to group commits on a PR - 262 is a special case in a number of ways tho, ofc) [08:31:50.0130] ljharb re: archival, don't pr refs remain forever? [08:32:19.0144] in github [08:32:32.0698] in the git repo on github, I mean [08:32:35.0185] and in local repos that opt in to downloading them. but you're right that would be a path. [08:33:15.0649] If ecma is very concerned about long-term archival, they should be scraping TC39's repos thoroughly, so that the possibility of github disappearing does not pose a loss-of-archive threat. In which case, TC39 should be able to treat its github repos as archival. And so infinite review of PR-only commits should be possible. [08:40:56.0089] (Also, by "atomic", I assume you don't mean it in the DB sense (git takes care of that), but rather in the sense of leaving the repo (spec) in a valid/consistent/reasonable state.) [10:52:11.0908] i mean it in the conceptual sense, yes [10:53:19.0481] it's actually a common view that a PR should only *be* a single conceptual change - i don't subscribe to that philosophy personally, and i'm fine with PRs containing multiple conceptual changes (ie, commits), which is why i don't indiscriminately squash PRs down to one commit (which i think is destructive) [12:09:49.0495] My point is that even when you have a PR that *is* a single conceptual change, it can still be useful to view it as a set of smaller conceptual changes. I'm disagreeing with the idea that (in any given case) there's only one level-of-detail that's deserving of archiving. 2022-06-21 [10:50:12.0877] > To make the story short it looks like that for the ES2022 standards Allen Wirfs-Brock will prepare the PDF versions. It will take for Allen about one week after the final html versions are available from the Editors. It will be a nice "PDF" format, but a "one time" solution for 2022. For a solution for 2023 and beyond we suggest to have a follow up project. Allen is proposing a nice strategy for that, that we have to present it in more details and agree on it. But that is for later. Until June 2023 there is still one year to go... [10:50:23.0653] I wish they would've just let us solve this problem for them... [10:53:13.0108] i am okay with a world where we just do nothing about and have no consideration for the pdf version [10:53:23.0655] whatever anyone else wants to do, good luck, but no support from us [10:57:02.0512] if it continues to be that way in perpetuity, fine, but I hate kicking the can down the road if it's going to come back to us some day [10:57:17.0569] agreed [10:58:20.0174] did not realize Allen was even remotely involved anymore [10:58:45.0043] Allen is responsible for our archival processes I believe? [13:28:17.0602] lol (－‸ლ) at this solution, but k 2022-06-22 [14:32:00.0488] shu ljharb editor call? [14:32:33.0909] running late, be there in 2 2022-06-29 [16:02:39.0134] bakkot: before i file the devtools issue about not autocompleting deprecated methods, do you consider *all* methods currently in Annex B to be legacy? [16:16:54.0969] (like, i know Annex B says that, but that doesn't necessarily reflect reality) 2022-06-30 [20:32:57.0419] shu: yes [20:34:03.0027] it's just the stupid HTML string methods `substr`, `escape`, `unescape`, the 1900-based `Date.setYear`/`Date.getYear`, and `RegExp.compile` [20:34:07.0692] no one should ever use any of those [20:35:41.0643] there's also `.__proto__` and `__lookupGetter__` and friends, which are not annex B but are "Legacy", but it's kind of reasonable to use those in the console as an easier alternative to doing the right thing [20:35:52.0979] as long as you don't ship them to prod [20:36:05.0057] but even that excuse does not apply to the string methods and `getYear` and so on [20:36:48.0523] * it's just the stupid HTML string methods, `substr`, `escape`, `unescape`, the 1900-based `Date.setYear`/`Date.getYear`, `Date.toGMTString` which is just an alias for `Date.toUTCString`, and `RegExp.compile` [09:50:29.0056] how do i know what year it is otherwise