[00:17:21] RoanKattouw: I'm about ready to go home, but if the remaining issues you're referring to are small, I can sneak them in before I go. [00:17:48] I just submitted the comments, sorry about that [00:18:17] I was replying directly to comments on patchset 1, I guess that's why it behaved the way it did [00:18:22] It's all small stuff [00:18:26] cool [00:18:36] thanks [00:28:53] RoanKattouw: rather than fix the line in alter.sql, i added a change-column line at the bottom -- since various local environments and prototype have the enum already [00:29:31] OK that's fine [00:29:49] I will manually collapse those when applying alter.sql to the cluster on Thursday [00:32:32] thx [00:45:16] rsterbin: Thanks, all good now, approved and merged [00:45:26] thanks! [00:45:38] glad to have that done on wednesday :) [00:45:43] Yeah me too [01:09:34] <^demon|away> RoanKattouw: I didn't copy the REL branches for extensions. Other than l10n backports, they're almost always unmaintained. [01:10:19] Hmm OK [01:10:27] So how is Reedy supposed to build the 1.19 tarball then? [01:10:33] Oh wait no extensions [01:10:43] And I guess ExtDist hasn't been fixed for git anyway [01:10:47] <^demon|away> Magic. [01:10:59] Hmm well the 1.19 tarball has some extensions I guess [01:11:07] <^demon|away> To be perfectly honest, I have zero clue. I haven't figured it out. [01:11:14] OK [01:11:31] Re docs, I'm overhauling https://wikitech.wikimedia.org/view/How_to_deploy_code [01:11:45] It will have all the instructions for deploying extension changes, including all the submodule stuff [01:11:45] <^demon|away> I was thinking of using tags for this somehow. [01:11:53] <^demon|away> Like @ release, go through extensions and tag them. [01:12:00] <^demon|away> So you can at least pair extension -> master [01:12:04] <^demon|away> s/master/core/ [01:12:05] and for creating 1.NNwmfM branches for extensions as-needed [01:12:11] Right [01:15:11] <^demon|away> I responded to your e-mail, that should answer other questions. [01:16:50] Yeah I read it [01:57:47] RoanKattouw: Yeah, ExtensionDistributor on mw.org hasn't been fixed to work with git [01:58:10] !b 35574 [01:58:10] https://bugzilla.wikimedia.org/show_bug.cgi?id=35574 [01:59:07] Hm.. that could get quite complicated if not organized properly [01:59:14] extension repos can have their own branching now [01:59:29] We should have REL_ tags for extensions [01:59:49] so ExtDist would probably have to fetch a list of branches and/or tags after selecting the extension name [01:59:55] wmf/* branching is irrelevant, and REL_ branching for extensions ideally shouldn't happen [01:59:57] Yes [02:00:02] Hmm yeah [02:00:09] There is no global list of tags/branches anymore [02:00:25] No more generic branches that all extensions will have [02:00:31] but that's also a good thing, in a way. that way there will only be a branch if the extension maintainer choose to and will be aware of it [02:01:44] !b 36035 [02:01:44] https://bugzilla.wikimedia.org/show_bug.cgi?id=36035 [02:01:51] RoanKattouw: Do you have any clue what could cause bug 36035 [02:02:04] its in new pages and general search, but not in opensearch [02:02:14] Weird [02:02:17] Maybe it's a TitleKey issue [02:03:08] No idea what's going on there [02:03:17] * RoanKattouw is about to leave and doesn't wanna dive into that [04:26:49] Testing Windows -dev [15:05:05] Krinkle: you around? I'd like to get some clarification on bug 35939 [15:05:10] !b 35939 [15:05:10] https://bugzilla.wikimedia.org/show_bug.cgi?id=35939 [15:05:18] Good morning [15:05:38] mornin! [15:05:40] Oh that [15:05:42] Hi [15:05:46] I just got up [15:05:54] robla: what kind of clarification? [15:07:01] well, for starters, what's the exit condition for it? [15:08:09] I'm not sure what you mean by 'exit condition'. [15:08:50] RoanKattouw -- alas, there's one more commit to be reviewed for tomorrow [15:08:53] https://gerrit.wikimedia.org/r/5229 [15:08:57] I just saw, yeah [15:08:59] Reviewing now [15:09:01] thanks [15:09:39] Krinkle: meaning "what needs to happen before this can be marked as fixed?" (and how is that different than bug 31173)? [15:10:05] robla: bug 31173 requests a certain piece of functionality to be added to mediawiki core [15:10:20] bug 35939 is a problem currently in the wmf-config [15:11:01] bug 31173 will auto-fix 31173, but 31173 could be fixed by other (temporary) means if it becomes a high priority problem. [15:11:18] which it currently isn't, depending on who you ask. [15:11:22] 31173 will auto-fix itself? [15:11:28] That must be a typo (although it is true :D ) [15:11:38] bug 31173 will auto-fix 35939, but 35939 * [15:12:44] The links in the opening comment on bug 35939 links to where it is explained best, especially `bug 31173 comment 6` [15:14:22] It comes down to the fact that `wgResourceBasePath` has nothing to do whatshowever with the 'resources' directory, it is a naming conflict with 'resource loader' and 'resources' (the only clue is that `wgResourceBasePath` has no plural "resources") [15:14:45] which is why the current hack exposes the entire mw-version root, and uses a double dir hack to get to it [15:14:53] https://www.mediawiki.org/w/resources-1.20wmf1/resources/jquery/jquery.suggestions.js [15:14:56] resources/resources [15:17:22] Krinkle: Hmm, I don't think we can change the variable now because it has a well-documented meaning [15:17:34] Instead, we should fix the symlink structure on the cluster as per your stuff-1.20 suggestion [15:18:12] resources-1.20wmf1 doesn't have to be a symlink to the docroot, it can also be a directory containing three symlinks (to skins, resources and extensions) [15:18:33] I didn't mean to suggest changing the variable. wgResourceBasePath != wgResourcesPath [15:18:51] Ah OK [15:18:56] wgResourcesPath is like wgExtensionsAssetsPath [15:19:02] So $wgResourceBasePath would default to "$wgResourcesPath/resources" [15:19:06] or rather, would be, if we implement it [15:19:19] Yes, probably [15:19:37] and wgExtensionsAssetsPath and wgSkinsPath (Or whatever it is called) should also use wgResourcesPath [15:19:54] $wgStylePath yeah [15:19:54] wgResourceBasePath* [15:20:11] which is backwards compatible since wgResourceBasePath itself is false by defaulting to wgScript [15:21:10] $wgScriptPath, yes [15:21:15] yeah [15:22:02] RoanKattouw: The implementation should probably not be to actually link mw-version-docroot to stuff-1.20 though, I think it's still better to create 3 separate aliases, as to not expose the entire docroot [15:22:11] Yes, of course [15:22:22] its not too critical since there are entry point protections, but up until mw-version het deploy, we always hid the docroot, so might as well keep doing that (in that w/ is not a real link to docroot either) [15:22:30] But $wgResourceBasePath would allow us to change the structure [15:22:34] Yep [15:22:40] Point resources-N to resources, skins-N to skins, etc [15:23:09] RoanKattouw: Hm.. do you mean wgResourceBasePath ? [15:23:15] * robla starts http://etherpad.wikimedia.org/bug35939 to hash out a coherent explanation of the proposed solution [15:23:22] Yeah w/ actually goes to a directory with multiversion wrappers (live-1.5), not the docroot [15:23:27] Krinkle: Sorry $wgResourcesPath [15:23:31] * RoanKattouw keeps confusing the old and the new name [15:23:44] I guess that is part of the confusion [15:23:55] neither is old or new name [15:24:05] Well one of them is definitely new [15:24:11] yes, [15:24:15] I agree the 'old' one isn't technically old [15:24:27] i mean, neither is going away, they have a different meaning [15:29:07] Yes [15:29:18] I mean "pre-existing" and new I gues [15:30:13] RoanKattouw: can you switch to a lighter color? [15:33:34] hi, has anyone tried watching only some directory of a repository in gerrit? i tried it using the file: operator, but it doesn't seem to work [15:33:50] Svick: Let me see [15:34:14] Svick: path:^includes/api/.* should work I believe [15:36:48] RoanKattouw: that says "Unsupported operator path:^includes/api/.*" to me [15:37:19] RoanKattouw: I like (1), what do you think? I've highlighted the difference a bit [15:37:26] I like (2) better [15:37:33] Bah [15:38:06] ? [15:38:22] Sorry, "Bah" was re Svick saying it didn't work [15:38:38] RoanKattouw: and file:^includes/api/,* doesn't cause any error, but it doesn't show anything in the list of watched changes [15:39:19] RoanKattouw: the stuff-1.20/resources is (1) [15:39:24] so, part of the reason why I'm trying to get to the bottom of this is that bug 35939 has a target milestone of 1.20wmf1. I'm assuming we can push to 1.20wmf2, right? [15:39:54] robla: 1.20 in general [15:40:04] Svick: Sorry, you're right, it is file. So file:^includes/api/.* (with a dot not a comma) should work I think, let me test that [15:40:05] either now or somewhere down the road, not blocking [15:40:11] robla: Yes we can [15:40:19] In fact we *should* [15:40:29] Because 1.20wmf1 has already been partially rolled out [15:40:43] but knowing people link a lot to wmf resources from all over the place, I'd rather not have it go to the background [15:40:59] I think it'll be fine [15:41:08] As long as we keep the nonversioned symlinks intact [15:41:20] The URLs with version numbers in them change all the time anyway, because the version numbers change [15:41:35] This is why we shouldn't make this change now in 1.20wmf1, but apply it to 1.20wmf2 right as we roll it out [15:41:35] yes, but I've never seen anyone use a non-version path in any gadget or tool [15:41:38] that'd be a first [15:42:02] Well it's not like people will magically start using the 1.20wmf2 paths as soon as we deploy [15:42:07] They would have to update those anyway [15:42:09] people copy what they see in the source code [15:42:12] I know, no problem :) [15:42:20] Update them every two weeks I might add :) [15:42:22] those break either way [15:42:49] RoanKattouw: right, i did mean dot; but even something like file:^.* doesn't show anything for me [15:44:54] Yeah I see the same behavior [15:44:54] RoanKattouw: So can you elaborate on your preferred solution? [15:45:22] Krinkle: It's Proposed solution (2) in the Etherpa [15:45:24] d [15:48:54] ok....I've copied the explanation to a comment in bug 35939, and moved it to 1.20wmf2 for now (looks like there might have been a purging of milestones from BZ) [15:49:36] robla: the wmf milestones are in the 'Wikimedia' product [15:50:26] bug 35939 is on 1.20wmf2 now [15:50:39] oh....that's right Wikimedia is different [15:50:49] however, Mediawiki should also have the wmf milestones [15:51:22] otherwise, we wont' be able to mark Mediawiki bugs as deployment blockers [15:51:36] Hm.. [15:51:37] right [15:52:04] I thought we used to have a generic wmf-deployment blocker [15:52:05] not versioned, since if it is blocking.. [15:52:22] I can't find it anymore though [15:52:46] [MediaWiki] The milestone 1.20wmf deployment has been created. [15:53:52] it totally needs to be versioned [15:53:58] yeah [15:54:08] OK [15:54:13] Shall I proceed to implement solution (2) ? [15:54:41] RoanKattouw: Can you maybe elaborate a little it on the choice? I don't have a strong preference, but (1) seemed like the logical choice to me [15:55:08] Krinkle: (1) requires a larger change in our symlink structure [15:55:21] Hmm but a smaller change in MW core [15:55:42] Aside from the advantage in mw core, you said yourself it would only have to apply to new symlinks [15:55:49] Yes [15:55:54] But that applies to both (1) and (2) [15:55:58] yeah [15:56:27] hmm [15:56:42] so the size of the change isn't all that important, it's either removing 1 line and adding 1 line in mm-version create, or changing 2, removing 1 and adding 1 [15:56:52] For (1) we need no MW changes at all [15:57:00] hm.. [15:57:02] ah, right [15:57:10] We don't need to phase out $wgStylePath / $wgExtensionAssetsPath either (and we shouldn't) [15:57:17] Just set them appropriately on the cluster [15:57:24] Yeah [15:57:49] Then I'd only have to hack the checkoutMediawiki script to set up the symlink structure correctly [15:58:04] maybe change mediawiki defaults though that skinsPath and extensionsPath do take resourceBasePath as part of them (I think right now Setup sets them to wgScriptPath), but that's optional, we can set it in wmf the way we want it [15:58:35] oh, and I assume we can let them point all to bits instead of local wiki? [15:58:43] They already do [15:58:48] Except for $wgLocalStylePath [15:58:52] the symlinks do, but the settings dont [15:58:56] Yes they do [15:59:02] * RoanKattouw checks [15:59:05] There is a wgLocalStylePath ? [15:59:14] Yes, for csshover.htc [15:59:18] .htc files can't be cross-domain [15:59:19] Oh.. [15:59:45] k [16:00:05] Hmm you're right that $wgResourceBasePath doesn't point to bits [16:00:16] in debug mode stuff comes from local domain [16:00:26] Yes, but only /resources stuff probably, right? [16:00:32] yes, skins do come from bits [16:00:34] Skin stuff and extension stuff should come from bits already [16:00:35] Yes [16:00:38] So that's a bug, well spotted [16:02:08] csshover.htc is the only thing so far that needed to be local? [16:02:10] Incredible [16:02:14] I thought there'd be more [16:02:30] No that's all [16:02:36] at least to the point where the config for it is not skins dir specific [16:02:40] We set it up so you /could/ have more [16:02:56] yeah, its not wgCssHoverHtcPath :P [16:03:00] hehe [16:03:12] OK let's dish out some RL2 tasks too [16:03:18] yep [16:03:18] Then I'll work on this then RL2 [16:03:26] Stuff I was planning to do today: [16:03:38] * Fix display bug on preferences page [16:03:39] * Add support for skin and position properties [16:03:41] * Instate ID length limit in backend [16:04:22] RoanKattouw: (so, wontfix 31173 ?) [16:04:46] Yeah I guess so [16:06:03] RoanKattouw: btw, I renamed /w/stuff-$version to /w-$version [16:06:16] I don't know if aliases higher than /w are a problem? [16:06:24] (well, siblins rather) [16:06:28] siblings* [16:06:35] No it needs to be inside /w [16:06:39] ah.. [16:07:45] well, then we need to come up with a stupid word to put in between : [16:07:46] :P [16:07:51] * RoanKattouw ponders directory names [16:08:06] We could just have /resources-1.20wmf2/skins [16:08:07] static ? [16:08:12] Ha! Yes [16:08:17] static-1.20wmf2 [16:08:19] or bits [16:08:49] except if the same name is used on bits.wm.o, then better not have bits.wm.o/w/bits-1.20 [16:09:34] RoanKattouw: hm.. on bits there is no /w/, right ? skins is aliases in the root there [16:09:43] /bits.wikimedia.org/skins-1.20wmf1/vector/images/search-ltr.png [16:11:10] Yes, skins and resources are in the root, but extensions is in /w [16:11:13] Really confusing and evil [16:12:27] RoanKattouw: So bits aliases are set up separate, right? [16:14:31] No I don't think so [16:14:33] Well, maybe [16:14:40] Anyway the way I'm doing it should work [16:14:45] * RoanKattouw should probably test this [16:14:45] alrighty [16:17:30] RoanKattouw: so re: RL2 points you listed, looks good. I've listed mine in the features pad of this week [16:17:59] Nice [16:18:06] Re moving stuff out / pushing it back: yes and yes [16:18:39] I have backed out and branched off Salvatore's code [16:19:42] okay, I hadn't noticed [16:19:53] did that go through gerrit? [16:20:10] Only part of it did [16:20:13] I created the branch directly [16:20:26] Then I submitted a merge (merge RL2 into gadgetprefs) to Gerrit [16:20:33] That commit fails PHP lint, BTW, I should fix that [16:20:49] Or it explodes in some other way, I forget [16:21:17] https://gerrit.wikimedia.org/r/#change,4342 [16:21:22] You should be able to find it in Gerrit if you search for project:mediawiki/extensions/Gadgets branch:gadgetprefs [16:21:42] Oh, yes, and that [16:21:54] If you approve that, Salvatore's code will be out of the main RL2 branch for the time being [16:22:24] My broken merge attempt is https://gerrit.wikimedia.org/r/#change,4385 [16:22:33] Thanks [16:23:11] okay, if you like you can take the time now to figure some stuff with the symlink/paths stuff, I'll take a quick food break (as I was planning to before robla pinged me :) ) [16:23:36] brb in 20 [16:24:53] OK [16:24:59] * RoanKattouw starts symlinking stuff [16:29:48] DarTar: how would you feel about closing the clicktracking bug and just keeping clicktracking requirements on the page you've created? keeping a highest-priority bug open continually isn't really optimal, and it just increases the number of things you have to update. [16:38:10] jpostlethwaite: Are you still working on the UnitTest extension? [16:38:21] yes [16:38:42] Any idea when it's likely to go into core? [16:38:48] i have been getting used to the git-gerrit process : [16:38:52] ahh [16:38:54] i have no idea on that [16:39:00] The WikiData guys are going to be using it (or are starting to) [16:39:03] i have a bunch of stuff to commit to it [16:39:17] okay, I have some important updates [16:39:19] fo rit [16:39:22] for it [16:39:32] i was wanting to get some commits this week [16:40:14] who in particular in WikiData is starting to use it [16:41:03] Tobias for one [16:41:34] ok, I will try to talk to him this week about it [16:41:40] Cool, cheers [16:41:42] thanks for the heads up :) [16:41:51] He just mentioned the core stuff was too old for their usage [16:42:06] i can understand that :) [16:56:54] rsterbin_away: I was in a meeting, catching up with AFT stuff in a moment [16:57:52] but I agree on that ticket, no need to keep it open, let alone give it highest priority [17:01:58] RoanKattouw: wow, it feels like a million years ago when I wrote gadget editor. diving into the code now to start working on todays points [17:08:54] Krinkle: mediawiki will soon(ish) have the ability to store arbitrary data types. so there will be no need to encode gadget definitions as pseudo-wikitext. [17:09:04] just a thought :) [17:09:23] Daniel_WMDE: RL2 is ahead of that [17:09:35] RL2? [17:09:40] oh, resource loader [17:09:44] MediaWiki:Gadgets-definition has been dismantled in the RL2 branch of Gadgets [17:09:58] in favor of JSON blobs on wiki pages in a dedicated namespace [17:11:13] But I'm convinced that our solution is probably not as clean as it would be with that new storage properties for data types, although the way we have it now in the RL2 branch is pretty clean within the boundaries we have [17:12:53] hola [17:13:18] Krinkle: i think it would be easy to transition your solution to the COntentHandler stuff [17:13:32] Krinkle: actually, per default, content models are bound to namespaces [17:14:20] mediawiki would just support content types natively, without any need of special cases like for the CSS/JS stuff, or using 10 different hooks toi handle every aspect [17:18:21] Daniel_WMDE: yeah, we wanted to use *.json but choose .js for now so that we don't have to add or register a gazillion hooks [17:18:38] and also Geshi syntax highlighter required it, it has the logic hardcoded [17:18:57] ...but even -js will only work in the mediawiki namespace currently [17:19:02] no [17:19:02] well, i guess you changed that [17:19:03] No, we hacked it [17:19:07] ic [17:19:10] :D [17:19:10] i hacked it too :) [17:19:15] yayy conflicts [17:19:18] well, we'll see [17:19:37] I think we just added a hook in mw-core where it says isJsCssPage() or something [17:19:45] Yeah [17:19:50] it defaulted to NS_MEDIAWIKI, NS_USER preg_match( js|css$ ) [17:20:03] we added one for gadgets through the added hook [17:20:03] Daniel_WMDE: When is the core support for Wikidata going to be done? [17:21:19] hexmode, robla: 20% checkin now? [17:21:21] RoanKattouw, Krinkle: i expect to submitt the first batch of changes next week. that will alreaqdy cover handiing of JS/CSS stuff [17:21:28] sure [17:21:30] OK, nice [17:21:41] it may break the Geshi extension though. would need some adjusting [17:21:48] I guess we can just merge that into our branch and start using it [17:21:49] but nothing too horrible [17:22:00] RoanKattouw: yea, but wait until next week [17:22:10] For sure [17:22:12] the current wikidata branch is very messy [17:22:15] I'll wait until you submit it [17:22:22] ok. gtg now. [17:22:23] cu! [17:22:26] In fact, why don't you add me as a reviewer [17:22:29] when you submit it to Gerrit [17:22:41] will do, thanks! [17:22:47] Nikerabbit: I don't have any specific guidance on today, other than keeping an eye out for the deployment [17:22:52] hi 20% people [17:22:57] robla: just fyi I'm planning and working towards enabling translation memories and TranslationNotifications on the cluster [17:23:36] sumanah: any specific focus areas for 20% time? [17:23:39] Nikerabbit: hi there, sounds like you already have plans for today [17:24:12] robla: when raindrift comes in I'm going to talk with him about ShortURL [17:24:23] sumanah: this is scale of few weeks, not today [17:24:49] I need some help from the ops with those... if they happen to have time [17:25:28] https://bugzilla.wikimedia.org/show_bug.cgi?id=34938 <- Nikerabbit and RoanKattouw: if you have an idea of where the root cause might lie for this, I'd love to know [17:25:55] robla: Reedy - haven't caught up on mail yet this morning. Now that the IE/RTL bug is solved, how long till a 1.19 release? [17:25:56] I'm pinging Roan on this one because l10n cache has been a recent theme. Probably lots of unrelated problems, though [17:26:03] robla: I suspect a bug in localisation cache [17:26:19] o, hm [17:26:33] I've been trying to study that extension but haven't had time really [17:26:54] Yeah the pagetitle message is empty in sa [17:27:01] * RoanKattouw attempts to fix [17:28:10] raindrift: hi, ping [17:28:20] raindrift: (re 20% time) [17:28:52] raindrift: I have to head off in a moment, but I was wondering whether you need stuff to do today for your 20% day or whether you have something in mind [17:31:33] raindrift: https://www.mediawiki.org/wiki/Review_queue - ShortURL could use some attention..... [17:31:36] raindrift: back in 30 min [17:33:39] can anyone help me setup git? I'm on windows following the instructions at https://labsconsole.wikimedia.org/wiki/Git#Windows [17:33:55] but I get an error "couldn't update submodule git INSTALLATION ABORTED." [17:34:02] when the installer has been running for a while [17:34:33] During which step? [17:37:21] it says "fatal: unable to connecto to repo.or.cz: [17:37:33] ^^ [17:37:50] Then that's a bug in some of the software you're installing or downloading I guess [17:38:02] We definitely didn't build anyone that lives on a random Czech web site somewhere [17:38:06] *build anything [17:38:16] not quite sure Roan, it says * [new tag] v 1.7.9.6 --> v1.7.9.6 [17:38:26] it's going through all of these tags [17:38:33] on http://msysgit.github.com/ [17:38:47] I'm using the one on the right hand side [17:39:06] ^demon, Reedy - i just ran into an annoying problem that is solvable with late static bindings but we still have the php 5.2 requirement. per the last email on the "Bump of minimum required PHP version to 5.3 for MediaWiki 1.20", it sounds like someone just needs to… bump the php requirement in trunk [17:39:11] would hte one on the left work with me? [17:39:11] can we just… do it? [17:40:37] <^demon> awjr: If you had suggested 5.3 for any reason other than LSB, I'd say yes :( [17:40:44] <^demon> LSB sucksssssss [17:40:55] ^demon: PHP's handling of static methods and properties sucks [17:41:12] i think LSB sucks a little bit less :p [17:41:22] <^demon> No, people's assumptions of how static stuff should inherit sucks. [17:41:44] <^demon> I mean, even the PHP devs are regretting LSB, doesn't that tell you something? [17:41:46] ^demon: could you have a look at http://www.mediawiki.org/wiki/Project:Requests/User_rights/Thehelpfulone#User:Thehelpfulone please? [17:42:05] ^demon: then we should use static methods and properties a lot less in MediaWiki [17:42:13] <^demon> I agree. [17:42:41] <^demon> People write static methods because they're lazy and want to type less. So LSB was introduced to make static methods behave somewhat more like regular methods. [17:42:47] <^demon> When really, the solution is to write less static code :) [17:42:56] heh [17:43:04] i think there's a slight performance edge when using static stuff [17:43:28] <^demon> Calling a static function is slower than calling a non-static one. [17:43:37] <^demon> But you've got the object overhead. [17:43:38] oh i thought it was vice versa, at least for properties [17:43:42] <^demon> There's always a tradeoff :) [17:44:02] regardless using static everywhere makes extending classes a complete f'ing nightmare [17:44:45] <^demon> Right, which is why people shouldn't write stuff that's static if they want it to inherit like a normal method. [17:44:56] srsly. [17:44:58] <^demon> Like I said, LSB is a crutch for poor initial class design. [17:45:25] i think i need to do some HTMLForm rewriting on my 20% day. [17:45:28] <^demon> The *one* place I've seen LSB be actually useful for is stuff like factory() functions, but that's pretty much it. [17:45:43] that makes sense [17:46:20] <^demon> I've had this debate several times, if you can tell ;-) [17:46:25] hehehe [17:46:54] RoanKattouw_away: Am I correct that skins & position aren't in RL2 yet? I was just figuring out if it was being saved or not, but I guess not [17:47:02] <^demon> I think we should probably write something about LSB in the coding conventions. I know I'm not alone in my distaste for it. [17:47:39] ^demon i think that's not a bad idea - accompanied of course with admonition about poor usage of static methods/properties [17:48:34] <^demon> Static methods and such have their place, they're just wildly overused because people want to type "Foo::bar()" instead of "$f = new Foo; $f->bar();" [17:48:37] ah, okay, it's a 'TODO' [17:48:38] <^demon> Shorter isn't always more clever ;-) [17:48:49] exactly [17:49:12] Krinkle: They're not yet, I am going to do this today [17:49:17] sure, no [17:49:20] sure, np [17:51:41] hexmode: ping re 1.20 issues [17:51:53] hexmode: you heard about the "loss of session data" issue that is cropping up? [17:57:07] <^demon> Was geshi fixed? [17:57:17] No [17:57:23] <^demon> :( [17:57:23] Or if it was, it's not been synced [17:57:26] <^demon> awjr: http://www.mediawiki.org/wiki/Manual:Coding_conventions/PHP#Static_methods_and_properties [18:03:49] Where do I complain about upload wizard? [18:03:56] vvv: what kind of complaint? [18:04:12] vvv: here, the Bugzilla component "UploadWizard," wikitech-l are reasonable choices [18:04:44] Well, I want an email where I can forward an issue complain [18:04:52] vvv do you have a particular issue? I've been finding some bugs in UploadWizard myself recently [18:04:54] vvv: although of course I prefer friendly notifications .... [18:09:44] csteipp: you may enjoy skimming https://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering to see the most recent updates from various activities that your teammates are doing [18:10:45] Thanks sumanah! [19:03:26] Joan, around? [19:05:26] Reedy: fix is in gerrit, brion had a minor complaint that I'll address today [19:05:31] (re geshi) [19:16:50] hexmode: ping re the "loss of session data" issue that is cropping up in 1.20 - have you heard about this? [19:17:45] sumanah, should be fixed [19:18:11] Eloquence: got it, yay, thanks. [19:22:05] !bug 35900 | Eloquence: sumanah : [19:22:05] Eloquence: sumanah :: https://bugzilla.wikimedia.org/show_bug.cgi?id=35900 [19:22:21] nicely botted, Krenair [19:22:23] Krinkle: [19:22:26] :) [19:22:42] :P [19:22:49]