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

From MediaWiki.org
Jump to navigation Jump to search

Intro[edit]

TitleValue[edit]

  • 22:05:43 <qgil> #topic TitleValue
  • 22:05:58 <bd808> #link https://www.mediawiki.org/wiki/Requests_for_comment/TitleValue
  • 22:06:45 <DanielK_WMDE_> hm, am i supposed to say something about TitleValue now?
  • 22:06:47 <TimStarling> were there any unresolved issues from the mailing list discussion that anyone would like to raise now?
  • 22:06:47 <qgil> (thank you bd808 - fyi everybody, if you want a sentence to appear in the notes, start with #info bla bla )
  • 22:06:59 <^d> TimStarling: Yes, one of the major unresolved issues was serialization.
  • 22:07:05 <brion> 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 <DanielK_WMDE_> I found https://wiki.debian.org/MeetBot useful
  • 22:07:11 <^d> I think there was some unresolved question as to how we'd store namespaces.
  • 22:07:20 <^d> Whether it'd be an int, or the canonical name, etc.
  • 22:07:39 <TimStarling> what would you use serialization for?
  • 22:08:33 <brion> other than 'happening to be a member of an object that gets serialized' ?
  • 22:08:55 <TimStarling> we don't really serialize objects very often
  • 22:09:26 <DanielK_WMDE_> serialization is not the point
  • 22:09:50 <TimStarling> as for integer versus canonical namespace, integer seems the obvious choice to me
  • 22:09:54 <DanielK_WMDE_> 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 <brion> i'd say there's two prime possibilities:
  • 22:10:08 <brion> 1) use the integer key
  • 22:10:09 <TimStarling> since everything about a namespace can easily be determined from its integer ID
  • 22:10:13 <brion> 2) use a MWNamespace object
  • 22:10:13 <DanielK_WMDE_> but in reality, Title relies on a bunch of things - and thus, everything depends on everything.
  • 22:10:20 <DanielK_WMDE_> This turns mediaWiki into a monolithic tangle.
  • 22:10:33 <brion> but life is simplest if we just store an int eh :D
  • 22:10:54 <^d> I'm fine with ints too :)
  • 22:11:02 * MaxSem scrolls to the bottom of Tite.php and sees getEditNotices():/
  • 22:11:10 <TimStarling> MWNamespace depends on everything, right?
  • 22:11:30 <DanielK_WMDE_> using a canonical namespace has the advantage that we can meaningfully represent titles from other wikis
  • 22:11:34 <DanielK_WMDE_> with IDs, we can't do that
  • 22:11:58 <MaxSem> I think we'll end up storing title proper, ns number and ns string
  • 22:12:09 <aude> MWNamespace is a utility class
  • 22:12:14 <TimStarling> DanielK_WMDE_: that application is not discussed on the RFC, is it?
  • 22:12:14 <DanielK_WMDE_> 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 <aude> doesn't make sense to mix them
  • 22:12:29 <DanielK_WMDE_> TimStarling: no, it only ocurred to me recently.
  • 22:12:33 <TimStarling> I think you can use integers for foreign titles, if you want to
  • 22:12:57 <TimStarling> it is a bit more complicated than what we do now
  • 22:13:01 <DanielK_WMDE_> TimStarling: but then how do you generate a link? you'd need to know the id->name mapping for the namespaces on the other wiki
  • 22:13:11 <TimStarling> which is NS=0 DBK=<foreign PDBK>
  • 22:13:19 <brion> DanielK_WMDE_: so we really can't do id->name or name->id mapping on foreign wikis without fetching their remote configuration
  • 22:13:29 <DanielK_WMDE_> indeed
  • 22:13:30 <brion> *nod* that's about how we handle interwikis now
  • 22:13:31 <TimStarling> yes, I mean by fetching the remote configuration
  • 22:14:19 <DanielK_WMDE_> 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 <bawolff> Interwikis also don't necessarily point to wikis
  • 22:14:34 <TimStarling> DanielK_WMDE_: what do you think of Brad's criticism that TitleParser and TitleFormatter could be the same class?
  • 22:14:50 <DanielK_WMDE_> yes, that would only work for other mediawiki instances. so perhaps a WikiLink class would be more useful for that.
  • 22:15:31 <DanielK_WMDE_> TimStarling: i think the *interfaces* should be independent, but they could be implemented by the same class.
  • 22:15:33 <TimStarling> I think interwiki links to non-wikis were a terrible mistake
  • 22:15:39 <TimStarling> in fact, I think the whole interwiki feature sucks
  • 22:15:43 <DanielK_WMDE_> but code using these should not *rely* on them being implemented by the same class or object
  • 22:15:44 <TimStarling> but maybe that's a rant for another day
  • 22:15:45 <aude> +1 seems weird to represent non-mediawiki "titles" with title values
  • 22:16:03 * brion hmms
  • 22:16:14 <csteipp> 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 <brion> i hate to suggest Interfaces but .... could we have TitleVaue and ForeignTitle? or is that way MADNESS
  • 22:17:05 <brion> so I'd tend to wrap TitleParser and TitleFormatter together also
  • 22:17:06 <TimStarling> what do we use foreign titles for at the moment?
  • 22:17:09 <DanielK_WMDE_> brion: ForeignTitle is pretty much what i ment when i wrote this into the rfc: "a WikiLink class with subclasses for internal links, interwiki links, and external links."
  • 22:17:16 <aude> TimStarling: extensively with wikibase
  • 22:17:38 <DanielK_WMDE_> aude: using our own (Simple)SiteLink class.
  • 22:18:10 <TimStarling> aude: you use Title objects with interwiki prefixes in wikibase?
  • 22:18:11 <aude> DanielK_WMDE_: figuring out the namespace for the link is the tricky part
  • 22:18:17 <DanielK_WMDE_> 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 <AaronSchulz> brion: seems like they could be one yeah
  • 22:18:38 <aude> TimStarling: we use site links
  • 22:18:53 <DanielK_WMDE_> aude: if you only have the ID from a db query, then yes.
  • 22:19:01 <DanielK_WMDE_> but that's not what TitleValue is about
  • 22:19:10 <TimStarling> when I say a foreign title, I mean a Title object with mInterwiki !==
  • 22:19:14 <aude> site link = site id + page name
  • 22:19:27 <TimStarling> they are traditionally used by the parser
  • 22:19:40 <TimStarling> I mean, Title::secureAndSplit() is basically a parser outgrowth
  • 22:20:28 <TimStarling> I'm just wondering if we really need foreign Title objects at all
  • 22:20:34 <brion> so title components are traditionally (interwiki:)?(namespace:)?(text)(#hash)?
  • 22:20:35 <DanielK_WMDE_> TimStarling: this could go into a TitleParser implementation. Though the TitleParser interface only defines parsing of *local* links.
  • 22:20:39 <aude> i suppose the site links do store the full page title
  • 22:20:42 <brion> where if there's an interwiki, we don't really fiddle with namespaces
  • 22:20:47 <aude> e.g. Category:Berlin
  • 22:20:53 <brion> it's funky but you can kinda think of an interwiki as an extended namespace :)
  • 22:20:55 <TimStarling> or if we can use an object to represent foreign titles that is not derived from Title
  • 22:21:42 <TimStarling> brion: yes
  • 22:21:57 <TimStarling> that is basically a little fragment of the wikitext grammar, displaced from Parser to Title
  • 22:22:00 <brion> i guess the ultimate question is "what do we need to slot in to the spaces that are normally local title objects"
  • 22:22:08 <DanielK_WMDE_> TimStarling: in my mind, that would not really be a "title" (since we can#t normalize it), but rather a "link". but whatever :)
  • 22:22:14 <aude> separating interwiki links from title seems good
  • 22:22:21 <brion> hmm, i like that
  • 22:22:23 <aude> keeping title simple, for local links
  • 22:23:11 <brion> yes i can be convinced of that
  • 22:23:22 <DanielK_WMDE_> 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 <aude> +1
  • 22:23:39 <brion> 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 <brion> and leave interwikis and hashes to future link objects where they're actually needed
  • 22:24:26 <MaxSem> i.e. in old Title for now?
  • 22:24:33 <brion> MaxSem: yes
  • 22:24:37 <DanielK_WMDE_> exactly
  • 22:24:49 <DanielK_WMDE_> so, to get back on track: the main criticism seems to be "but then we need to pass around the pesky Parser/Formatter objects everywhere".
  • 22:24:55 <brion> so that mostly leaves the parser/formatter and registry questions
  • 22:25:05 <brion> easy answer: put them on IContext
  • 22:25:12 <MaxSem> oh noes
  • 22:25:14 <brion> which we already pass around everywhere ;)
  • 22:25:15 <DanielK_WMDE_> i can only say to that "yes, but that's really a good thing, and not as annyoing as you might think".
  • 22:25:26 <TimStarling> I think there was some concern on the mailing list about how much code will be touched by the Title -> TitleFormatter/TitleParser migration
  • 22:25:33 <MaxSem> it'll grow to be the next god object that we'll need to slaughter
  • 22:25:41 <DanielK_WMDE_> TimStarling: tons and tons, if we do everythign at once
  • 22:25:45 <DanielK_WMDE_> but there's absolutely no need to
  • 22:25:50 <^d> We never really needed IContext. We should've just kept $mediaWiki global ;-)
  • 22:25:51 <DanielK_WMDE_> TitleValue and Title can easily co-exist
  • 22:25:52 <brion> i think we should explicitly *not* do it all at once, yes
  • 22:26:13 <brion> make sure it's easy to get a TitleValue from a Title and vice-versa
  • 22:26:16 <DanielK_WMDE_> 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 <TimStarling> we should at least have a sample though
  • 22:26:20 <brion> and start building new interfaces on TitleValue
  • 22:26:31 <TimStarling> so we know what we're getting ourselves in for
  • 22:26:34 <brion> yeah
  • 22:26:46 <brion> anyone have a module they'd like to volunteer for migration ? :)
  • 22:26:55 <DanielK_WMDE_> 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 <DanielK_WMDE_> 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 <DanielK_WMDE_> not nice
  • 22:27:17 <qgil> #help anyone have a module they'd like to volunteer for migration ? :)
  • 22:27:30 <TimStarling> DanielK_WMDE_: RequestContext is constructible with no arguments, isn't it?
  • 22:27:52 <DanielK_WMDE_> TimStarling: well, the "arguments" are global state.
  • 22:27:58 <TimStarling> it doesn't even have a __construct()
  • 22:28:11 <TimStarling> it just uses mutators
  • 22:28:12 <DanielK_WMDE_> which makes it worse: you have to know which global state to control or restore before constructing the context object
  • 22:28:42 <MaxSem> the whole point of context that it *kill* global state
  • 22:29:52 <DanielK_WMDE_> MaxSem: but what it currently does it *wrap* global state
  • 22:29:55 <brion> so
  • 22:29:56 <ori-l> $requestContext = &$GLOBALS; /* DON'T LOOK AT ME */
  • 22:30:04 <DanielK_WMDE_> :P
  • 22:30:13 <brion> imho the big win comes from separating the state/factory methods from the value object itself
  • 22:30:34 <MaxSem> DanielK_WMDE_, that's only for main execution path, it doesn't have to
  • 22:31:13 <TimStarling> brion: what do you think of my idea of having ServiceRegistry be a member of RequestContext?
  • 22:31:29 <DanielK_WMDE_> MaxSem: yes. but it's hard to construct robust code for creating a "celan" RequestContext for e.g. testing.
  • 22:31:42 <DanielK_WMDE_> and to do so, you'd have to create a ton of stuff you really don't need for your test.
  • 22:31:47 <TimStarling> currently we have IContextSource, which can be implemented without much difficulty
  • 22:31:55 <brion> 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 <TimStarling> but if we have a hundred factory functions in it, it won't be so easy to implement
  • 22:32:20 <DanielK_WMDE_> brion, TimStarling: the point of the registry thing is that it *doesn* get passed around. ever.
  • 22:32:23 <TimStarling> 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 <brion> aho
  • 22:32:37 * brion rereads
  • 22:32:42 <DanielK_WMDE_> 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 <aude> DanielK_WMDE_: it'd be accessed statically?
  • 22:32:52 <DanielK_WMDE_> nothing depends on it, so it's free to depend on the services it needs.
  • 22:32:52 <aude> yeah....
  • 22:33:09 <DanielK_WMDE_> yes, it would. it's only purpose it to provide static access to the service objects
  • 22:33:26 <brion> so my concern with that is it puts us back to having global state that you can't change locally
  • 22:34:27 <robla> (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 <DanielK_WMDE_> 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 <DanielK_WMDE_> that's the idea
  • 22:34:34 <TimStarling> DanielK_WMDE_: except that we have thousands of static entry points, by the obvious definition
  • 22:34:40 <DanielK_WMDE_> that makes these components reusable and testable
  • 22:34:58 <TimStarling> we have thousands of static and global functions that access global state
  • 22:35:10 <DanielK_WMDE_> 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 <TimStarling> 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 <DanielK_WMDE_> 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 <DanielK_WMDE_> then we look at Y. and so on
  • 22:36:05 <DanielK_WMDE_> no need for a hige migration or refactoring
  • 22:36:49 <TimStarling> alright, so to wrap up for now...
  • 22:36:57 <qgil> TimStarling, wait
  • 22:37:00 <brion> so... my recommendation would be to prototype converting some stuff (limited area) and we can revisit this with some more experience
  • 22:37:06 <qgil> please use #info in your summaries
  • 22:37:07 <MaxSem> DanielK_WMDE_, that'll result in half of components requiring Title, another one - TitleValue
  • 22:37:12 <TimStarling> brion: I was about to say that
  • 22:37:12 <DanielK_WMDE_> TimStarling: the migration part is basically to push the need for accessing the static registry up the stack, towards the "edges" of the program, until, ideally, it's only done during initial bootstrapping.
  • 22:37:20 <MaxSem> it'll be hard to glue them together
  • 22:37:23 <DanielK_WMDE_> MaxSem: yes, that's exactly the idea.
  • 22:37:30 <DanielK_WMDE_> no, why?
  • 22:37:35 <TimStarling> if DanielK_WMDE_ can make a prototype without us agreeing to merge it, that would be a good outcome
  • 22:37:35 <DanielK_WMDE_> it's easy to construct one from the other
  • 22:37:41 <brion> MaxSem: not hard, just slightly ugly $title->asTitleValue() etc
  • 22:37:49 <TimStarling> then we can evaluate it at that point
  • 22:37:50 <brion> data conversion \o/
  • 22:37:59 <DanielK_WMDE_> brion: indeed
  • 22:38:30 <DanielK_WMDE_> TimStarling: i'd be willing to prototype this on a small module. say, a simple special page or api module
  • 22:38:41 <TimStarling> ok
  • 22:38:51 <TimStarling> I think that will help to focus discussions somewhat
  • 22:38:56 <DanielK_WMDE_> (these however are bad examples, because it's hard to control their instantiation, and constructor parameters are fixed)
  • 22:38:56 <qgil> #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 <TimStarling> special pages are not so bad for constructor parameters etc.
  • 22:39:25 <TimStarling> I was looking at their current implementations, they really don't have much global state anymore
  • 22:39:26 <qgil> #info <DanielK_WMDE_> TimStarling: i'd be willing to prototype this on a small module. say, a simple special page or api module
  • 22:39:50 <qgil> anything else about this topic before we move to the next?
  • 22:40:07 <DanielK_WMDE_> 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 <brion> *nod*
  • 22:40:20 <qgil> Anything anybody wants to say about this topic with info"before we move on?
  • 22:40:42 <qgil> #info <DanielK_WMDE_> 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 <DanielK_WMDE_> qgil: what i just said
  • 22:40:48 <qgil> :)
  • 22:40:49 <DanielK_WMDE_> exactly :)
  • 22:41:09 <qgil> TimStarling, do you want to sttart a new topic?
  • 22:41:14 <TimStarling> DanielK_WMDE_: I think that is fair
  • 22:41:29 <TimStarling> do we have any other RFCs for which the proposer is present and interested in discussing it?
  • 22:41:40 <qgil> Any official agreement about this point for the notes?
  • 22:41:42 <DanielK_WMDE_> TimStarling: i'll request a week's coding time to work on this.
  • 22:41:54 <aude> :)
  • 22:41:56 <qgil> #info <DanielK_WMDE_> TimStarling: i'll request a week's coding time to work on this.
  • 22:42:16 <MaxSem> ^d, configuration database?
  • 22:42:17 <qgil> ok, new topic?
  • 22:42:34 <^d> MaxSem: Tim said "and interested in discussing" ;-)
  • 22:42:38 <MaxSem> lol
  • 22:42:52 * robla orders Chad to be interested in configuration database :-P
  • 22:43:02 <brion> i'd love to discuss the styling in templates but i'd want jon here for that

Configuration database[edit]

  • 22:43:03 <qgil> #topic Configuration database
  • 22:43:04 <qgil> there
  • 22:43:10 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database
  • 22:43:13 <qgil> :)
  • 22:43:15 <brion> \o/ yay topic
  • 22:43:28 <csteipp> (jon and matt aren't here, so styles and passwords are out)
  • 22:43:33 <TimStarling> we can spend a little time on configuration database
  • 22:43:59 <TimStarling> password requirements is really simple, we can probably approve that one without Matt here
  • 22:44:07 <DanielK_WMDE_> i just added a comment on the talk page for the config db proposal
  • 22:44:12 <^d> So, I've only got a couple thoughts on Config Mgmt that have really changed.
  • 22:44:16 <aude> ^d: so it's basically like a settings class?
  • 22:44:19 <^d> A) Don't put it in the database, that's dumb.
  • 22:44:23 <^d> B) Singleton is evil
  • 22:44:24 <DanielK_WMDE_> ...suggesting to store the configuration on wiki pages, not in separate database tables
  • 22:44:35 <^d> Other than that, don't have much vested interest anymore.
  • 22:44:38 <AaronSchulz> I assume this would start off with some pretty interface wrapping globals and then start changing it under the hood more
  • 22:44:59 <^d> That was my idea originally. And I think my half-assed implementation did some of that.
  • 22:45:12 <brion> DanielK_WMDE_: so depending on what config you store, that might ..... be a dependency problem. ;)
  • 22:45:21 <robla> I think the Wikia folks are working on a proposal in this area
  • 22:45:29 <TimStarling> what are you thinking of as an alternative to the singleton?
  • 22:45:35 <^d> IContext.
  • 22:45:36 <TimStarling> RequestContext member?
  • 22:45:38 <^d> Yeah
  • 22:45:47 <DanielK_WMDE_> brion: you mean for configuring the configuration management extension?... yea :)
  • 22:45:50 <qgil> robla, Wikia folks like... OwynD ?
  • 22:45:56 <OwynD> hey there
  • 22:46:01 <^d> TimStarling: I have a proposed gerrit change to do that.
  • 22:46:03 <AaronSchulz> RequestContext::getMain()->getConfig()->get( 'someVar' ); ;)
  • 22:46:04 <brion> DanielK_WMDE_: or configuring the wiki page storage subsystem...
  • 22:46:04 <robla> \o/
  • 22:46:06 <TimStarling> you know, my dream for RequestContext is to have the ability to have a RequestContext which operates on a foreign wiki
  • 22:46:11 <AaronSchulz> totally no singleton there
  • 22:46:11 <DanielK_WMDE_> ^d: kitchen sink objects are nearly as evil as singletons :)
  • 22:46:18 <MaxSem> AaronSchulz, kill me please
  • 22:46:26 <TimStarling> it would have namespace configuration, database factories, etc. and it would just work
  • 22:46:31 <^d> DanielK_WMDE_: Meh.
  • 22:46:37 * AaronSchulz grins
  • 22:46:38 <OwynD> we have an extension called WikiFactory that basically does this for us.
  • 22:46:39 * brion has this dream as well
  • 22:46:47 <^d> 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 <^d> I *really* don't care about this as much as I did 2+ years ago.
  • 22:46:59 <DanielK_WMDE_> brion: well, db configuration has to be done first, of course.
  • 22:47:08 <OwynD> it has a list of variables for each wiki and just injects them into the global namespace...
  • 22:47:09 <^d> So if we intend to see it through to completion, we should find a new steward for the RFC.
  • 22:47:10 <TimStarling> AaronSchulz: I think there is some cause for optimism
  • 22:47:22 <TimStarling> like I say, look at the SpecialPage implementations these days
  • 22:47:22 <brion> sounds like this RfC needs a new champion to push it through
  • 22:47:26 <legoktm> brion: something won't be able to be configured in this configuration thing. mainly for sanity
  • 22:47:29 <OwynD> so anything that is defined in config (including custom namespaces etc) just basically works
  • 22:47:32 <legoktm> somethings*
  • 22:47:33 <brion> again i think we should also narrow its focus
  • 22:47:36 <TimStarling> no RequestContext::getMain() there
  • 22:47:41 <brion> maybe explicitly say 'this won't be used to configure the database'
  • 22:47:50 <robla> #help Chad doesn't want to be the RFC champion for Configuration Database RFC. any takers?
  • 22:47:53 <brion> and start with new settings or migrating something small
  • 22:47:54 <DanielK_WMDE_> so, how about not trying to port all or most of the present config?
  • 22:47:58 <^d> brion: Actually, it could configure everything.
  • 22:48:06 <^d> My current thinking is pretty simple.
  • 22:48:07 <DanielK_WMDE_> how about just introducing an additional/alternative config storage system?
  • 22:48:12 <^d> LocalSettings.php -> LocalSettings.json
  • 22:48:15 <^d> For the default case.
  • 22:48:21 <AaronSchulz> TimStarling: this would be a cause for avoiding utility classes in some cases more so
  • 22:48:26 <^d> Something fancier for wiki farms.
  • 22:48:39 <AaronSchulz> otherwise you get stuck passing Config into every little method
  • 22:48:43 <DanielK_WMDE_> 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 <qgil> OwynD, https://www.mediawiki.org/wiki/Extension:WikiFactory ?
  • 22:49:12 <Platonides> or if the wiki admin doesn't like using the database
  • 22:49:14 <AaronSchulz> the more related things are grouped into objects (but not too big) the more manageable this is
  • 22:49:16 <DanielK_WMDE_> AaronSchulz: or passing just the settings needed to every class.
  • 22:49:17 <^d> So the best way to do this isn't actually having two config systems side by side.
  • 22:49:18 <DanielK_WMDE_> ideally.
  • 22:49:28 <Platonides> having it as an alternative config looks good
  • 22:49:35 <AaronSchulz> Config gets passed from parent to child class in construction...which can work reasonably
  • 22:49:49 <DanielK_WMDE_> ^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 <OwynD> yep, that's the one
  • 22:49:57 <^d> DanielK_WMDE_: No, you don't.
  • 22:49:59 <TimStarling> anyway, we are mostly dreaming if we don't have anyone to drive this
  • 22:49:59 <qgil> #link https://www.mediawiki.org/wiki/Extension:WikiFactory
  • 22:50:01 <^d> Have a fallback system.
  • 22:50:07 <legoktm> I'd be willing to work on some of it
  • 22:50:24 <legoktm> DanielK_WMDE_: There could be something like wgConf's extractAllGlobals()
  • 22:50:29 <^d> That ^
  • 22:50:31 <TimStarling> legoktm: maybe you should file your own RFC about it
  • 22:50:41 <TimStarling> I think we could have competing RFCs
  • 22:50:49 <DanielK_WMDE_> ^d: sure - that's what i suggested. have an new/extra system with for accessing config, and use that to override "traditional" settings. fall back on the old stuff.
  • 22:50:59 <AaronSchulz> TimStarling: the one that sits there and the one that doesn't
  • 22:50:59 <qgil> #info <TimStarling> anyway, we are mostly dreaming if we don't have anyone to drive this
  • 22:51:02 <OwynD> we still have LocalSettings, DefaultSettings etc.
  • 22:51:07 <qgil> #info <legoktm> I'd be willing to work on some of it
  • 22:51:17 <legoktm> TimStarling: Ok, I'll try and find some time for it
  • 22:51:23 <OwynD> 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 <TimStarling> can we talk about password requirements?
  • 22:51:48 <AaronSchulz> csteipp: [cough]
  • 22:51:48 <qgil> #info <OwynD> we have an extension called WikiFactory that basically does this for us.
  • 22:51:50 <^d> 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 <^d> It can be fixed incrementally.
  • 22:52:09 <^d> SiteConfiguration is a good enough starting point we can iterate from.
  • 22:52:12 <qgil> TimStarling, can you please summarize any resolution about the current topic, please?
  • 22:52:17 <csteipp> Password requirements? I'm all for it.
  • 22:52:22 <^d> (Trying to do OMGEVERYTHING sets this project up for failure)
  • 22:52:23 <^d> </done>
  • 22:52:28 <brion> 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 <brion> though that had fewer globals so was easier :D
  • 22:53:09 <TimStarling> qgil: current RFC probably abandoned, legoktm to file new RFC
  • 22:53:15 <OwynD> yep, i feel like that part is a bit "sketchy" but it does work.
  • 22:53:23 <qgil> #info <TimStarling> qgil: current RFC probably abandoned, legoktm to file new RFC
  • 22:53:28 <OwynD> for example we have to launch a maintenance script in a wiki context.
  • 22:53:35 <DanielK_WMDE_> ^d: nicely put :)
  • 22:53:39 <OwynD> so it has all the right variables defined.

Password requirements[edit]

  • 22:53:51 <qgil> #topic Password requirements
  • 22:53:55 <TimStarling> there are a couple of really simple features proposed here
  • 22:54:00 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Password_requirements
  • 22:54:02 <OwynD> 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 <brion> OwynD: nice, i'll make a note to follow up on that for later :)
  • 22:54:09 <^d> brion: Speaking of globals, $wgArticle doesn't exist anymore ;-)
  • 22:54:16 <csteipp> Yep, I think it would be a very simple patch
  • 22:54:21 <TimStarling> one is to make it so that increasing $wgMinimalPasswordLength doesn't break everything
  • 22:54:22 <brion> \o/
  • 22:54:30 <OwynD> 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 <TimStarling> fine, hardly even needs an RFC
  • 22:54:41 <AaronSchulz> brion: same here
  • 22:54:43 <TimStarling> it's just a bug fix
  • 22:54:52 <csteipp> Which makes me wonder, should we generalize it a little, and create a PasswordPolicy object, and start using that?
  • 22:54:58 <AaronSchulz> we don't put all our bugs through RfC?
  • 22:55:16 <^d> brion: https://gerrit.wikimedia.org/r/#/c/93106/ :p
  • 22:55:25 <brion> \o/
  • 22:55:52 <TimStarling> various people are talking about character set requirements, but I'm not sure if that is actually proposed
  • 22:56:08 <TimStarling> but if someone submitted that to gerrit, I would probably approve it
  • 22:56:16 <TimStarling> since some admins like character set requirements
  • 22:56:55 <csteipp> 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 <qgil> #info <TimStarling> 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 <brion> ok so do we just have the character limit setting, or are we also including password complexity requirements for groups?
  • 22:57:44 <MaxSem> I fucking hate mandatory "you must have at least one number and one uppercase char". 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 <bawolff> +1
  • 22:57:55 <TimStarling> yeah, password requirements for groups is not so simple
  • 22:58:00 <TimStarling> but commonly requested
  • 22:58:14 <TimStarling> I think there is a bug or changeset for it?
  • 22:58:24 <csteipp> There is at least a bug for it
  • 22:58:28 <qgil> #info <csteipp> 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 <csteipp> 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 <TimStarling> you would need to ask new admins to change their password on their first login after promotion
  • 22:59:02 <siebrand> +1 for sticking to time boxes, qgil
  • 22:59:22 <TimStarling> which is pretty simple once you have expiry and forced reset features
  • 22:59:29 <csteipp> 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 <DanielK_WMDE_> 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 <DanielK_WMDE_> should be simple
  • 22:59:42 <TimStarling> 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 <ori-l> yes, i was just going to say
  • 23:00:04 <ori-l> there's quite a lot of overlap
  • 23:00:13 <brion> excellent
  • 23:00:22 <brion> so that sounds feasible and not undesirable?
  • 23:00:35 <TimStarling> so, what I would like from this RFC is for the discussion to be moved out to the talk page
  • 23:00:52 <qgil> #info <TimStarling> so, what I would like from this RFC is for the discussion to be moved out to the talk page
  • 23:01:24 <qgil> Is this the end of the meeting?
  • 23:01:35 <TimStarling> almost
  • 23:01:45 <qgil> anything else?
  • 23:01:47 * aude yawns
  • 23:01:50 <TimStarling> also, we would like expiration and forced reset to be part of the RFC
  • 23:02:15 <TimStarling> since the code overlaps with the group requirements feature
  • 23:02:24 <TimStarling> sound good csteipp?
  • 23:02:46 <ori-l> 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 <csteipp> Yep. I'll talk with Matt about adding that in. One of us can do that, I'm sure.
  • 23:02:59 <TimStarling> I think once the document is cleaned up, we can just accept it
  • 23:03:07 <TimStarling> since the mediawiki feature is pretty uncontroversial
  • 23:03:08 <qgil> #action Password requirements: <TimStarling> 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 <TimStarling> the controversial part of this is the WMF configuration
  • 23:03:18 <qgil> #link http://git.wikimedia.org/blob/operations%2Fmediawiki-config.git/HEAD/wmf-config%2FBug54847.php
  • 23:03:34 <ori-l> thanks :)
  • 23:03:36 <csteipp> #link https://gerrit.wikimedia.org/r/#/c/92037/ the much cleaner version of ^
  • 23:03:47 <qgil> ori-l, you can also type link, info, etc yourselves
  • 23:04:10 <qgil> end of meeting?
  • 23:04:11 * DanielK_WMDE_ randomly wonders if something that is both a formatter and a parser is a "forser".
  • 23:04:46 <TimStarling> qgil: yes
  • 23:04:51 <qgil> #info Thank you everybody! The plan is to keep having these meetings every other week.
  • 23:04:52 <qgil> #endmeeting