[21:00:51] #startmeeting RFC meeting [21:00:52] Meeting started Wed Apr 3 21:00:51 2019 UTC and is due to finish in 60 minutes. The chair is KateChapman. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:00:52] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:00:52] The meeting name has been set to 'rfc_meeting' [21:01:08] #topic RFC: Skin templating https://phabricator.wikimedia.org/T217158 [21:01:20] hi all, who is here to talk skin templating? [21:01:50] * tgr is lurking [21:03:22] we have one lurker so far [21:05:35] Isarra: you here? [21:05:46] * milimetric also lurking [21:06:10] * RoanKattouw lurks [21:06:42] * duesen_ skulks [21:07:13] Hi, right, yes. [21:07:23] Hey :) [21:07:41] KateChapman: did you hear anything from Skizzerz? [21:07:58] I did not [21:08:07] I prodded the others... [21:10:32] Hm, looks like there is nobody here to actually drive the discussion [21:11:04] Maybe I can try to summarize the questions that came up when we discussed this in the techcom meeting earlier [21:11:14] I think that sounds like a good idea [21:11:39] Actually, er, this is an hour early? [21:11:47] I missed up the timezones [21:12:15] messed up the timezones. so it is right on time for 2 and 1 hour early for the other [21:12:16] Ah. [21:12:22] apparently the UTC time was wrong, the Californian and European times were correct. [21:12:24] correct? [21:12:31] The european time is also wrong, then. [21:12:57] They're on CEST now, but 23 matches what CET would be. [21:13:03] For... [21:13:09] Gods, I'm too out of it to explain this. [21:13:26] I know better, I just had a moment of assuming I knew better when I types the times up [21:13:41] anyway, we're here now, so might as well not waste time talking about time :) [21:13:49] Isarra: it'S 23:13 here, the meeting was announced for 23:00 [21:13:54] so that's fine [21:14:09] hey Skizzerz [21:14:13] duesen_ if you could recap what techcom discussed earlier that would be a useful launching point I think [21:14:30] I could then answer any questions, give more insight into why I wrote what I wrote, etc. [21:14:51] there's actually quite a few angles and questions, but the big one is really: WHY? [21:14:55] to expand that a little... [21:15:00] I'm glad that Isarra was able to make it as well, as she has a lot of experience with the current skinning system and therefore knows its pain points as well as places where the proposal may fall short [21:15:14] it seems like it'S already possible to write a skin that behaves as proposed, with no (or very little) modification to core [21:15:22] Why? Because the current skin system is so god-awful that it takes a PhD to make sense of it and write a sane skin [21:15:30] porting existing skins to the proposed system would however be pretty time consuming [21:15:36] and resulting in tons of copy/paste for no good reason [21:16:00] it's also unclear whether we'd want to proposed capability, namely modifying mustache templates that drive skins on-wiki, for wikimedia sites [21:16:26] Okay, I'm going to get some food and come back, because I am way too out of it right now. [21:16:28] Ok. I want to make a skin based on vector, but adding in a right sidebar to host some other content (or perhaps ads) there [21:16:32] So... the main point is ease of writing a new skin [21:16:33] ? [21:16:45] that'S very different from letting people on-wiki modify skins [21:16:47] Right now I need to duplicate the entirety of vector, tweak the one thing I care about, and have to now bother with making sure I take in all of upstream's changes [21:16:49] it shouldn't be that hard [21:16:56] this has nothing to do with on-wiki skin modification [21:16:59] this RFC* [21:17:22] The one described on the wiki does [21:17:27] where? [21:17:32] should these parts be removed/ignored? [21:17:59] are we not talking about https://www.mediawiki.org/wiki/Requests_for_comment/Skin_templating ? [21:18:04] possibly rewritten to be more clear, since being able to modify the skin on-wiki is not a design goal [21:18:08] Krinkle: we are [21:18:11] "As a wiki user, I want to: Customise a skin to modify its appearance or otherwise add or remove functionality, either" for only myself or for everyone on the wiki, for varied reasons. [21:18:25] ah [21:18:52] I answered that with "Wiki users are adequately served by the existing system, and will continue to be adequately served by the new system, as the customisation points in Special:Preferences and sitewide and user css/js pages will remain as-is for this proposal. " [21:18:53] with a wild west approach to skins, if you try to make skins based on other skins ("themes"), either they will be unmaintainable because upstream will break the all the time, or upstream will try to avoid breaking child skins and become unmodifiable [21:19:00] Skizzerz: As I understand it, the base classes in MediaWiki core offer a complete valid HTML representation of all information the skin is capable of presenting by default. The show case FallbackSkin being an example of how minimal a skin can be. And how little duplication there needs to be. [21:19:00] Also maybe the use of "System administrator" is confusing? Is that an on-wiki admin, or the wiki owner with shell access? [21:19:07] tl;dr that line was referring to existing customization points with User:Myuser/skinname.css [21:19:32] system administrator is a wiki owner with shell access [21:19:55] to avoid that, you need a contract between parent and child skins, and it's not really reasonable to expect each parent skin to figure it out on its own [21:20:13] Skizzerz: ok, thanks for clarifying. [21:20:15] Skizzerz: Creating a derivative of Vector in particular (if anyone wants that) is something that could be achieve by using a PHP sub class. We do not currently have a trend of sub-skins like WordPress, but that's certainly something that could be discussed. In any event, MediaWiki is currently agnostic to that. It would be a feature for Vector, and any other skin to support that, not core. [21:20:21] The RFC still calls for "A special page on the wiki which lets privileged users modify templates." [21:20:47] tgr: "theme" has traditionally meant just a bunch of CSS mods on top of an existing skin CSS ;) "child skins", which I believe is a concept in WordPress (where "themes" means what "skins" means in the MW world), hasn't really been a thing in the MW world; some skins use(d) to extend other skins' templates but I think most skins are pretty stand-alone these days, even the ugly and outdated Vector forks (most of which should've been themes [21:20:47] to begin with!) [21:20:50] so I suppose that option is off the table? [21:20:54] right. So core would ship a base DOM (with no or very minimal css/js) -- this would be the new "Fallback" skin. Monobook, vector, etc. would inherit from that and add in their uniqueness [21:21:14] duesen_: We should probably take it off the table for this RFC, to avoid throwing too many features into the mix [21:21:31] something like that can be served with an extension as well [21:21:39] ashley: CSS mods are also unmaintainable without a contract [21:22:03] Yes, I agree. If we take on-wiki customization ouot, and focus on mustache based templates with a sane way top subclass. [21:22:22] In my hypothetical example where I want to add a right sidebar to vector, I can inherit from vector and modify *just* the template where it defines the layout of the sidebars/page content, to inject my sidebar. As well as whatever CSS may be necessary [21:22:23] ...that would make the RFC discussion more focused [21:22:40] indeed, the lack of standardization and whatnot has been somewhat of an issue and things do randomly like to break for whatever reason(s) [21:23:36] but introducing a standardized DOM now would break everything that is builtfor the old DOM of existing skins [21:23:41] tgr: my goal is that the extensibility features that this would expose allow us to handle forward changes in a clean fashion; either making things just work(tm), or when we do need to break the contract, it breaks in a way that's easy for child skins to keep up with as opposed to them having to restart from scratch [21:24:38] Skizzerz: Is this primarily to enable something new that is currently not technically feasible, or to make existing solutions easier to implement? [21:25:04] Krinkle: i like the idea of a base skin based on mustache that is friendly to subclassing/extending/modifying it [21:25:36] both, in a sense. This doesn't bring anything new per se to the world of skinning. I want to reduce friction points that skin authors face when trying to either make a skin for general consumption, or when making a unique style for their own wiki [21:25:54] Okay, I'm trying to follow this, but I'm a bit slow right now... [21:25:54] Somebody said something about the core stuff having all the valid html for skins, but that's just not the case? The core stuff is soup and also we need more than just html to be inheritable and such. [21:26:19] To me the idea of a skin fork doesn't seem that unappealing. One could rebase/merge-in upstream changes once per release cycle. Of course sub classing would be even easier, and is also something that is possible today already, but that's more a question of whether the thing you want to modify has a clean customisation point or not. For most "small" changes it is inevitable to duplicate something. Whether 10 line PHP method being duplicated [21:26:19] in a sub class, or a 20 line mustache template being duplicated with 1 line difference. [21:26:29] Skizzerz: i can see how sub-skins would work. i don't quite see how extensions would work. If I have two extensions that both want to add something to the sidebar, how do they do that? [21:26:45] Most of the content in any given skin IS stuff that should be in core, but it isn't, like the getportlets generators, proper footers, even really consistent stuff like preferences content... [21:26:54] so a system that I've found in use elsewhere is that extensions that want to modify UI effectively do a find/replace [21:26:54] And it's just duplicated everywhere. [21:27:01] "find X string, replace with X+Y" [21:27:25] if that's the case, then two extensions won't collide because they'll each be able to successfully execute that action [21:27:35] That's why it's a problem to fork skins, because you fork a skin, you fork EVERYTHING in the skin. The sidebar logic, the footer html, basically everything but the content and header. [21:27:50] And there's no way not to do that. [21:28:04] Isarra: I agree that "make skins not suck" is a great goal, but it doesn't seem focused anough for an irc discussion :) [21:28:06] it certainly has downsides, but it's an option for extensibility in a way that should be compatible with multiple extensions trying to manipulate the same area [21:28:23] (and yes, the gurrent system is, err, not great) [21:28:29] And php extending the skinMonobook class is a bad idea too because if the structure changes at all everything breaks. [21:28:59] That's what this is - templating allows us to resolve that by making things inheritable on top of that. [21:29:16] We won't need all this crap in all of them, and we'll have a more robust thing than extending the class, too. [21:29:22] Skizzerz: wait - extensions would use search&replace, or regex munging to put things into the skin? the current system of hooks seems sane in comparison... [21:29:37] I'm open to better ideas :) [21:30:07] (as an aside, mediawiki's hooks system is pretty sane compared to how I've seen software extensibility done elsewhere. I'd almost qualify it as a gold standard) [21:30:09] Isarra: RE: "extending is a bad idea because if the structure changes everthing breaks" - can you elaborate on that? [21:30:12] sorry, that came out a bit more harsh than intended. Take "sane" to mean "sanatized" :) I'm worried about broken HTML [21:30:21] How is that different from regular public API contract changes between releases? [21:30:34] Is there a non-theoretical example of this happening for skins? [21:30:35] the skin templates effectively become a public API in this case [21:30:56] *** FYI we are half way through the scheduled meeting time *** [21:31:22] duesen_: I agree, that's a problem. I don't think there's a way to enforce that an extension doesn't break html outside of saying "don't do something really dumb" [21:31:26] Modern extended monobook and changed the main function to adjust the DOM a bit. [21:31:27] Skizzerz: the solution would be to have a place in the skin that renders a list of html chunks, and extensions can add to that list of chunks. this is where the nice boundary between "template" and "data" breaks down, and the template treats bits from the data model as pre-rendered HTML. [21:31:42] i keep running into this with any kind of skinning system i have seen [21:31:44] I tried to make MonoBook more consistent with other skins internally and totally broke modern. [21:31:54] It sounds to me like what you want is to encourage skin authors that fork popular skins, to stop doing that and instead subclass it, so that maintenance is easier and breakages are more obvious/easier to resolve by technical means. Also it sounds like this would require commitment from WMF to treat its Skin PHP classes as public APIs and follow the deprecation policy for it. [21:31:57] Would that suffice? [21:32:05] And then we would have had to completely rewrite modern anyway to inherit this. [21:32:11] Isarra: and IIRC Cavendish still extends MonoBookTemplate although there's a ticket about removing the dependency (but Cavendish is sorta-maintained and on GitHub, not on gerrit, so...) [21:32:28] What, no... [21:32:45] as an example, let's say that we have sidebar things, and one of them is
. I want to inject an element before that. So I find that div and replace it with {{> MyExtensionSubTemplate}}
[21:32:57] duesen_: does that illustrate what I'm going after better with regards to extensions? [21:33:23] The whole problem here is that depending on php for this adds too much complexity. For the most part, skins shouldn't care one bit what the actual php is, they should inherit it all by default from somewhere stable, and 99% of the changes will be to the templates and css and such. [21:33:59] But we have nowhere stable for this, nor any default templates... [21:34:17] Skizzerz: for making skins, yes. For allowing extensiosn to inject stuff into skins, not really. the current system has (ugly but functional) ways to do that. i'm trying to understand how that would work in the new system. [21:34:39] Isarra: I think we may be forgetting about use cases you don't care about. That's fine, but what I don't get is why are we proposing to require a skin to be based on mustache template? What are we gaining by no longer allowing a MW extension repo to register a skin as PHP class like today? [21:35:22] One can certainly subclass a SkinTemplate class that only uses mustache and work with the maintainers of skins you use to use those accordingly. Then your skin-fork would only need to subclass those skin's template classes and point to your own mustache files instead. [21:35:28] so there'd be a hook whenever a template is loaded. That hook is passed the template, which extensions can then modify. Exactly how they can modify is undefined in the RFC. I suggested a find/replace, but we could go with something more robust (such as a mini language based on DOM traversal) [21:35:35] ...what? [21:36:17] Skizzerz: that sounds like skin authoring is getting simpler, but writing extensiosn that inject stuff into skins is getting a lot harder... [21:36:18] The proposal as written seems worded to aim at core, hence my resistance. It seems entirely unnecessary to require it and break things. And the remaining part of what we want to do, are already possible. Which would be a matter of social convention to encourage wider use of. [21:36:23] Is that... is any of that what I said? [21:36:30] e.g. $template->find("css selector goes here")->insertAfter("{{> MyExtensionTemplate}}") [21:37:07] I'm just spitballing ideas; I'm not sure what a good solution would be for extensions. I think both of the above would be simple enough to do in an extension [21:37:27] Isarra, Krinkle: if I'm not mistaking, your argument seems to be about whether THE base skin is based on mustache, or there is A base skin based on mustache. [21:37:28] certainly no harder than how extensions currently just munge everything in BeforePageDisplay with regex find/replace... [21:37:39] I'm sorry, I can't keep up with any of this right now. If you want specific examples of things, please ping me, but otherwise I'm just going to trust Skizzerz to maybe be more able to communicate the matter. [21:38:13] +1 to duesen_'s explanation [21:38:52] Skizzerz: I think both find/replace and DOM-queries are fragile. It seems much preferred to have an abstract API, and would solve the same problem. Rather than spreading intimate knowledge of what the DOM looks like, and have the extension do CSS selectors, what about something like $skin->addThing('extension thing'). Then the skin can implement that method however it sees fit. Regardless of what its DOM looks like. [21:38:58] Skizzerz: SkinTemplate has currently 9 hook points to inject stuff without the need for regex muinging. What would they be replaced with? [21:39:12] Skizzerz: some would just supply data, but some supply rendered HTML [21:39:17] I think for this RFC to be feasible, we'd need to have both the mustache-template system and the current PHP templating system side-by-side for a number of versions [21:39:30] the ones that supply data would need to continue to exist and continue to supply data [21:39:40] Isarra: if there was a base skin based on mustache, that could be forked as you say and customized with pure css / js, would that accomplish the goal you and Skizzerz have, without breaking changes? [21:39:43] duesen_: Was that what he was saying? [21:39:48] Isarra: would having A base skin based on mustache be sufficient, or do we have to reqrite all skins to satisfy the requirement? [21:39:52] the ones that supply rendered HTML would instead be their own templates, which child skins and extensions can override as necessary [21:40:03] *rewrite [21:40:37] Skizzerz: ah, but then you have the last-write-wins problem of two extensions wanting to replace the same sub-template. [21:40:49] that'S what i was getting at with the lsit-of-html-chunks earlier [21:40:55] duesen_: Eventually, if this were to move forwards, I'd like everything rewritten to use the new template and the old PHP templating system taken behind the shed [21:40:57] The mustache would be a layer on top of... [21:41:16] duesen_: if an extension wants to wholesale replace a sub-template, then it's probably doing that for good reason and we should let it [21:41:17] Um, it wouldn't be the only thing. The idea is to layer it. [21:41:26] and if two extensions want to do that, they probably aren't compatible with each other anyway [21:41:52] Meanwhile if we have my above proposed injection system, they can each add whatever sub-sub-templates they want to that sub-template and work happily together [21:42:08] instead of having only 4 places to inject your extension html, now you can put it anywhere [21:42:10] Skizzerz: I doubt that. I think we have a lot of cases of multiple extensions injecting things into the same place in the skin right now. and we'd have to find a way to keep them working. [21:42:28] right, would my proposal above not be suitable for that? [21:42:35] basically, my questions about extensibility, and krinkles questions about the need to modify core, is really: [21:42:43] how do we do any of this in a backwards compatible way? [21:43:06] or a modification of what I said above based on what Krinkle said (such as assigning semantics to various areas and letting injections happen based on that, rather than worrying about particular DOM structure) [21:43:13] how can we move in the direction you want without having to rewrite all existing skins, and break or change existing extensions right away? [21:43:20] we can't [21:43:29] then that's a show stopper [21:43:49] we can provide a new template, and migrate skins one-by-one to it. Extensions that want to deal with the new style will need to be modified to support the new style [21:43:53] we can't rewrite all that stuff at once, and we can't break it. [21:44:12] We can carry forward existing hooks, but that's it. Most of how extensions interact with skins is skin-specific anyway. [21:44:15] how doe we provide compatibility during aq transition period? [21:44:26] but the RFC inherently is not backwards-compatible with the existing system, and I think such backwards compatibility would be harmful to the goals it is trying to achieve [21:44:29] There is NO way to fix this that does not include breaking things/requiring new stuff to be used. [21:44:35] different hook names? [21:44:38] Because there is nothing we can keep using. [21:44:50] new system uses new hook names, old system sticks around and uses old hook names [21:45:02] anything that wants to work with the old system continues to work because we aren't changing any of it [21:45:04] Skizzerz: that lack of backward compatibility is the main concern. B/C is a must at least for a transition period [21:45:28] but once a skin transitions to the new system, then anything that wants to hook into it would need to be updated somehow [21:45:50] Skizzerz: ok, so, the old skins stay as they are. and a new hierarchy of skins is developed, derived from a new base skin. [21:45:52] is that the idea? [21:45:54] yes [21:46:12] I think all of this can be done without breaking compat. [21:46:22] So, the proposal is to create a new base skin, and encourage other skins to be ported to extend it? [21:46:23] I mentioned in the RFC having a transition period where both systems exist side-by-side for at least 4 versions. I think that may be too aggressive though, given how slowly 3rd party wikis move [21:46:32] **** 15 minutes remaining **** [21:47:04] I don't want to break or remove the old skinning system until the new one has been proven to work well and things have had time to migrate [21:47:13] Krinkle: What compatibility are you referring to? [21:47:15] I just don't think we can reconcile having old code work with the new system [21:47:16] Exactly? [21:47:28] because they are just fundamentally different [21:47:33] Skizzerz: so I suppose the key question is really if and when mediawiki's default skin(s) would be based on the new system. [21:47:57] ideally as part of the RFC. I could demo with one or two at first, but I'd like to migrate everything. [21:48:16] btw, i think there is some confusion about the backwards compat issue. you are saying it's backwards compatible because the old system stays in palce, but it's not because it's totally different. I think I see what you mean, but it's causing confusing [21:48:32] sorry, I'm not sure what level of backwards-compat you're expecting [21:48:50] I'm confused what compatibility people are talking about to begin with. [21:49:25] There are basically two ways to add something to a skin - a hook to add something to a particular div or such, or by adding it to an array that generates navigation. [21:49:27] I can think of a couple of extensions that do lots of things with skins: Echo and VisualEditor. Echo would definitely need modifications to work with the new system [21:49:41] VisualEditor should be able to work without changes, I believe (or very minimal changes) [21:50:02] Echo needs modifications to work with the current system. [21:50:07] Every skin has to custom handle it. [21:50:22] VisualEditor is js and should keep working regardless. [21:50:27] https://codesearch.wmflabs.org/search/?q=Hooks%3A%3A.*SkinTemplate&i=nope&files=&repos= [21:50:45] that'S a naive search for all the things that would have to be modified in extensions [21:51:26] right, some of those are data hooks, which wouldn't need modification at all [21:51:47] Perhaps it would help if you could outline the process you envision for introducing the new system and transitioning mediawiki sites/skins/extensions/gadgfes/etc to using it [21:51:55] in the rfc, i mean, not here and now :) [21:52:10] I agree. I can add a section on that. I'll also clear up some of the confusion above, and remove references to on-wiki customizations [21:52:15] Having a list of data vs non-data hooks would help, too [21:52:35] Skizzerz: thank you. i think that would help a lot [21:53:12] Many of the non-data ones are things like adding a tab, or such. That should be fairly trivial to carry forward, and if anything made more reliable by not having to manually include support for it in every skin. [21:53:13] to be clear, i like the system you propose. i think it would be much nivcer to work with than what we have. [21:53:35] ...wait, adding a tab should be data. [21:53:36] But as alwayw with mediawiki, the key question is: how do we get there with the resources we have without breaking all the things. [21:53:49] Krinkle: there are some core "sacred cows" that I would like to slaughter as well, such as how Table of Contents is generated and injected in to skins (to give skins more control of that). But I think such things are best put off until after a base system works [21:54:09] also infoboxes, but that's still an idea that's in my head [21:55:02] Skizzerz: MCR needs a way to lay out the content of multiple slots on a page, quite possibly customizable per wiki and namespace. I'd love to have such a mechanism. [21:55:04] any sort of skin modification of what typically goes into the content area is going to require more work and would likely just add too many things into this RFC [21:55:50] sure, i'm nto saying it should be in there. just saying i'm sympathetic to your pain :) [21:55:52] duesen_: Yeah, real MCR content rendering is pretty hard to reconcile with having arbitrary skins, unfortunately. [21:55:53] duesen_: I think the plan is to have Skizzerz implement a base prototype, and ashley and I as the main maintainers of skins, as well as some extensions using really stupid hooks, will experiment with it further and figure out what's missing, or something. [21:56:16] And if it actually works we should be able to migrate all the ones in gerrit over pretty easily, though... uh... [21:56:16] Isarra: that sounds liek a plan [21:56:21] ok so I think the action items from this meeting are: [21:56:28] 1. Expand upon the RFC to include a migration plan [21:56:33] Giving an overview of extensions and hooks, and how they would need to change, would be very helpful [21:56:41] 2. Add a section for possible future expansion [21:57:01] ashley can add all the weird wikihow hooks to it. [21:57:28] #action 1. Expand upon the RFC to include a migration plan [21:57:59] #action 2:56 PM 2. Add a section for possible future expansion [21:58:17] anything else to note specifically in the minutes? either with #info or #action? feel free [21:58:22] just a couple minutes left [21:59:53] Skizzerz: I hope this wasn't too discouraging. I know that these discussions can feel very antagonistic, and the pace can gert a bit crazy. [22:00:07] no this was great, thanks for the feedback [22:00:28] I very much appreciate the goal of this rfc. But unfortunately, our job as techcom is to try and poke holes in nice things. [22:00:46] it'S just to make sure they actualyl work, but it's still poking holes into nice things... [22:01:21] I'm sorry I couldn't explain things very well. [22:01:54] unless anyone has any other last minute things I'm going to close the meeting [22:02:09] I was sort of hoping I wouldn't still be sick by now. [22:02:54] :( [22:02:55] As long as this was helpfull to move things forward, all is good [22:03:16] Isarra: oh, I hope you feel better soon! [22:03:24] #endmeeting [22:03:24] Meeting ended Wed Apr 3 22:03:24 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [22:03:24] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-03-21.00.html [22:03:24] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-03-21.00.txt [22:03:24] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-03-21.00.wiki [22:03:25] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2019/wikimedia-office.2019-04-03-21.00.log.html [22:03:33] Skizzerz is the brains. As long as he understood, we should be good. [22:03:41] Brains. [22:03:52] Isarra: same here, feel better soon! [22:05:02] Thanks. >.< [22:05:28] Now I have that picture of Pinky and the Brain in my head... [22:07:31] anyway, thanks for chairing, KateChapman! [22:15:47] duesen_: got sidetracked, sorry. Getting holes poked into it is my goal as well, it's better to discover any design issues now while they're still words on a wiki than it is after a ton of hours have been invested in coding [22:16:27] (the pace was indeed crazy though!) [22:16:56] I'll post on the phab task when I have the updates out