| 00:39 | <Domenic> | Now getting CSSWG internal server errors... yeah, I think we should resurrect the run-it-ourselves PRs |
| 00:42 | <Jeffrey Yasskin> | I've bugged plinss. It was broken yesterday too. |
| 00:44 | <Jeffrey Yasskin> | +1 for getting this onto a server that a whole team is responsible for. It doesn't make sense to rely on 1 person. |
| 00:56 | <Jeffrey Yasskin> | See also https://w3ccommunity.slack.com/archives/C010CACSKAL/p1704934117327259 |
| 05:59 | <sideshowbarker> | As far as W3C hosting any replacement for https://api.csswg.org/bikeshed/, I think that’s extremely unlikely to happen. If anybody wants to know why in more detail, I can explain more. But regardless, even if W3C were to host it, that wouldn’t solve the problem of spreading out the maintenance responsibilities among a wider part of the community — because the way that W3C normally does hosting would necessarily limit shell access to the server environment to W3C staff only (or even specifically just to W3C systems-team staff). |
| 07:38 | <annevk> | I think the problem is more that the whole setup is somewhat opaque without any visibility into the code or ways to report issues in a transparent manner. Not that there's no shell access. |
| 07:52 | <sideshowbarker> | So maybe rather than trying to set up community hosting for the existing code that none of us know anything about or have ever actually even seen or contributed anyway, it might be better to build something from scratch based on the requirements |
| 07:56 | <annevk> | Yeah, I think for now WHATWG will just install it on GitHub CI per Domenic's work. If at some point a centralized solution exists we feel comfortable with we could switch back to that. Although Domenic's back-of-the-envelope math suggests it might not be worth the effort. |
| 10:16 | <annevk> | foolip: in case you don't get GitHub pings: https://github.com/whatwg/spec-factory/pull/68 |
| 10:17 | <foolip> | annevk: I do, just too many :) |
| 10:17 | <annevk> | Hah, I'm familiar with that problem |
| 14:51 | <canadahonk> | If a relative websocket URL is used in a worker, should it be relative to the worker or the document URL? |
| 15:30 | <annevk> | canadahonk: the worker; it's the same as any other URL |
| 15:48 | <annevk> | Hmm, I regret answering. If you're still there, what made you ask that? |
| 16:24 | <Ms2ger (back in 2024 W2)> | annevk: 🎏 |