| 00:13 | <shu> | ljharb: okay, initial spec for transfer up at https://tc39.es/proposal-arraybuffer-transfer/ if you'd like to review |
| 00:18 | <shu> | huh i wonder why it says January 11, what timezone is GH on |
| 00:19 | <Andreu Botella> | probably UTC |
| 05:18 | <ljharb> | yeah, it's utc, it's really annoying |
| 05:19 | <ljharb> | there's an env var kevin added to ecmarkup that lets you set the modified time, but unfortunately i haven't worked out an ergonomic way to use it so that the date is deterministic :-/ |
| 06:11 | <bakkot> | well |
| 06:11 | <bakkot> | it's easy to make it deterministically 1970-01-01 or whatever |
| 06:12 | <ljharb> | lol ok well, deterministic and increasing as time itself increases :-p |
| 06:12 | <bakkot> | but deterministically "date of last file modification" is trickier yes |
| 06:14 | <bakkot> | for CI it's probably fine to have it do the commit date |
| 06:14 | <bakkot> | if you want it to be deterministic and increasing |
| 16:01 | <ljharb> | that date isn’t known until after the committed build is generated tho |
| 16:58 | <bakkot> | if you commit changes to the spec and then CI generates a separate commit with the build for that spec, CI can use the date of the "changes to the spec" commit to generate the date for the build |
| 17:00 | <ryzokuken> | that would help with the "CI rebuilds spec and causes merge conflicts" issue |
| 17:00 | <ryzokuken> | because the default template has this really irritating issue |
| 17:01 | <ryzokuken> | GH actions tries to rebuild the spec everytime, even if the commit already updates the built spec and adds fixup commits that need to be addressed but at the very least would cause merge conflicts |
| 17:01 | <ryzokuken> | so it's pretty much impossible to merge multiple PRs in a row. You have to always rebase all PRs on top of the main branch once you merge anything, it's quite irritating at times. |
| 17:05 | <bakkot> | ryzokuken: that's already fixed by https://github.com/tc39/template-for-proposals/pull/32, which puts the built spec on its own branch |
| 17:05 | <ryzokuken> | oh nice |
| 17:06 | <ryzokuken> | how can I incorporate this into an existing proposal repo? |
| 17:07 | <bakkot> | uhhh basically just apply that PR as a patch |
| 17:07 | <ryzokuken> | ah cool! Wasn't sure that'd just work. Will try this and let you know how it went |
| 17:07 | <bakkot> | and then change the repo settings to deploy from the gh-pages branch once the new CI runs and generates it |