2024-03-12 [00:10:22.0604] Can I suggest a policy of not force-pushing to branches people are working on, even just force-pushing to rebase? I'm used to the convention of clicking the "update with merge commit" button, which makes it much more obvious what's happened when one's local branch is out of date. [10:28:32.0002] Igalia has an all hands next week during the maintainers meeting. how would people feel about moving it to the following week? 2024-03-13 [23:24:35.0928] > <@bakkot:matrix.org> Can I suggest a policy of not force-pushing to branches people are working on, even just force-pushing to rebase? I'm used to the convention of clicking the "update with merge commit" button, which makes it much more obvious what's happened when one's local branch is out of date. happy to hear the other maintainer's thoughts, but the convention on github is pretty commonly that force pushes are expected [23:27:07.0543] I have never had anyone else force push to a branch I was working on prior to me saying the branch was ready to merge, so I don't this this convention is that widespread [23:28:21.0321] everyone else just pushes new commits, which means if they want to run CI with the branch updated to main they click the "update with merge commit" button [23:28:31.0947] * I have never had anyone else force push to a branch I was working on prior to me saying the branch was ready to merge, so I don't think this convention is that widespread [00:43:23.0793] if it's not a draft PR then it's potentially ready to merge; that's what the "draft" semantic is for [08:53:53.0076] yeah, I do force-pushes on PRs all the time. I don't know whether it's the convention, maybe I'm weird 😅 [08:55:57.0867] in my defense, I work on a lot of repos where most contributors have less time/motivation to be involved than me, and are often not immediately on top of following up with the PRs that they send. so when I force-push, that seems like a kindness because it saves them the trouble of rebasing [09:00:30.0534] update with merge commit, on the other hand, I'm not a fan of - it's fine if your working style is to consistently do one commit per PR, because you can always 'squash and merge' when it comes time to merge the PR. but in test262 we get both 'squash everything' PRs and 'each commit is a carefully curated logical unit' PRs. update with merge commit makes the latter harder to preserve [09:10:59.0924] > <@ljharb:matrix.org> if it's not a draft PR then it's potentially ready to merge; that's what the "draft" semantic is for If there are outstanding requests for changes from maintainers then it is not potentially ready to merge [09:11:42.0431] unless the maintainers are making those changes themselves and then immediately approving and merging, in which case I have no objections to force-pushing as part of the process [09:15:38.0332] we could maybe render some of this moot by not requiring that PRs have to be fast-forwardable to be mergeable (but still require that when they are actually merged, they are rebased and fast-forwarded). github can do this. that way, no one would have to force-push unless there were actually merge conflicts, which rarely happens because of the nature of test262 [09:34:15.0232] > <@bakkot:matrix.org> If there are outstanding requests for changes from maintainers then it is not potentially ready to merge true, fair [09:35:40.0935] but in general, i'm surprised you've never had this happen, because i've had it happen to me dozens of times and i've done it to others many hundreds of times. and in this case it wasn't even a real force push, i just clicked the clickable "rebase branch" button in the UI. so tbh i think that if you aren't expecting someone to click one of the buttons in the web ui then on some level you may need to adjust your expectations? [09:50:39.0236] I mean, the "land PR with a merge commit" button also exists in the web ui [09:50:57.0427] the presence of a button in the web UI does not indicate it is always or indeed ever reasonable to press that button [09:51:31.0191] and while I wouldn't say I _expect_ people not to click the "land with merge commit" one, I do try to convince maintainers not to press it on projects I contribute to, since it is a bad experience for contributors [09:51:53.0799] this is also how I feel about the "update with rebase" button when a branch is actively being worked on 2024-03-21 [17:10:46.0220] > <@pchimento:igalia.com> Igalia has an all hands next week during the maintainers meeting. how would people feel about moving it to the following week? so, we didn't have the maintainers meeting today, but how do people feel about having it next week? [22:39:05.0733] i missed today anyways. i'm fine doing it next week 2024-03-25 [16:57:56.0978] that sounds like 2 in favour, 0 against maintainers meeting on this coming Wednesday 27th 😄 ljharb I believe you have the keys to the calendar event? 2024-03-26 [17:03:48.0257] ah yes thanks, will move it shortly 2024-03-27 [08:08:18.0312] I got a notification of the update; I'm not available to meet today [08:34:41.0973] bakkot: we want to land https://github.com/tc39/test262/pull/3994, can you let us know when it's ready? [09:26:55.0755] ljharb: go for it [09:27:05.0295] there's more tests to write but those can be in a followup [09:27:12.0377] and I believe everything there is good [09:30:38.0438] great thanks, will do 2024-03-29 [01:14:34.0842] Hi, I'am wondering how do I know to right the Map code like the "code_of_Map.png" according to spec_of_Map.png [01:17:12.0788] My further question is how can I write the corresponding demo code that they can work based on the spec? Any suggesion would be appreciated, thanks in advance. [07:57:06.0521] dpu: are you asking about checking what your code is supposed to do by reading the spec? when I do that, I like to make a note of each line in the spec and write down what the value is of each variable 2024-03-30 [19:12:38.0645] ptomato Thanks for reply. I am not ask for checking, I ask for how to write the right code. For example, how can a newbie write correct code after reading the [Map](https://262.ecma-international.org/14.0/?_gl=1*14njui1*_ga*MTc3Mzc4NjY1NS4xNzExNjk1OTk0*_ga_TDCK4DWEPP*MTcxMTY5NTk5NC4xLjEuMTcxMTY5NjQyMi4wLjAuMA..#sec-map-constructor) part of spec? Why the Map initialization exactly like the code_of_Map.png, not like the code_of_Map2.png [19:13:51.0443] The code_of_Map.png is the first png I send, code_of_Map2.png is the sedcond.