Architecture meetings/RFC review 2013-11-20

Wednesday, November 20, 2013 at 10:00 PM UTC at #wikimedia-meetbot ^connect

Requests for Comment to review

Summary and logs

The content below is an export of the original MeetBot notes using Pandoc.

Meeting summary

1. Details of this RFC review meeting are available at https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-20 (qgil, 22:03:40)
Page deletion (qgil, 22:05:30)
1. https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion (qgil, 22:05:43)
2. : https://bugzilla.wikimedia.org/show_bug.cgi?id=55398 proposed new field; AaronSchulz suggests we go with new table (Leucosticte, 22:06:55)
3. <TimStarling> maybe it should present a single option (a table), and maybe give a few more details about how that will work. Then we'll accept it (qgil, 22:22:57)
4. ACTION: Leucosticte to expand on "new table" design, optionally start on prototype (TimStarling, 22:23:31)
Configuration database 2 (qgil, 22:26:44)
1. https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2 (qgil, 22:26:53)
2. <TimStarling> neither JSON nor CDB are really appropriate backends for a web interface (qgil, 22:34:11)
3. https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages (^d, 22:38:32)
4. https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages (qgil, 22:38:51)
5. <TimStarling> I think we need to talk about requirements (qgil, 22:49:18)
6. ACTION: legoktm and other interested devs to develop requirements list on wiki (TimStarling, 22:49:20)
Text extraction (qgil, 22:49:48)
1. https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction (qgil, 22:50:00)
2. <MaxSem> this RFC is asking for decisions on 2 things: core vs. extension and whether to store the extracts in page_props, unconditionally (qgil, 22:50:23)
3. extracts are definitely too big for the core DB, need some other storage backend (TimStarling, 22:57:52)
4. ACTION: MaxSem and other interested devs to discuss storage backend options on RFC (TimStarling, 23:00:17)
5. ACTION: ^d to comment on RFC sharing experience with similar problem in ElasticSearch (TimStarling, 23:00:52)

Meeting ended at 23:04:06 UTC (full logs).

Action items

Leucosticte to expand on "new table" design, optionally start on prototype
legoktm and other interested devs to develop requirements list on wiki
MaxSem and other interested devs to discuss storage backend options on RFC
^d to comment on RFC sharing experience with similar problem in ElasticSearch

Action items, by person

^d
1. ^d to comment on RFC sharing experience with similar problem in ElasticSearch
legoktm
1. legoktm and other interested devs to develop requirements list on wiki
Leucosticte
1. Leucosticte to expand on "new table" design, optionally start on prototype
MaxSem
1. MaxSem and other interested devs to discuss storage backend options on RFC

People present (lines said)

TimStarling (71)
^d (35)
AaronSchulz (34)
MaxSem (27)
legoktm (22)
qgil (20)
aude (14)
Leucosticte (14)
ori-l (10)
vvv (5)
bd808 (5)
Krenair (4)
robla (3)
meetbot-wm` (2)
drdee (1)

Full log

Meeting logs

22:03:23 <qgil> #startmeeting
22:03:23 <meetbot-wm`> Meeting started Wed Nov 20 22:03:23 2013 UTC.  The chair is qgil. Information about MeetBot at https://bugzilla.wikimedia.org/46377.
22:03:23 <meetbot-wm`> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:03:31 <TimStarling> who added page deletion to the list at https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-20 ?
22:03:40 <qgil> #info Details of this RFC review meeting are available at https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2013-11-20
22:03:41 <Leucosticte> I did
22:03:59 <qgil> TimStarling, which should be the first topic?
22:04:17 <TimStarling> we also have Configuration database 2, and we have legoktm online for that one
22:04:26 <legoktm> :D
22:04:31 <TimStarling> and text extraction, and we have maxSem online for that?
22:04:36 <MaxSem> yup
22:05:18 <TimStarling> ok, let's start with page deletion
22:05:30 <qgil> #topic Page deletion
22:05:35 <TimStarling> Leucosticte: you have made some edits to this RFC recently?
22:05:43 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Page_deletion
22:05:50 <Leucosticte> yes, the two options being considered were new field and new table
22:06:23 <qgil> Everybody: please rememberto add "#info"at the beginning of sentences you want to be written in the meeting minutes. Thank you!
22:06:55 <Leucosticte> #info: https://bugzilla.wikimedia.org/show_bug.cgi?id=55398 proposed new field; AaronSchulz suggests we go with new table
22:07:25 <^d> I like this rfc and all I've read is the intro.
22:07:43 <Leucosticte> oh, I guess only use #info on major items, right?
22:07:46 <TimStarling> so you have just fleshed out these two options a bit?
22:08:01 <Leucosticte> pretty much. Platonides was the one who originally put the two options forward
22:08:13 * AaronSchulz actually coded the table option ages ago in branch
22:08:24 <qgil> Leucosticte, you're doing fine  :)
22:08:29 <^d> Question: has any thought been given to oversight migration?
22:08:30 <AaronSchulz> not that any of that would be usable now ;)
22:08:38 <MaxSem> It took us quite a time to get rev_deleted right, and page_delted will be much, much harder due to widespread use
22:08:47 <^d> We've still not migrated oversight data to rev_del, and whatever new idea should allow oversight to be migrated too.
22:08:56 <Krenair> I have a patch in Gerrit for that.
22:08:57 <legoktm> ^d: I think Krenair was working on a script to convert oversight data to revdel
22:09:17 <Krenair> It got too complex and I haven't bothered working on it for months.
22:09:19 <TimStarling> Leucosticte: are you offering to write the code for this, or are you just interested in the design?
22:09:59 <TimStarling> AaronSchulz: a branch in git or subversion?
22:10:06 <AaronSchulz> svn
22:10:10 <Leucosticte> TimStarling: offering to write code, but it looks like Aaron already started on the code, if we're going with the table option.
22:10:16 <AaronSchulz> this was the old days when brion had to review everything
22:10:29 <TimStarling> that's going back a way :)
22:10:47 <AaronSchulz> like I said, it would be from scratch to do that now
22:10:52 <TimStarling> Leucosticte may just want to look at your diff for ideas
22:11:44 * aude waves
22:12:15 * Krenair waves back
22:12:29 <drdee> is this an RFC that should be discussed at the Architecture Meeting in January?
22:12:39 <TimStarling> so everyone's preferred option is adding an archived_page table?
22:12:48 <^d> I'm on the fence.
22:13:15 <MaxSem> yep
22:13:21 <TimStarling> if revisions are left in the revision table, that makes deletion and undeletion fairly efficient
22:13:39 <MaxSem> which is a separate whee
22:13:42 <TimStarling> but I guess that is a property of both proposals
22:14:08 <Leucosticte> TimStarling, I preferred field since it would be nice to keep page IDs the same across deletions and recreations, and because deletion just is really just hiding pages from certain viewers, so the page may as well stay in the table -- that's my thinking, but the new table would be more secure by default; Aaron's right about that
22:14:09 <AaronSchulz> right
22:14:25 <AaronSchulz> you can still preserve page IDs either way
22:14:45 <TimStarling> same way we preserve revision IDs currently
22:14:49 <MaxSem> also, adding page_deleted to many queries would require a lot of index tuning and potentially more indexes
22:15:26 <TimStarling> how would Special:Contributions work?
22:16:06 <TimStarling> I guess there is a join on page already
22:16:26 <Leucosticte> oh, well if the page IDs stay the same then new field doesn't have a lot of advantages listed, other than "All page_ids live in one table." Were there other advantages?
22:16:30 <TimStarling> would we be looking at merging the code of Special:Contributions and Special:DeletedContributions?
22:17:06 <AaronSchulz> they could share more code at least
22:17:17 * ^d wonders what the schema would look like if a 1.5-style complete refactor happened...throw out all assumptions and do things the Right Way.
22:17:39 <vvv> And how many extensions will break as a result?..
22:18:10 <MaxSem> ^d, and a migration couple orders of magnitude harder...
22:18:11 <MaxSem> :P
22:18:42 <^d> Hey I was just wondering, not advocating :p
22:18:49 <TimStarling> would there be multiple archived_page rows per title?
22:18:58 <TimStarling> oh, sorry
22:19:01 <TimStarling> that is in the RFC document
22:19:29 <TimStarling> ^d: it would probably be a field
22:20:16 <TimStarling> but a table has some advantages for b/c
22:20:34 <TimStarling> anyway, should we accept this or ask for more detail?
22:21:28 <TimStarling> maybe it should present a single option (a table), and maybe give a few more details about how that will work
22:21:34 <TimStarling> then we'll accept it
22:21:36 <TimStarling> sound good?
22:21:42 <^d> Yeah I can agree to that.
22:22:01 <^d> I'm not unconvinced on the new table, I think with some more arguments you'll have me sold.
22:22:57 <qgil> #info <TimStarling> maybe it should present a single option (a table), and maybe give a few more details about how that will work. Then we'll accept it
22:23:31 <TimStarling> #action Leucosticte to expand on "new table" design, optionally start on prototype
22:23:55 <Leucosticte> so you need info on how Special:Contributions will work, or did you figure that out?
22:24:05 * AaronSchulz can only find the patch on https://bugzilla.wikimedia.org/show_bug.cgi?id=11402
22:25:18 <qgil> TimStarling, let us know when you wnt to move to a next topic, and which one it will be
22:25:36 <TimStarling> Leucosticte: maybe just give some indicative SQL showing the kind of query Special:Contributions and Special:DeletedContributions would do
22:26:09 * AaronSchulz doubts the former would need much change
22:26:32 <TimStarling> qgil: on to Configuration database 2
22:26:44 <qgil> #topic Configuration database 2
22:26:53 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Configuration_database_2
22:26:58 <Leucosticte> TimStarling: okay. so, ^d, did you have any more detail regarding what you were wondering aloud, or is that pretty much only an option we're going with if new table ends up being rejected after more details are given -- okay I guess we'll discuss later/elsewhere
22:27:36 <TimStarling> Leucosticte: obviously a change to deletion is needed, we're not going to reject the whole concept
22:28:09 <TimStarling> it's just a matter of getting the right level of detail before coding starts, so that you don't end up wasting too much time on back-and-forth in code review
22:28:39 <Leucosticte> ah, okay
22:28:44 <AaronSchulz> Leucosticte: you want to show the Special:Undelete SQL smaple in the rfc too
22:29:15 <Leucosticte> okay.
22:29:18 <AaronSchulz> and don't make it a separate page like I did in that patch ;)
22:29:19 <^d> Also, I'm curious what happens when a page is deleted & recreated. Not once, many times (it happens)
22:29:22 <AaronSchulz> ok, config now
22:30:10 <AaronSchulz> the rfc could say more about storage
22:30:23 <TimStarling> legoktm: you know that performant is not a word, right?
22:30:31 <TimStarling> just saying
22:30:34 <AaronSchulz> at some point, you need config files on each apache
22:30:34 <Leucosticte> it's in wiktionary
22:30:40 <legoktm> TimStarling: oops.
22:30:46 <TimStarling> yeah, lots of stupid things are in wiktionary
22:30:47 * AaronSchulz isn't sure where DataStore would really fit it
22:31:03 <Leucosticte> i thought the same thing when I saw it
22:31:10 <AaronSchulz> legoktm: it's used all over the web
22:31:21 <AaronSchulz> and in person...that is generally how things become new words
22:31:44 <legoktm> AaronSchulz: Really there just needs to be some kind of key-value storage. JSON was an easy choice since its human readable, and easy to use. CDB was also included if JSON isn't fast enough
22:32:16 <TimStarling> neither JSON nor CDB are really appropriate backends for a web interface
22:32:21 <AaronSchulz> right, but when people say key/value storage it's easy to get hung up on things like Cassandra, Mongo ect that are neither here nor there
22:32:38 <MaxSem> DataStore!
22:32:40 <AaronSchulz> could could be a blob in swift really...we don't even need key value
22:32:53 <^d> DataStore requires you having a connection to the database.
22:32:54 <AaronSchulz> well, one key, that would be for all the config
22:33:07 <legoktm> TimStarling: What would you suggest instead?
22:33:11 <vvv> It is not clear to me how this proposal interacts with extensions, especially ones which are not aware of new configuration backend
22:33:12 <AaronSchulz> but that is just for canonical storage, the apaches still need a copy locally
22:33:27 <TimStarling> legoktm: MySQL
22:33:42 <bd808> json is not the greatest config file format since it doesn't support comments
22:33:47 <AaronSchulz> b/c definitely needs mentioning in the rfc
22:33:50 <legoktm> vvv: you would still be able to use globals for backwards compatability
22:34:08 <legoktm> vvv: and extensions could use a hook to add their own configuration options
22:34:09 <robla> oh dear, bd808 is starting to hint at yaml
22:34:11 <qgil> #info <TimStarling> neither JSON nor CDB are really appropriate backends for a web interface
22:34:14 * robla grabs popcorn
22:34:21 <^d> Heh, so basically we're back to my old config proposal then.
22:34:24 <^d> Database.
22:34:39 <legoktm> Is using a database fast enough?
22:34:39 <vvv> YAML is what I've seen commonly used for those purposes
22:34:48 <robla> I believe Wikia has a db based solution.  OwynD?
22:34:53 <AaronSchulz> legoktm: not without a local shared-nothing cache
22:35:14 <AaronSchulz> really lots of ways of doing canonical storage + local caching could work
22:35:17 * bd808 thinks robla is projecting just because I happen to maintain the best PHP YAML extension
22:35:21 <AaronSchulz> including using MySQL
22:35:46 <aude> legoktm: we stick php into local settings to do tricks, sometimes, like add a hook for a specific wiki
22:35:56 <aude> how would such things be handeld with the config db
22:35:56 <TimStarling> we need to have multiple backends merged together, right?
22:35:58 <aude> ?
22:36:15 <TimStarling> and for WMF, we only want a subset of configuration variables to be web-editable
22:36:17 <AaronSchulz> aude: yeah, config management works a lot better with declarative conf
22:36:30 <legoktm> aude: You would just stick that into LocalSettings.php like is currently done
22:36:33 <TimStarling> for things that are not web-editable, we want a source file in version control
22:36:36 <TimStarling> with comments
22:36:46 <AaronSchulz> things like $wgJobClasses would have some trickiness since extensions dynamically add on to it
22:36:56 <aude> legoktm: after extract globals or whatnot?
22:36:57 <TimStarling> for things that are web editable, we want logs with usernames, and diffs and such like
22:37:04 <Krenair> I was about to say - I'm wondering how web-editable things are going to work with extensions
22:37:26 <TimStarling> yeah, that's another thing, extensions are not mentioned in this new RFC
22:37:27 <legoktm> TimStarling: I was thinking that everything is stored in the backend, and we use userrights to restrict what gets edited on the web
22:37:51 <^d> re: extensions & how to present a UI & so forth, Daniel Kinzler had an idea on my last rf.
22:37:52 <legoktm> Krenair: what do you mean?
22:37:52 <^d> *rfc
22:38:01 <legoktm> aude: yes
22:38:18 <TimStarling> legoktm: you can't give the web user the ability to edit a file in version control
22:38:22 <AaronSchulz> if there was a convention that dynamically altered config vars were only a function of the core config plus the site json/whatever config plus extension presence I guess one could compile and distribute the config
22:38:32 <^d> https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages
22:38:51 <qgil> #link https://www.mediawiki.org/wiki/Thread:Talk:Requests_for_comment/Configuration_database/Storing_setting_on_wiki_pages
22:39:23 <AaronSchulz> if it was resolved down, you could even have the config code be isolated from the rest of MW and other things could read the config for different wikis
22:39:26 <legoktm> TimStarling: right. everything would be stored in the backend, just not everything would be web editable
22:40:01 <AaronSchulz> you also wouldn't need the horribleness of things like getCachedConfigVar() in JobQueueGroup
22:40:06 <legoktm> ^d: main problem with that is that its not easy to access another wiki's page text. there's also a security issue with non-public configs
22:40:26 <AaronSchulz> any rfc must deal with fetching foreign wiki configuration and extension altered config
22:40:34 <legoktm> AaronSchulz: sorry, i'm lost. what are you referring to?
22:40:41 <^d> Gives us an excuse to have an interwiki transclusion rfc ;-)
22:40:56 <TimStarling> well, the existing system gives us that for core conf vars
22:41:05 <TimStarling> we just forgot to account for extensions
22:41:09 <^d> Well, that's part of what I was advocating.
22:41:15 <^d> Start with the current system.
22:41:20 <^d> And incrementally make it better.
22:41:27 <TimStarling> the current system is moderately complex
22:41:32 <vvv> One of the issues I discovered some time ago, is that you can't really tell anything about extension config unless extensions are aware of your system
22:41:47 <TimStarling> it's not just a key/value store, it has post-processing, like $stdLogo
22:41:54 <AaronSchulz> we already resolve config down for caching in wmf-config sort of
22:42:04 <ori-l> what sort of abstraction would tie different json configuration blobs together? how would you navigate between them?
22:42:25 <ori-l> a 10k-line file is horrible, but you can follow it by scrolling up and down
22:42:39 <legoktm> ori-l: the current proposal just has it stored in one big json file
22:42:44 <legoktm> each organized by "category"
22:42:56 <ori-l> that doesn't seem that compelling to me
22:43:10 <legoktm> site related vars, RL related vars, etc.
22:43:46 <ori-l> JSON is very limited
22:43:52 <TimStarling> the current system has ways to apply settings to groups of wikis
22:43:53 <ori-l> you can't reference or compose values
22:44:01 <^d> TimStarling: Which is one thing you have to keep.
22:44:15 <legoktm> TimStarling: my proposal included using db lists
22:44:19 <^d> (And I always thought was the hardest part to get right if you do things from scratch)
22:45:09 <TimStarling> so we are talking about a global web UI?
22:45:37 <ori-l> legoktm: ?
22:45:49 <TimStarling> would there be a local UI, for non-WMF wikis?
22:46:03 <^d> I think talking about a UI is putting the cart before the horse when we can't even come to agreement on architecture.
22:46:13 <ori-l> I don't think so
22:46:17 <legoktm> I was really only thinking of a local UI
22:46:22 <legoktm> but there probably should be a global one
22:47:14 <TimStarling> I think we need to talk about requirements
22:47:22 <bd808> Why not just put everything in the db except enough bootstrap config to find the database?
22:47:42 <ori-l> What would that solve?
22:47:50 <TimStarling> I think our discussions on architecture are fairly directionless because we don't have clear requirements
22:48:25 <TimStarling> so, I would like to make that an action item and move on to the last RFC in the last 10 minutes of the meeting
22:48:28 <ori-l> I want to flag an additional issue
22:48:31 <ori-l> oh, go ahead.
22:48:42 <bd808> ori-l: Just trying to think of how editing would work I guess. Serializing to disk seems gross.
22:49:18 <qgil> #info <TimStarling> I think we need to talk about requirements
22:49:20 <TimStarling> #action legoktm and other interested devs to develop requirements list on wiki
22:49:27 <legoktm> ok
22:49:48 <qgil> #topic Text extraction
22:49:53 <MaxSem> Okay, so basically this RFC is asking for decisions on 2 things: core vs. extension and whether to store the extracts in page_props, unconditionally
22:50:00 <qgil> #link https://www.mediawiki.org/wiki/Requests_for_comment/Text_extraction
22:50:23 <qgil> #info <MaxSem> this RFC is asking for decisions on 2 things: core vs. extension and whether to store the extracts in page_props, unconditionally
22:50:44 <TimStarling> MaxSem: what is the total data size?
22:51:14 <TimStarling> we can't store much in page_props, increasing core database size is quite expensive
22:51:33 <MaxSem> HTML extracts are rendered pages minus 30-50%
22:51:47 <AaronSchulz> no core DB bloat please :)
22:51:49 <TimStarling> so, enormous?
22:51:50 <MaxSem> text extracts are much shorter than wikitext
22:51:50 <^d> Can we cache them $somewhere?
22:52:07 <^d> If we know we'll get a decent hit rate.
22:52:08 <aude> seems odd to mix that with other stuff in  page props
22:52:22 <vvv> Wouldn't that fit well into whatever backend for parser cache we are currently using?
22:52:24 <aude> it's big enough to go in it's own place
22:52:35 <TimStarling> roughly how many bytes per page?
22:53:10 <MaxSem> not sure about the stats
22:53:30 <^d> You know where we could stash them...elasticsearch.
22:53:41 <^d> It would be kind of perfect for that.
22:53:48 <MaxSem> what for?
22:54:24 <MaxSem> ES is a search engine first of all, KV storage is btter done with something else
22:54:28 <TimStarling> MaxSem: the extension thing, you would have a WikitionaryExtract or WikimediaExtract extension or something like that?
22:54:29 <^d> We've already got text extracts (more or less) living in elasticsearch.
22:54:53 <MaxSem> TimStarling, say WIkimediaExtracts
22:54:57 <aude> it would be good not to have dependency on elastic search, but possibly as a "store" option
22:55:12 <MaxSem> but I was thinking about making it doable with config settings only
22:55:23 <^d> MaxSem: Indeed. You can search for a single document's extract ;-)
22:55:37 <^d> I think it should be in core, tbh
22:55:51 <MaxSem> ^d, I'm more interested in batch retrieval than in searching
22:56:03 <TimStarling> I was under the misapprehension that extracts were from truncated versions of articles
22:56:14 <TimStarling> that is not the case, there is no truncation, right?
22:56:26 <MaxSem> you can request a lede extract
22:56:31 <^d> MaxSem: Also doable. Give me pages [1,500]
22:56:31 <MaxSem> or first N sentences
22:56:45 <TimStarling> but the whole thing is stored somewhere?
22:57:05 <MaxSem> currently, it's cached in memcached
22:57:12 <^d> Meh, we only store current revisions though.
22:57:17 <^d> -10 :(
22:57:29 <bd808> Would stored parsoid DOMs make this easier? Just an xslt transform?
22:57:39 <MaxSem> but on-demand rendering doesn't allow batch retrieval
22:57:52 <TimStarling> #info extracts are definitely too big for the core DB, need some other storage backend
22:58:23 <MaxSem> TimStarling, extension DB like AFT and Echo?
22:58:42 <TimStarling> we don't have time today to go through all the options
22:58:55 <aude> MaxSem: i assume we'd have per-content type implementations of formatting, or even the option to opt-out for certain content types?
22:59:13 <MaxSem> aude, I'm only interested in articles
22:59:16 <aude> e.g. extracts for wikidata entities would be pretty different or perhaps not make sense
22:59:23 <aude> MaxSem: ok, so wikitext content
22:59:24 <TimStarling> it is quite a similar problem to what we are doing with ElasticSearch
22:59:31 <MaxSem> if someone has a different use case... patches welcome!:P
22:59:42 <TimStarling> let me do a couple of action items...
22:59:47 <^d> Indeed, which is what lead to HtmlFormatter making its way to core.
23:00:17 <TimStarling> #action MaxSem and other interested devs to discuss storage backend options on RFC
23:00:52 <TimStarling> #action ^d to comment on RFC sharing experience with similar problem in ElasticSearch
23:01:08 <MaxSem> anything on core vs. extension?:)
23:01:25 <TimStarling> it's fine by me to have WikimediaExtracts
23:01:30 <^d> Core makes it easier for me to reuse more for Cirrus
23:01:48 <^d> But if everyone else thinks extension I can live with it.
23:02:04 <qgil> Anything else?
23:02:08 <TimStarling> maybe you should say on the RFC what exactly will be in WikimediaExtracts and why it is needed
23:02:22 <MaxSem> I was proposing basics in core with possibly WMF-specific stuff in an ext
23:02:30 <aude> and make sure to mention which content type(s) :)
23:03:38 <aude> and that other content types could "hook" into this and implement the extracts in a different format
23:03:39 <TimStarling> ok, all done?
23:03:41 <MaxSem> aude, I liek getText() moar than getContent(), will use it until it disappears:P
23:03:53 <aude> hah
23:04:02 <qgil> Thank you everyone! The next meeting is scheduled on 2013-12-04, same time -- https://www.mediawiki.org/wiki/Architecture_meetings
23:04:06 <qgil> #endmeeting