Architecture meetings/RFC review 2013-11-06/Log

22:03:58 &lt;qgil&gt; #startmeeting 22:03:58 &lt;meetbot-wm`&gt; Meeting started Wed Nov 6 22:03:58 2013 UTC. The chair is qgil. Information about MeetBot at https://bugzilla.wikimedia.org/46377. 22:03:58 &lt;meetbot-wm`&gt; Useful Commands: #action #agreed #help #info #idea #link #topic. 22:04:05 &lt;^demon|lunch&gt; I got pinged twice on IRC and once IRL, guess I am here :) 22:04:09 &lt;siebrand&gt; gwicke is still in the wrong channel. 22:04:23 &lt;qgil&gt; #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-06 22:04:36 &lt;qgil&gt; Ok TimStarling, you can start :) 22:05:01 &lt;robla&gt; (etherpad: https://etherpad.wikimedia.org/p/ArchitectureMeeting ) 22:05:24 &lt;qgil&gt; #link https://etherpad.wikimedia.org/p/ArchitectureMeeting 22:05:31 &lt;TimStarling&gt; well, TitleValue, a nice simple one to start with eh? 22:05:43 &lt;qgil&gt; #topic TitleValue 22:05:58 &lt;bd808&gt; #link https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue 22:06:45 &lt;DanielK_WMDE_&gt; hm, am i supposed to say something about TitleValue now? 22:06:47 &lt;TimStarling&gt; were there any unresolved issues from the mailing list discussion that anyone would like to raise now? 22:06:47 &lt;qgil&gt; (thank you bd808 - fyi everybody, if you want a sentence to appear in the notes, start with #info bla bla ) 22:06:59 &lt;^d&gt; TimStarling: Yes, one of the major unresolved issues was serialization. 22:07:05 &lt;brion&gt; so I love the idea of TitleValue itself; I'm a bit less sold on TitleParser and TitleFormatter and the registry, but talk me into it :) 22:07:11 &lt;DanielK_WMDE_&gt; I found https://wiki.debian.org/MeetBot useful 22:07:11 &lt;^d&gt; I think there was some unresolved question as to how we'd store namespaces. 22:07:20 &lt;^d&gt; Whether it'd be an int, or the canonical name, etc. 22:07:39 &lt;TimStarling&gt; what would you use serialization for? 22:08:33 &lt;brion&gt; other than 'happening to be a member of an object that gets serialized' ? 22:08:55 &lt;TimStarling&gt; we don't really serialize objects very often 22:09:26 &lt;DanielK_WMDE_&gt; serialization is not the point 22:09:50 &lt;TimStarling&gt; as for integer versus canonical namespace, integer seems the obvious choice to me 22:09:54 &lt;DanielK_WMDE_&gt; basically, it's about this: almost everythin uses Title, directly or indirectly. So, to avoid a tangle, Title should depend on very little. 22:10:06 &lt;brion&gt; i'd say there's two prime possibilities: 22:10:08 &lt;brion&gt; 1) use the integer key 22:10:09 &lt;TimStarling&gt; since everything about a namespace can easily be determined from its integer ID 22:10:13 &lt;brion&gt; 2) use a MWNamespace object 22:10:13 &lt;DanielK_WMDE_&gt; but in reality, Title relies on a bunch of things - and thus, everything depends on everything. 22:10:20 &lt;DanielK_WMDE_&gt; This turns mediaWiki into a monolithic tangle. 22:10:33 &lt;brion&gt; but life is simplest if we just store an int eh :D 22:10:54 &lt;^d&gt; I'm fine with ints too :) 22:11:02 * MaxSem scrolls to the bottom of Tite.php and sees getEditNotices:/ 22:11:10 &lt;TimStarling&gt; MWNamespace depends on everything, right? 22:11:30 &lt;DanielK_WMDE_&gt; using a canonical namespace has the advantage that we can meaningfully represent titles from other wikis 22:11:34 &lt;DanielK_WMDE_&gt; with IDs, we can't do that 22:11:58 &lt;MaxSem&gt; I think we'll end up storing title proper, ns number and ns string 22:12:09 &lt;aude&gt; MWNamespace is a utility class 22:12:14 &lt;TimStarling&gt; DanielK_WMDE_: that application is not discussed on the RFC, is it? 22:12:14 &lt;DanielK_WMDE_&gt; which is better really depends on what we want to use the TitleValue for: if we want to generate a link, it's nicer to have the namespace name. if we want to run a DB query, it's nicer to have the id. 22:12:15 &lt;aude&gt; doesn't make sense to mix them 22:12:29 &lt;DanielK_WMDE_&gt; TimStarling: no, it only ocurred to me recently. 22:12:33 &lt;TimStarling&gt; I think you can use integers for foreign titles, if you want to 22:12:57 &lt;TimStarling&gt; it is a bit more complicated than what we do now 22:13:01 &lt;DanielK_WMDE_&gt; TimStarling: but then how do you generate a link? you'd need to know the id-&gt;name mapping for the namespaces on the other wiki 22:13:11 &lt;TimStarling&gt; which is NS=0 DBK=&lt;foreign PDBK&gt; 22:13:19 &lt;brion&gt; DanielK_WMDE_: so we really can't do id-&gt;name or name-&gt;id mapping on foreign wikis without fetching their remote configuration 22:13:29 &lt;DanielK_WMDE_&gt; indeed 22:13:30 &lt;brion&gt; *nod* that's about how we handle interwikis now 22:13:31 &lt;TimStarling&gt; yes, I mean by fetching the remote configuration 22:14:19 &lt;DanielK_WMDE_&gt; on the other hand, there's nothing that forces us to not have a calss other than TitleValue to handle these cases. In factm I proposed WikiLink for this. 22:14:21 &lt;bawolff&gt; Interwikis also don't necessarily point to wikis 22:14:34 &lt;TimStarling&gt; DanielK_WMDE_: what do you think of Brad's criticism that TitleParser and TitleFormatter could be the same class? 22:14:50 &lt;DanielK_WMDE_&gt; yes, that would only work for other mediawiki instances. so perhaps a WikiLink class would be more useful for that. 22:15:31 &lt;DanielK_WMDE_&gt; TimStarling: i think the *interfaces* should be independent, but they could be implemented by the same class. 22:15:33 &lt;TimStarling&gt; I think interwiki links to non-wikis were a terrible mistake 22:15:39 &lt;TimStarling&gt; in fact, I think the whole interwiki feature sucks 22:15:43 &lt;DanielK_WMDE_&gt; but code using these should not *rely* on them being implemented by the same class or object 22:15:44 &lt;TimStarling&gt; but maybe that's a rant for another day 22:15:45 &lt;aude&gt; +1 seems weird to represent non-mediawiki &quot;titles&quot; with title values 22:16:03 * brion hmms 22:16:14 &lt;csteipp&gt; I actually support Brad in that. Both the parsing and the formatting will have a security component, and I'd rather *not* see the security distributed across many objects. 22:16:20 &lt;brion&gt; i hate to suggest Interfaces but .... could we have TitleVaue and ForeignTitle? or is that way MADNESS 22:17:05 &lt;brion&gt; so I'd tend to wrap TitleParser and TitleFormatter together also 22:17:06 &lt;TimStarling&gt; what do we use foreign titles for at the moment? 22:17:09 &lt;DanielK_WMDE_&gt; brion: ForeignTitle is pretty much what i ment when i wrote this into the rfc: &quot;a WikiLink class with subclasses for internal links, interwiki links, and external links.&quot; 22:17:16 &lt;aude&gt; TimStarling: extensively with wikibase 22:17:38 &lt;DanielK_WMDE_&gt; aude: using our own (Simple)SiteLink class. 22:18:10 &lt;TimStarling&gt; aude: you use Title objects with interwiki prefixes in wikibase? 22:18:11 &lt;aude&gt; DanielK_WMDE_: figuring out the namespace for the link is the tricky part 22:18:17 &lt;DanielK_WMDE_&gt; TimStarling: im'n not sure how often Title objects are used to represent interwiki links... but the introduction of TitleValue wouldn't hinder that. 22:18:23 &lt;AaronSchulz&gt; brion: seems like they could be one yeah 22:18:38 &lt;aude&gt; TimStarling: we use site links 22:18:53 &lt;DanielK_WMDE_&gt; aude: if you only have the ID from a db query, then yes. 22:19:01 &lt;DanielK_WMDE_&gt; but that's not what TitleValue is about 22:19:10 &lt;TimStarling&gt; when I say a foreign title, I mean a Title object with mInterwiki !== '' 22:19:14 &lt;aude&gt; site link = site id + page name 22:19:27 &lt;TimStarling&gt; they are traditionally used by the parser 22:19:40 &lt;TimStarling&gt; I mean, Title::secureAndSplit is basically a parser outgrowth 22:20:28 &lt;TimStarling&gt; I'm just wondering if we really need foreign Title objects at all 22:20:34 &lt;brion&gt; so title components are traditionally (interwiki:)?(namespace:)?(text)(#hash)? 22:20:35 &lt;DanielK_WMDE_&gt; TimStarling: this could go into a TitleParser implementation. Though the TitleParser interface only defines parsing of *local* links. 22:20:39 &lt;aude&gt; i suppose the site links do store the full page title 22:20:42 &lt;brion&gt; where if there's an interwiki, we don't really fiddle with namespaces 22:20:47 &lt;aude&gt; e.g. Category:Berlin 22:20:53 &lt;brion&gt; it's funky but you can kinda think of an interwiki as an extended namespace :) 22:20:55 &lt;TimStarling&gt; or if we can use an object to represent foreign titles that is not derived from Title 22:21:42 &lt;TimStarling&gt; brion: yes 22:21:57 &lt;TimStarling&gt; that is basically a little fragment of the wikitext grammar, displaced from Parser to Title 22:22:00 &lt;brion&gt; i guess the ultimate question is &quot;what do we need to slot in to the spaces that are normally local title objects&quot; 22:22:08 &lt;DanielK_WMDE_&gt; TimStarling: in my mind, that would not really be a &quot;title&quot; (since we can#t normalize it), but rather a &quot;link&quot;. but whatever :) 22:22:14 &lt;aude&gt; separating interwiki links from title seems good 22:22:21 &lt;brion&gt; hmm, i like that 22:22:23 &lt;aude&gt; keeping title simple, for local links 22:23:11 &lt;brion&gt; yes i can be convinced of that 22:23:22 &lt;DanielK_WMDE_&gt; i think we are getting a bit sidetracked with the interwiki stuff. TitleValue is about local links only. Let's worry about interwiki links another time. 22:23:30 &lt;aude&gt; +1 22:23:39 &lt;brion&gt; keep core title down to local (namespace,title) pair, which is something we pass around and store as a unit *all the time* 22:23:52 &lt;brion&gt; and leave interwikis and hashes to future link objects where they're actually needed 22:24:26 &lt;MaxSem&gt; i.e. in old Title for now? 22:24:33 &lt;brion&gt; MaxSem: yes 22:24:37 &lt;DanielK_WMDE_&gt; exactly 22:24:49 &lt;DanielK_WMDE_&gt; so, to get back on track: the main criticism seems to be &quot;but then we need to pass around the pesky Parser/Formatter objects everywhere&quot;. 22:24:55 &lt;brion&gt; so that mostly leaves the parser/formatter and registry questions 22:25:05 &lt;brion&gt; easy answer: put them on IContext 22:25:12 &lt;MaxSem&gt; oh noes 22:25:14 &lt;brion&gt; which we already pass around everywhere ;) 22:25:15 &lt;DanielK_WMDE_&gt; i can only say to that &quot;yes, but that's really a good thing, and not as annyoing as you might think&quot;. 22:25:26 &lt;TimStarling&gt; I think there was some concern on the mailing list about how much code will be touched by the Title -&gt; TitleFormatter/TitleParser migration 22:25:33 &lt;MaxSem&gt; it'll grow to be the next god object that we'll need to slaughter 22:25:41 &lt;DanielK_WMDE_&gt; TimStarling: tons and tons, if we do everythign at once 22:25:45 &lt;DanielK_WMDE_&gt; but there's absolutely no need to 22:25:50 &lt;^d&gt; We never really needed IContext. We should've just kept $mediaWiki global ;-) 22:25:51 &lt;DanielK_WMDE_&gt; TitleValue and Title can easily co-exist 22:25:52 &lt;brion&gt; i think we should explicitly *not* do it all at once, yes 22:26:13 &lt;brion&gt; make sure it's easy to get a TitleValue from a Title and vice-versa 22:26:16 &lt;DanielK_WMDE_&gt; brion: so, tons of stuff depend on IContext. This means, to avoid a tangle, IContext should depend on as little as possible. 22:26:18 &lt;TimStarling&gt; we should at least have a sample though 22:26:20 &lt;brion&gt; and start building new interfaces on TitleValue 22:26:31 &lt;TimStarling&gt; so we know what we're getting ourselves in for 22:26:34 &lt;brion&gt; yeah 22:26:46 &lt;brion&gt; anyone have a module they'd like to volunteer for migration ? :) 22:26:55 &lt;DanielK_WMDE_&gt; brion: otherwise, you cet this: to construct X, you need an IContext. To construct an IContext, you need A, B, C, D, E, F, ..... Q, R... 22:27:15 &lt;DanielK_WMDE_&gt; sure, you could null/stub some out, but you then need to know in advance which parts of IContext X actually uses. 22:27:17 &lt;DanielK_WMDE_&gt; not nice 22:27:17 &lt;qgil&gt; #help anyone have a module they'd like to volunteer for migration ? :) 22:27:30 &lt;TimStarling&gt; DanielK_WMDE_: RequestContext is constructible with no arguments, isn't it? 22:27:52 &lt;DanielK_WMDE_&gt; TimStarling: well, the &quot;arguments&quot; are global state. 22:27:58 &lt;TimStarling&gt; it doesn't even have a __construct 22:28:11 &lt;TimStarling&gt; it just uses mutators 22:28:12 &lt;DanielK_WMDE_&gt; which makes it worse: you have to know which global state to control or restore before constructing the context object 22:28:42 &lt;MaxSem&gt; the whole point of context that it *kill* global state 22:29:52 &lt;DanielK_WMDE_&gt; MaxSem: but what it currently does it *wrap* global state 22:29:55 &lt;brion&gt; so 22:29:56 &lt;ori-l&gt; $requestContext = &amp;$GLOBALS; /* DON'T LOOK AT ME */ 22:30:04 &lt;DanielK_WMDE_&gt; :P 22:30:13 &lt;brion&gt; imho the big win comes from separating the state/factory methods from the value object itself 22:30:34 &lt;MaxSem&gt; DanielK_WMDE_, that's only for main execution path, it doesn't have to 22:31:13 &lt;TimStarling&gt; brion: what do you think of my idea of having ServiceRegistry be a member of RequestContext? 22:31:29 &lt;DanielK_WMDE_&gt; MaxSem: yes. but it's hard to construct robust code for creating a &quot;celan&quot; RequestContext for e.g. testing. 22:31:42 &lt;DanielK_WMDE_&gt; and to do so, you'd have to create a ton of stuff you really don't need for your test. 22:31:47 &lt;TimStarling&gt; currently we have IContextSource, which can be implemented without much difficulty 22:31:55 &lt;brion&gt; TimStarling: that's probably what I'd do... otherwise we have a second global object we're passing around with some other method 22:32:01 &lt;TimStarling&gt; but if we have a hundred factory functions in it, it won't be so easy to implement 22:32:20 &lt;DanielK_WMDE_&gt; brion, TimStarling: the point of the registry thing is that it *doesn* get passed around. ever. 22:32:23 &lt;TimStarling&gt; but if you split out the hundred factory functions to their own class, it will still be possible to implement IContextSource from scratch 22:32:34 &lt;brion&gt; aho 22:32:37 * brion rereads 22:32:42 &lt;DanielK_WMDE_&gt; it's a small, isolated bit of state that gets used *only* in static entry points and is *never* a memebr of anything 22:32:46 &lt;aude&gt; DanielK_WMDE_: it'd be accessed statically? 22:32:52 &lt;DanielK_WMDE_&gt; nothing depends on it, so it's free to depend on the services it needs. 22:32:52 &lt;aude&gt; yeah.... 22:33:09 &lt;DanielK_WMDE_&gt; yes, it would. it's only purpose it to provide static access to the service objects 22:33:26 &lt;brion&gt; so my concern with that is it puts us back to having global state that you can't change locally 22:34:27 &lt;robla&gt; (just to note: we're over halfway through, and still on the first RFC. that's probably fine, but if anyone was dying to get to the other RFCs, they should speak up) 22:34:28 &lt;DanielK_WMDE_&gt; brion: yes, but it's used in *very* limited locations. all the real logic would not need global state, and would also not need any factories, registries, contexts - it would ask exactly for the services it needs, and nothing more 22:34:31 &lt;DanielK_WMDE_&gt; that's the idea 22:34:34 &lt;TimStarling&gt; DanielK_WMDE_: except that we have thousands of static entry points, by the obvious definition 22:34:40 &lt;DanielK_WMDE_&gt; that makes these components reusable and testable 22:34:58 &lt;TimStarling&gt; we have thousands of static and global functions that access global state 22:35:10 &lt;DanielK_WMDE_&gt; TimStarling: sure, no need to deal with all of them. deal just with the ones that have a need for creating an object that requires such a service. 22:35:49 &lt;TimStarling&gt; I'm concerned that you may be designing an architecture which would work well from scratch, but not so well for the MW core 22:35:52 &lt;DanielK_WMDE_&gt; basically, we'd convert component X to use TitleValue, and require the mentioned service objects. Then we'd use the registry in the static entry points that create an insteanc of X. 22:35:57 &lt;DanielK_WMDE_&gt; then we look at Y. and so on 22:36:05 &lt;DanielK_WMDE_&gt; no need for a hige migration or refactoring 22:36:49 &lt;TimStarling&gt; alright, so to wrap up for now... 22:36:57 &lt;qgil&gt; TimStarling, wait 22:37:00 &lt;brion&gt; so... my recommendation would be to prototype converting some stuff (limited area) and we can revisit this with some more experience 22:37:06 &lt;qgil&gt; please use #info in your summaries 22:37:07 &lt;MaxSem&gt; DanielK_WMDE_, that'll result in half of components requiring Title, another one - TitleValue 22:37:12 &lt;TimStarling&gt; brion: I was about to say that 22:37:12 &lt;DanielK_WMDE_&gt; TimStarling: the migration part is basically to push the need for accessing the static registry up the stack, towards the &quot;edges&quot; of the program, until, ideally, it's only done during initial bootstrapping. 22:37:20 &lt;MaxSem&gt; it'll be hard to glue them together 22:37:23 &lt;DanielK_WMDE_&gt; MaxSem: yes, that's exactly the idea. 22:37:30 &lt;DanielK_WMDE_&gt; no, why? 22:37:35 &lt;TimStarling&gt; if DanielK_WMDE_ can make a prototype without us agreeing to merge it, that would be a good outcome 22:37:35 &lt;DanielK_WMDE_&gt; it's easy to construct one from the other 22:37:41 &lt;brion&gt; MaxSem: not hard, just slightly ugly $title-&gt;asTitleValue etc 22:37:49 &lt;TimStarling&gt; then we can evaluate it at that point 22:37:50 &lt;brion&gt; data conversion \o/ 22:37:59 &lt;DanielK_WMDE_&gt; brion: indeed 22:38:30 &lt;DanielK_WMDE_&gt; TimStarling: i'd be willing to prototype this on a small module. say, a simple special page or api module 22:38:41 &lt;TimStarling&gt; ok 22:38:51 &lt;TimStarling&gt; I think that will help to focus discussions somewhat 22:38:56 &lt;DanielK_WMDE_&gt; (these however are bad examples, because it's hard to control their instantiation, and constructor parameters are fixed) 22:38:56 &lt;qgil&gt; #action by TimStarling: if DanielK_WMDE_ can make a prototype without us agreeing to merge it, that would be a good outcome. Then we can evaluate it at that point 22:39:11 &lt;TimStarling&gt; special pages are not so bad for constructor parameters etc. 22:39:25 &lt;TimStarling&gt; I was looking at their current implementations, they really don't have much global state anymore 22:39:26 &lt;qgil&gt; #info &lt;DanielK_WMDE_&gt; TimStarling: i'd be willing to prototype this on a small module. say, a simple special page or api module 22:39:50 &lt;qgil&gt; anything else about this topic before we move to the next? 22:40:07 &lt;DanielK_WMDE_&gt; brion, TimStarling: i gather that there's agreement on trying to use TitleValue instead of Title where possible, but concern about how to access the serives objects for parsing and formatting. the two options being a) IContext and b) a separate static registry that is not passed around. 22:40:19 &lt;brion&gt; *nod* 22:40:20 &lt;qgil&gt; Anything anybody wants to say about this topic with info&quot;before we move on? 22:40:42 &lt;qgil&gt; #info &lt;DanielK_WMDE_&gt; brion, TimStarling: i gather that there's agreement on trying to use TitleValue instead of Title where possible, but concern about how to access the serives objects for parsing and formatting. the two options being a) IContext and b) a separate static registry that is not passed around. 22:40:43 &lt;DanielK_WMDE_&gt; qgil: what i just said 22:40:48 &lt;qgil&gt; :) 22:40:49 &lt;DanielK_WMDE_&gt; exactly :) 22:41:09 &lt;qgil&gt; TimStarling, do you want to sttart a new topic? 22:41:14 &lt;TimStarling&gt; DanielK_WMDE_: I think that is fair 22:41:29 &lt;TimStarling&gt; do we have any other RFCs for which the proposer is present and interested in discussing it? 22:41:40 &lt;qgil&gt; Any official agreement about this point for the notes? 22:41:42 &lt;DanielK_WMDE_&gt; TimStarling: i'll request a week's coding time to work on this. 22:41:54 &lt;aude&gt; :) 22:41:56 &lt;qgil&gt; #info &lt;DanielK_WMDE_&gt; TimStarling: i'll request a week's coding time to work on this. 22:42:16 &lt;MaxSem&gt; ^d, configuration database? 22:42:17 &lt;qgil&gt; ok, new topic? 22:42:34 &lt;^d&gt; MaxSem: Tim said &quot;and interested in discussing&quot; ;-) 22:42:38 &lt;MaxSem&gt; lol 22:42:52 * robla orders Chad to be interested in configuration database :-P 22:43:02 &lt;brion&gt; i'd love to discuss the styling in templates but i'd want jon here for that 22:43:03 &lt;qgil&gt; #topic Configuration database 22:43:04 &lt;qgil&gt; there 22:43:10 &lt;qgil&gt; #link https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database 22:43:13 &lt;qgil&gt; :) 22:43:15 &lt;brion&gt; \o/ yay topic 22:43:28 &lt;csteipp&gt; (jon and matt aren't here, so styles and passwords are out) 22:43:33 &lt;TimStarling&gt; we can spend a little time on configuration database 22:43:59 &lt;TimStarling&gt; password requirements is really simple, we can probably approve that one without Matt here 22:44:07 &lt;DanielK_WMDE_&gt; i just added a comment on the talk page for the config db proposal 22:44:12 &lt;^d&gt; So, I've only got a couple thoughts on Config Mgmt that have really changed. 22:44:16 &lt;aude&gt; ^d: so it's basically like a settings class? 22:44:19 &lt;^d&gt; A) Don't put it in the database, that's dumb. 22:44:23 &lt;^d&gt; B) Singleton is evil 22:44:24 &lt;DanielK_WMDE_&gt; ...suggesting to store the configuration on wiki pages, not in separate database tables 22:44:35 &lt;^d&gt; Other than that, don't have much vested interest anymore. 22:44:38 &lt;AaronSchulz&gt; I assume this would start off with some pretty interface wrapping globals and then start changing it under the hood more 22:44:59 &lt;^d&gt; That was my idea originally. And I think my half-assed implementation did some of that. 22:45:12 &lt;brion&gt; DanielK_WMDE_: so depending on what config you store, that might ..... be a dependency problem. ;) 22:45:21 &lt;robla&gt; I think the Wikia folks are working on a proposal in this area 22:45:29 &lt;TimStarling&gt; what are you thinking of as an alternative to the singleton? 22:45:35 &lt;^d&gt; IContext. 22:45:36 &lt;TimStarling&gt; RequestContext member? 22:45:38 &lt;^d&gt; Yeah 22:45:47 &lt;DanielK_WMDE_&gt; brion: you mean for configuring the configuration management extension?... yea :) 22:45:50 &lt;qgil&gt; robla, Wikia folks like... OwynD ? 22:45:56 &lt;OwynD&gt; hey there 22:46:01 &lt;^d&gt; TimStarling: I have a proposed gerrit change to do that. 22:46:03 &lt;AaronSchulz&gt; RequestContext::getMain-&gt;getConfig-&gt;get( 'someVar' ); ;) 22:46:04 &lt;brion&gt; DanielK_WMDE_: or configuring the wiki page storage subsystem... 22:46:04 &lt;robla&gt; \o/ 22:46:06 &lt;TimStarling&gt; you know, my dream for RequestContext is to have the ability to have a RequestContext which operates on a foreign wiki 22:46:11 &lt;AaronSchulz&gt; totally no singleton there 22:46:11 &lt;DanielK_WMDE_&gt; ^d: kitchen sink objects are nearly as evil as singletons :) 22:46:18 &lt;MaxSem&gt; AaronSchulz, kill me please 22:46:26 &lt;TimStarling&gt; it would have namespace configuration, database factories, etc. and it would just work 22:46:31 &lt;^d&gt; DanielK_WMDE_: Meh. 22:46:37 * AaronSchulz grins 22:46:38 &lt;OwynD&gt; we have an extension called WikiFactory that basically does this for us. 22:46:39 * brion has this dream as well 22:46:47 &lt;^d&gt; Anyway, I'd like to underscore what I said about not really having any vested interest here. 22:46:54 * aude renames RequestContext to KitchenSink :D 22:46:55 &lt;^d&gt; I *really* don't care about this as much as I did 2+ years ago. 22:46:59 &lt;DanielK_WMDE_&gt; brion: well, db configuration has to be done first, of course. 22:47:08 &lt;OwynD&gt; it has a list of variables for each wiki and just injects them into the global namespace... 22:47:09 &lt;^d&gt; So if we intend to see it through to completion, we should find a new steward for the RFC. 22:47:10 &lt;TimStarling&gt; AaronSchulz: I think there is some cause for optimism 22:47:22 &lt;TimStarling&gt; like I say, look at the SpecialPage implementations these days 22:47:22 &lt;brion&gt; sounds like this RfC needs a new champion to push it through 22:47:26 &lt;legoktm&gt; brion: something won't be able to be configured in this configuration thing. mainly for sanity 22:47:29 &lt;OwynD&gt; so anything that is defined in config (including custom namespaces etc) just basically works 22:47:32 &lt;legoktm&gt; somethings* 22:47:33 &lt;brion&gt; again i think we should also narrow its focus 22:47:36 &lt;TimStarling&gt; no RequestContext::getMain there 22:47:41 &lt;brion&gt; maybe explicitly say 'this won't be used to configure the database' 22:47:50 &lt;robla&gt; #help Chad doesn't want to be the RFC champion for Configuration Database RFC. any takers? 22:47:53 &lt;brion&gt; and start with new settings or migrating something small 22:47:54 &lt;DanielK_WMDE_&gt; so, how about not trying to port all or most of the present config? 22:47:58 &lt;^d&gt; brion: Actually, it could configure everything. 22:48:06 &lt;^d&gt; My current thinking is pretty simple. 22:48:07 &lt;DanielK_WMDE_&gt; how about just introducing an additional/alternative config storage system? 22:48:12 &lt;^d&gt; LocalSettings.php -&gt; LocalSettings.json 22:48:15 &lt;^d&gt; For the default case. 22:48:21 &lt;AaronSchulz&gt; TimStarling: this would be a cause for avoiding utility classes in some cases more so 22:48:26 &lt;^d&gt; Something fancier for wiki farms. 22:48:39 &lt;AaronSchulz&gt; otherwise you get stuck passing Config into every little method 22:48:43 &lt;DanielK_WMDE_&gt; just start using it for some stuff. config can still be done in the old style, but could be overwritten by setting o nthe wiki, for some settings that are defined for this 22:49:05 &lt;qgil&gt; OwynD, https://www.mediawiki.org/wiki/Extension:WikiFactory ? 22:49:12 &lt;Platonides&gt; or if the wiki admin doesn't like using the database 22:49:14 &lt;AaronSchulz&gt; the more related things are grouped into objects (but not too big) the more manageable this is 22:49:16 &lt;DanielK_WMDE_&gt; AaronSchulz: or passing just the settings needed to every class. 22:49:17 &lt;^d&gt; So the best way to do this isn't actually having two config systems side by side. 22:49:18 &lt;DanielK_WMDE_&gt; ideally. 22:49:28 &lt;Platonides&gt; having it as an alternative config looks good 22:49:35 &lt;AaronSchulz&gt; Config gets passed from parent to child class in construction...which can work reasonably 22:49:49 &lt;DanielK_WMDE_&gt; ^d: then you'd need to migrate all code that accesses config globals all at once. otherwise, you'll have two systems. 22:49:51 &lt;OwynD&gt; yep, that's the one 22:49:57 &lt;^d&gt; DanielK_WMDE_: No, you don't. 22:49:59 &lt;TimStarling&gt; anyway, we are mostly dreaming if we don't have anyone to drive this 22:49:59 &lt;qgil&gt; #link https://www.mediawiki.org/wiki/Extension:WikiFactory 22:50:01 &lt;^d&gt; Have a fallback system. 22:50:07 &lt;legoktm&gt; I'd be willing to work on some of it 22:50:24 &lt;legoktm&gt; DanielK_WMDE_: There could be something like wgConf's extractAllGlobals 22:50:29 &lt;^d&gt; That ^ 22:50:31 &lt;TimStarling&gt; legoktm: maybe you should file your own RFC about it 22:50:41 &lt;TimStarling&gt; I think we could have competing RFCs 22:50:49 &lt;DanielK_WMDE_&gt; ^d: sure - that's what i suggested. have an new/extra system with for accessing config, and use that to override &quot;traditional&quot; settings. fall back on the old stuff. 22:50:59 &lt;AaronSchulz&gt; TimStarling: the one that sits there and the one that doesn't 22:50:59 &lt;qgil&gt; #info &lt;TimStarling&gt; anyway, we are mostly dreaming if we don't have anyone to drive this 22:51:02 &lt;OwynD&gt; we still have LocalSettings, DefaultSettings etc. 22:51:07 &lt;qgil&gt; #info &lt;legoktm&gt; I'd be willing to work on some of it 22:51:17 &lt;legoktm&gt; TimStarling: Ok, I'll try and find some time for it 22:51:23 &lt;OwynD&gt; our local settings has a call to that factory stuff at the right place to set all the custom vars for a wiki 22:51:38 &lt;TimStarling&gt; can we talk about password requirements? 22:51:48 &lt;AaronSchulz&gt; csteipp: [cough] 22:51:48 &lt;qgil&gt; #info &lt;OwynD&gt; we have an extension called WikiFactory that basically does this for us. 22:51:50 &lt;^d&gt; Anyway, the only last thing I'll say on the subject is this: it doesn't need to be an OMGREWRITE like I advocated forever. 22:52:00 &lt;^d&gt; It can be fixed incrementally. 22:52:09 &lt;^d&gt; SiteConfiguration is a good enough starting point we can iterate from. 22:52:12 &lt;qgil&gt; TimStarling, can you please summarize any resolution about the current topic, please? 22:52:17 &lt;csteipp&gt; Password requirements? I'm all for it. 22:52:22 &lt;^d&gt; (Trying to do OMGEVERYTHING sets this project up for failure) 22:52:23 &lt;^d&gt; &lt;/done&gt; 22:52:28 &lt;brion&gt; OwynD: can that be used to switch full configuration at runtime? I used a similar trick in StatusNet a few years ago to switch configs in background daemons 22:52:43 &lt;brion&gt; though that had fewer globals so was easier :D 22:53:09 &lt;TimStarling&gt; qgil: current RFC probably abandoned, legoktm to file new RFC 22:53:15 &lt;OwynD&gt; yep, i feel like that part is a bit &quot;sketchy&quot; but it does work. 22:53:23 &lt;qgil&gt; #info &lt;TimStarling&gt; qgil: current RFC probably abandoned, legoktm to file new RFC 22:53:28 &lt;OwynD&gt; for example we have to launch a maintenance script in a wiki context. 22:53:35 &lt;DanielK_WMDE_&gt; ^d: nicely put :) 22:53:39 &lt;OwynD&gt; so it has all the right variables defined. 22:53:51 &lt;qgil&gt; #topic Password requirements 22:53:55 &lt;TimStarling&gt; there are a couple of really simple features proposed here 22:54:00 &lt;qgil&gt; #link https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements 22:54:02 &lt;OwynD&gt; one of our developers wrote a wrapper for that which just resets the vars without restarting the maintenance script over again, and it does work. 22:54:04 &lt;brion&gt; OwynD: nice, i'll make a note to follow up on that for later :) 22:54:09 &lt;^d&gt; brion: Speaking of globals, $wgArticle doesn't exist anymore ;-) 22:54:16 &lt;csteipp&gt; Yep, I think it would be a very simple patch 22:54:21 &lt;TimStarling&gt; one is to make it so that increasing $wgMinimalPasswordLength doesn't break everything 22:54:22 &lt;brion&gt; \o/ 22:54:30 &lt;OwynD&gt; the code is really ugly, but it's here: just for what it's worth: https://github.com/Wikia/app/tree/dev/extensions/wikia/WikiFactory 22:54:36 &lt;TimStarling&gt; fine, hardly even needs an RFC 22:54:41 &lt;AaronSchulz&gt; brion: same here 22:54:43 &lt;TimStarling&gt; it's just a bug fix 22:54:52 &lt;csteipp&gt; Which makes me wonder, should we generalize it a little, and create a PasswordPolicy object, and start using that? 22:54:58 &lt;AaronSchulz&gt; we don't put all our bugs through RfC? 22:55:16 &lt;^d&gt; brion: https://gerrit.wikimedia.org/r/#/c/93106/ :p 22:55:25 &lt;brion&gt; \o/ 22:55:52 &lt;TimStarling&gt; various people are talking about character set requirements, but I'm not sure if that is actually proposed 22:56:08 &lt;TimStarling&gt; but if someone submitted that to gerrit, I would probably approve it 22:56:16 &lt;TimStarling&gt; since some admins like character set requirements 22:56:55 &lt;csteipp&gt; Only length was in the proposal, but expiration and charset could also be in there. Also, different people having a different policy (the second part of the rfc) 22:57:00 &lt;qgil&gt; #info &lt;TimStarling&gt; there are a couple of really simple features proposed here. One is to make it so that increasing $wgMinimalPasswordLength doesn't break everything. Fine, hardly even needs an RFC. 22:57:03 &lt;brion&gt; ok so do we just have the character limit setting, or are we also including password complexity requirements for groups? 22:57:44 &lt;MaxSem&gt; I fucking hate mandatory &quot;you must have at least one number and one uppercase char&quot;. though my passwords tend to comply:P 22:57:48 * qgil wonders whather you want/need a hard stop at o'clock, in 3 minutes. 22:57:50 &lt;bawolff&gt; +1 22:57:55 &lt;TimStarling&gt; yeah, password requirements for groups is not so simple 22:58:00 &lt;TimStarling&gt; but commonly requested 22:58:14 &lt;TimStarling&gt; I think there is a bug or changeset for it? 22:58:24 &lt;csteipp&gt; There is at least a bug for it 22:58:28 &lt;qgil&gt; #info &lt;csteipp&gt; Only length was in the proposal, but expiration and charset could also be in there. Also, different people having a different policy (the second part of the rfc) 22:58:42 &lt;csteipp&gt; I think Tyler took it out of the password api patch 22:58:44 * DanielK_WMDE_ 's password is knapsack. it's np hard. 22:58:48 &lt;TimStarling&gt; you would need to ask new admins to change their password on their first login after promotion 22:59:02 &lt;siebrand&gt; +1 for sticking to time boxes, qgil 22:59:22 &lt;TimStarling&gt; which is pretty simple once you have expiry and forced reset features 22:59:29 &lt;csteipp&gt; TimStarling: That gets easier if my password expiration gets in. If we see out of policy password, we expire their password, and they have X days to change it before they're force to reset it. 22:59:30 &lt;DanielK_WMDE_&gt; TimStarling: basically, if *any* user tried to log in, and the password matches but doesn't meet the requirements (for that user), make them set a new one. 22:59:35 &lt;DanielK_WMDE_&gt; should be simple 22:59:42 &lt;TimStarling&gt; you know the forced reset feature we need as a replacement for the hash leak response hack 23:00:00 * aude already was forced to reset my wikidata password 23:00:01 &lt;ori-l&gt; yes, i was just going to say 23:00:04 &lt;ori-l&gt; there's quite a lot of overlap 23:00:13 &lt;brion&gt; excellent 23:00:22 &lt;brion&gt; so that sounds feasible and not undesirable? 23:00:35 &lt;TimStarling&gt; so, what I would like from this RFC is for the discussion to be moved out to the talk page 23:00:52 &lt;qgil&gt; #info &lt;TimStarling&gt; so, what I would like from this RFC is for the discussion to be moved out to the talk page 23:01:24 &lt;qgil&gt; Is this the end of the meeting? 23:01:35 &lt;TimStarling&gt; almost 23:01:45 &lt;qgil&gt; anything else? 23:01:47 * aude yawns 23:01:50 &lt;TimStarling&gt; also, we would like expiration and forced reset to be part of the RFC 23:02:15 &lt;TimStarling&gt; since the code overlaps with the group requirements feature 23:02:24 &lt;TimStarling&gt; sound good csteipp? 23:02:46 &lt;ori-l&gt; qgil: http://git.wikimedia.org/blob/operations%2Fmediawiki-config.git/HEAD/wmf-config%2FBug54847.php is the hacky version, if you want to #link it 23:02:47 &lt;csteipp&gt; Yep. I'll talk with Matt about adding that in. One of us can do that, I'm sure. 23:02:59 &lt;TimStarling&gt; I think once the document is cleaned up, we can just accept it 23:03:07 &lt;TimStarling&gt; since the mediawiki feature is pretty uncontroversial 23:03:08 &lt;qgil&gt; #action Password requirements: &lt;TimStarling&gt; what I would like from this RFC is for the discussion to be moved out to the talk page. Also, we would like expiration and forced reset to be part of the RFC 23:03:15 &lt;TimStarling&gt; the controversial part of this is the WMF configuration 23:03:18 &lt;qgil&gt; #link http://git.wikimedia.org/blob/operations%2Fmediawiki-config.git/HEAD/wmf-config%2FBug54847.php 23:03:34 &lt;ori-l&gt; thanks :) 23:03:36 &lt;csteipp&gt; #link https://gerrit.wikimedia.org/r/#/c/92037/ the much cleaner version of ^ 23:03:47 &lt;qgil&gt; ori-l, you can also type link, info, etc yourselves 23:04:10 &lt;qgil&gt; end of meeting? 23:04:11 * DanielK_WMDE_ randomly wonders if something that is both a formatter and a parser is a &quot;forser&quot;. 23:04:46 &lt;TimStarling&gt; qgil: yes 23:04:51 &lt;qgil&gt; #info Thank you everybody! The plan is to keep having these meetings every other week. 23:04:52 &lt;qgil&gt; #endmeeting