| 01:04 | <krosylight|out-until-Jan-6> | https://github.com/whatwg/streams/pull/1145 would be helpful for that, as it would aggregate the 8-byte and 4-byte chunks for you |
| 09:26 | <mztea9281> | That’s alot |
| 09:27 | <annevk> | Yeah, kinda weird that it's a download. Anyway, I wish we had ways to prevent PRs from getting to that point. |
| 09:42 | <annevk> | Automatic formatting might go a long way. |
| 09:43 | <sideshowbarker> | Some kind of heads-up bot/automation is imaginable: When a PR reaches some configured threshold of number of comments (or rate of comments during a day or week), the bot comments with an alert saying, "This PR has accumulated a lot of comments" |
| 09:44 | <sideshowbarker> | ...and then you could step back and reconsider if there's some change that could be made so that it doesn't end up accumulating even more |
| 10:02 | <annevk> | Well, this isn't a heated discussion. It's the popover PR and as far as I can tell it's all constructive. It's just a big change with a lot of details to get right. Perhaps though we need something similar to TC39's staging process for bigger changes? |
| 10:39 | <sideshowbarker> | Maybe so — but in general, it seems like when a PR has that many review changes, it has probably also been open for quite a long time, and if so, then you run into the technical problems of merge conflicts, and also the problem that the PR author and reviewers just get fatigued with it all |
| 10:40 | <sideshowbarker> | so sometimes I guess it can be an opportunity to step back and consider doing some kind of course correction — breaking it into smaller commits if possible, or whatever |
| 10:42 | <sideshowbarker> | but all that said, I know well that for some of the HTML PRs, it’s kind of unavoidable — because it’s necessary to touch a lot of places in the spec, and the relationships between the different parts can be complex |
| 11:06 | <moekhar khar> | hi |
| 12:02 | <jgraham> | Well another problem is ecossytem breakage. For example all the navigation changes in HTML have totally broken WebDriver so the spec won't even build because there were breaking changes in the "API surface" of the HTML spec. And on the one hand, I get it that we want to make these changes and "just let the rest of the ecosystem deal with the fallout" is probably the only practical way to get it landed at all, but on the other hand you wouldn't get away with that kind of thing in a software project. |
| 12:08 | <jgraham> | I think my point, such as it is, is that because it's nonsense to "pin" an older version of a spec, the full set of web specs is essentially a (structured) monolith. But we treat them like they're independent "libraries" because we don't have the tooling required to handle the non-local impact of changes upfront. |
| 12:47 | <Ms2ger 💉💉💉> | Well another problem is ecossytem breakage. For example all the navigation changes in HTML have totally broken WebDriver so the spec won't even build because there were breaking changes in the "API surface" of the HTML spec. And on the one hand, I get it that we want to make these changes and "just let the rest of the ecosystem deal with the fallout" is probably the only practical way to get it landed at all, but on the other hand you wouldn't get away with that kind of thing in a software project. |
| 12:58 | <jgraham> | Well that's fair. But I was thinking more about what you'd get away with in like a web browser where "sorry we updated the DOM internals so now the browser doesn't build" wouldn't fly. Or at an even bigger scale, something like the Google monorepo where you can't just check in breaking changes, but there's a lot of tooling support to make larger refactorings possible. |
| 13:07 | <annevk> | jgraham: we tend to patch downstream proactively. Perhaps https://dontcallmedom.github.io/webdex/ wasn't used enough for the navigation changes, but I would expect people to try and do some due diligence on that front. |
| 13:10 | <Ms2ger 💉💉💉> | Would be interesting to have tooling that surfaces which definitions disappear in a given PR - I guess there were plenty in the navigation pr |
| 13:23 | <annevk> | Useful output diffs would help with that as well. It's one of the downsides of only checking in the source. But yeah, disappearing IDs are one of the other things people tend to overlook. |
| 13:26 | <jgraham> | Well ultimately the way you handle this is for changes to a lib/API/spec to build all consumers of that in CI, so you can see breakage directly. But we're far away from having that kind of tooling. |
| 14:12 | <annevk> | Domenic: if you could give https://github.com/whatwg/html/pull/8496 another look tomorrow or so to validate the approach that would be appreciated; turns out "reflect" does a lot of heavy lifting, though we might be able to improve that over time |