[13:32:57] Just trying irc from Android [16:51:11] yo [16:51:52] hey aharoni [16:57:01] Language Engineering office hour in less than 5 minutes [16:58:28] \o/ [16:59:02] ~\o/~ [16:59:22] hello arrbee aharoni [16:59:29] hey kart_ [17:00:06] And we begin [17:00:09] #startmeeting Language Engineering monthly office hour - October 2014 [17:00:10] Meeting started Wed Oct 15 17:00:09 2014 UTC and is due to finish in 60 minutes. The chair is arrbee. Information about MeetBot at http://wiki.debian.org/MeetBot. [17:00:10] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [17:00:10] The meeting name has been set to 'language_engineering_monthly_office_hour___october_2014' [17:00:26] Hello everyone [17:00:32] Welcome to the monthly office hour of the Wikimedia Language Engineering team [17:01:01] * arrbee is Runa, the Outreach co-ordinator for our team [17:01:21] Our office hours are held every 2nd Wednesday of the month [17:01:43] We delayed by a week this month due to the holiday season in India [17:02:07] Our last office hour was held on September 10th, 2014. The logs are at: [17:02:16] #link https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2014-09-10 [17:02:49] o/ [17:02:59] Before we begin, please be aware that the chat will be logged and posted on a publicly accessible wiki [17:03:08] Hey Niharika .. good to see you [17:03:23] Good to see you too, arrbee! :) [17:03:26] A quick introduction of the team [17:04:12] We are the Wikimedia Language Engineering team. Besides me, present today are aharoni kart_ jsahleen Nikerabbit divec santhosh pginer [17:04:53] We build and maintain language features and tools for the wikis in more than 300 languages and support the wiki communities around the world [17:05:34] Our team page on mediawiki.org has details about the projects we work on and how you can participate in them: [17:05:37] #link https://www.mediawiki.org/wiki/Wikimedia_Language_engineering [17:06:38] Since our last office hour, we have continued work on Content Translation and also made updates to CLDR and Translate [17:07:13] For Content Translation, we completed the 2nd release last month [17:07:39] September 30th to be precise [17:07:46] The first was the MVP release earlier in July [17:08:04] The announcement for the new version can be found at: [17:08:22] #link https://www.mediawiki.org/wiki/Content_translation/Announcement-October2014 [17:09:16] However, due to technical difficulties with the setup on beta-labs the updated code is not yet available for wider testing and use [17:09:42] We hope to sort out the problems very soon [17:10:10] kart_ has been actively working with the Ops team on this [17:10:46] particulaly with akosiaris. Thanks a lot for the help. [17:11:11] \0 [17:11:36] Meanwhile we have already started working on the features for the next version, which is scheduled for release on November 18 [17:12:10] In the latest version we have introduced a basic formatting toolbar for Google Chrome [17:12:28] We have also activated bidirectional machine translation for Spanish and Portuguese [17:13:11] However, due to the blocker in the labs setup, users will have to wait for some more time to use these 2 languages reliably [17:13:53] santhosh: would you like to talk a bit about the other features and the new features planned for the next release? [17:14:38] We were working on improving the performance and polishing the existing features [17:14:46] We worked on several infrastructure components. [17:14:59] Overall it should improve the responsiveness of the tools. [17:15:10] We are adding automatic category adaptation feature now. [17:15:27] We will soon start work on a translation dashboard [17:16:18] is there any plan yet to add other languages? [17:16:48] Romaine: yes. Unfortunately, we are blocked on the lab setup. [17:16:55] And some early prepartion for allowing a translator to save and resume later -probably by another translator [17:17:10] Romaine: we will begin testing more language pairs for machine translation support [17:17:44] I hope Dutch can be such language [17:18:16] I have had the opportunity to extensive test another translating tool earlier and I am veru much looking forward to this tool [17:18:34] Romaine: once we prepare our infrastructure - that is what we are slightly blocked, we should be able to focus on increasing language coverage [17:18:59] we will evaluate more language pairs [17:19:17] in what time frame you expect such to be happen? [17:20:15] by the end of this month we are expecting our infrastructure issues resoved. We have to deploy the current language pair- Spanish-catalan to production then [17:20:30] Also open up catalan->spanish. [17:21:10] The next candidate language we have is Portuguese-spanish [17:21:24] Mainly because we use Apertium MT. [17:22:04] We will evaluate all language pairs we can support with Apertium first. [17:22:39] Romaine: we hope to have reliable testing infrastructure (not beta) to be ready for preliminary testing of more language pairs before the end of this month [17:23:05] Romaine: You are interested in English-Dutch? [17:23:20] yes [17:23:33] German-Dutch orFrench-Dutch is fine as well [17:23:47] all 3 seem to be in Apertium incubator [17:23:56] Apertium supports Afrikaans and Dutch as a pair. [17:24:14] Romaine: have you ever tried this pair? [17:24:41] I was trying to but maybe I did not understand the tool [17:25:20] on apertium.org? [17:26:18] not there, apparantly I should have [17:26:49] (in earlier years I have tested the translate tool https://nl.wikimedia.org/wiki/CoSyne , but that is a totally different project I think) [17:27:49] in apertium.org I can only select a language and translate to Portguease, Catalan or Spanish [17:28:41] Romaine: I can select Dutch-Afrikaans at http://www.apertium.org/index.eng.html#translation [17:28:54] and the other way around [17:29:10] yes, that is the only option together with Dutch [17:29:14] CoSyne is a pretty cool project, but AFAIK it's more about comparing current language versions of articles (but it's possible that I don't remember correctly) [17:29:32] Romaine: are you familiar with Afrikaans? [17:29:39] I can read Afrikaans [17:29:47] oh nice [17:29:51] people in the Netherlands can pretty well understand it [17:30:03] Apertium are very keen about releasing pairs that they are sure about. [17:30:18] Romaine: if you do get the time to check out the pair, we would be very interested to hear what you think of the translation [17:30:31] sure I can test [17:30:33] So it may work only in one direction for some languages. [17:30:54] Romaine: Thanks a lot. [17:31:24] is there a place where I can report/discuss the things I notice? [17:31:34] And yes, please test Afrikaans and tell us what do you think about it'd quality. Such feedback is very important to us. [17:31:55] where should I post/send/etc the feedback? [17:32:00] Romaine: ContentTranslation project talk page, bugzilla, #mediawiki-i18n, direct emails to any of us [17:32:07] all work [17:32:16] I will find one :) [17:32:32] #link https://www.mediawiki.org/wiki/Talk:Content_translation [17:32:35] Romaine: ^^ [17:32:51] personally I would have expected German-Dutch as well, bot languages are very similar to each other [17:33:10] Its in the incubator [17:33:43] Or Dutch-Frisian :) [17:33:51] It would have been desirable to have that pair, and some others ready in production :) [17:34:10] or Norwegion bokmal-Dutch [17:35:30] (CoSyne is a tool to compare current language versions of articles but also about translating articles) [17:35:58] if more of these languages come available I am happy yto test it [17:36:09] Thanks a lot :) [17:37:00] pginer has been testing the Spanish-Portuguese & Portuguese-Spanish translations with users [17:37:14] I can organise such for Dutch [17:37:48] Romaine: I will make sure we get in touch with you once we have some clarity on the infrastructure setup [17:37:56] :) [17:38:52] Meanwhile, you may have noticed the message on the Portuguese Village Pump for Content Translation testing [17:39:02] #link http://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Esplanada/an%C3%BAncios#Try_Portuguese_support_for_Content_Translation [17:39:32] In other news [17:40:10] santhosh has also been working on updating the plural forms in mediawiki i18n as per the latest CLDR 26 release [17:40:28] This primarily affects a few languages including Russian [17:40:59] We are working on determining a timeline for implementation of this change and also reach out to the affected language communities to verify the change in content [17:41:29] Nikerabbit: would you like to add something about this? [17:42:34] Greetings [17:42:37] yep [17:42:56] it is quite complicated since we need to update the rules and translations simultaneously [17:43:09] * Romaine filled in the form in the pt: In other news section [17:43:16] Scott_WUaS: Hello.. I was hoping you would drop by [17:43:37] we will be coordinating with various people to get these changes out in a way that causes minimal breakage [17:44:19] as a user you do not need to do anything. if you are a translators, we will need your help to verify and update translations as needed [17:44:56] Thanks Nikerabbit [17:45:24] Hi Arrbee ... how are you ... looking forward to participating in the remaining 15 minutes or so. [17:45:48] We will be announcing the when we have more clarity on the timeline for the CLDR work [17:45:57] Scott_WUaS: Unfortunately, I could not get any more information about the interwiki projects and wikidata, that you had mentioned. [17:46:25] Scott_WUaS: I was hoping someone from Wikidata may be able to help with it [17:47:04] Timecheck: just under 15 minutes [17:47:10] remain [17:48:08] Thank you for checking, arrbee ... I've begun contributing to Wikidata weekly summaries ... and there do appear to be a number of external sister wiki projects that also engage Wikicommons - I think - possibly wikidata listing all genes, for example. Is someone here from Wikidata who might be able to add to this? [17:48:47] * external sister wikidata projects [17:48:48] * arrbee spots dennyvrandecic [17:49:03] and Lydia_WMDE of course [17:50:17] Scott_WUaS: we can possibly contact them over email. I am interested to know more about this :) [17:50:21] you got me curious [17:50:30] Yes ... sounds great [17:50:39] Alright [17:50:49] Moving on [17:51:06] There are quite a few language engineering projects which are open for this round of OPW [17:51:17] #link http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Internationalization_and_localization [17:51:25] (arrbee: it's the multi- and inter-lingual aspects of this potential that are fascinating :) [17:51:53] Please feel free to spread the word around to young women who may be interested in this field of work for OPW projects [17:52:01] Niharika: sucheta ^^ [17:52:39] Scott_WUaS: very true. I hope we can get more information on this soon. [17:52:43] arrbee: I'm on it. :) [17:53:05] Niharika: Alright. :) [17:53:25] :) [17:54:40] aharoni|mobile: Nikerabbit, kart_ are listed mentors [17:54:59] possibly jsahleen will be joining in too [17:55:18] Please feel free to contact them [17:55:42] We have just under 5 minutes [17:57:06] Looks like there are no more questions :) [17:57:50] If nothing changes, our next office hour will be on November 12, 2014, but do lookout for the announcements for the exact date [17:58:11] Our mailing list is mediawiki-i18n@lists.wikimedia.org and IRC channel is #mediawiki-i18n [17:58:33] I will post the log from this meeting shortly on metawiki [17:59:27] Thanks everyone for joining in. See you next month. [17:59:29] Thank you, arrbee! [17:59:47] Do feel free to write directly to me if you have any questions about our projects [17:59:52] Thanks Scott_WUaS :) [18:00:11] Thanks arrbee. :) [18:00:14] Thanks Romaine. I will get back to you as soon as our infra setup issues are sorted. [18:00:17] Thanks Niharika [18:00:21] great [18:00:37] Thanks again! [18:00:38] #endmeeting [18:00:38] Meeting ended Wed Oct 15 18:00:38 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [18:00:38] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-15-17.00.html [18:00:38] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-15-17.00.txt [18:00:38] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-15-17.00.wiki [18:00:38] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-10-15-17.00.log.html [20:01:09] Krinkle [20:02:41] heh [20:02:51] now what was the topic? [20:03:04] is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [20:03:09] Oops [20:03:28] Thanks, TBloemink. [20:03:58] thanks, TBloemink [21:02:32] * DanielK_WMDE__ wibbles [21:02:54] #startmeeting RFC meeting [21:02:54] Meeting started Wed Oct 15 21:02:54 2014 UTC and is due to finish in 60 minutes. The chair is TimStarling. Information about MeetBot at http://wiki.debian.org/MeetBot. [21:02:54] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [21:02:54] The meeting name has been set to 'rfc_meeting' [21:03:05] #topic RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:04:42] ok, we'll start with the database one? [21:05:15] yea... i have a question about that one... [21:05:25] would it be feasible to have PG support as an extension? [21:05:29] how would that work with the installer? [21:05:35] <^demon|away> At the moment it wouldn't. [21:05:38] #topic Removing bad database abstractions | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ [21:05:42] #link https://www.mediawiki.org/wiki/Requests_for_comment/Removing_bad_database_abstractions [21:05:43] i guess the extension would need to register with the installer or something [21:05:47] DanielK_WMDE__ : i second that question :) [21:05:48] we’d need to devise a plugin point for the installer yeah [21:05:55] not impossible in theory [21:05:55] <^demon|away> Extensions can register in the installer, as extensions. [21:05:59] <^demon|away> But db setup is earlier [21:06:08] <^demon|away> So we'd need some work to do it. [21:06:14] <^demon|away> But yeah, not impossible. [21:06:14] but it feels scary to me unless it can automatically convert the schemas [21:06:19] things could really easy get out of sync [21:06:27] doesn't sound hard to write, but easy to get wrong... [21:06:42] <^demon|away> Yeah, which is part of my basis for filing this rfc. It's not so much that they're unused, but that they're difficult for people to maintain. [21:06:50] <^demon|away> And they don't think about them since they don't have to. [21:06:51] well, if your requirements for a wiki engine are "any wiki engine that works with MSSQL" then maybe you would use the last version of MW known to work with MSSQL [21:06:52] for the danger of being heretic: would composer's autoloader way of registering an extension be a solution here? [21:06:59] <^demon|away> Suggestions to abstract the schema away are a +1 for me. [21:07:06] somethign like dbal would help with the schemas :) [21:07:08] does it really matter to still support Postgre? If it is being done just for the sake of it and a few dozen of installs I don't think it is worth it. [21:07:09] so maybe it doesn't matter so much if it breaks occasionally [21:07:32] hashar, there are quite a few SMW intallations running on PG [21:07:37] part of the schema stuff might be addressed by another rfc we talked about the other week, possibly using doctrine DBAL and their schema tools? [21:07:37] hashar: there are folks that use it [21:07:47] mglaser: autoloader just makes the class available, it doesn't register hooks, or can it? [21:07:53] <^demon|away> aude: The think I fear with dbal/doctrine is in it being a step toewards towards their ORM that I'm not really looking for. [21:07:59] <^demon|away> *thing [21:08:01] hmmmmm [21:08:08] ^demon|away: it's not an orm [21:08:16] sql was supposed to *be* an abstraction layer. sighhhhh :D [21:08:18] agree, i would not want an orm [21:09:07] does the PG stuff rely on fancy things that would be hard to automatically generate from either a mysql schema base or an independent base schema? [21:09:09] but we can have dbal without the orm [21:09:14] * brion thinks triggers and stuff [21:09:18] <^demon|away> brion: At the moment, yes [21:09:22] <^demon|away> Triggers, constraints, etc. [21:09:33] hmm,t hat might need a migration then if we replace those [21:09:51] i’d rate this as “hard to do right, needs people invested in it to support the activity” [21:09:56] i once looked at the schema updaters for PG, they are completely different from the ones we use for MySQL. [21:10:01] and incomplete, iirc [21:10:01] you know I didn't like the way postgresql support was done from the outset [21:10:03] would it help to have Jenkins jobs using postgre / mysql as backends? For now Jenkins only use sqlite. [21:10:04] i don't think there is anything terribly hard to generate [21:10:07] <^demon|away> TimStarling: +1 [21:10:08] DanielK_WMDE__ : that's true. Afaik, it cannot. The way current db abstraction works is by inheriting classes, though. I could imagine a registration similar to the way wgAuth works [21:10:11] hashar: +1 [21:10:18] but requires attention to get it right and folks to do it [21:10:20] hashar: I said something like that on the talk page of the RfC [21:10:23] I would have liked it if it was as close to MySQL as possible, instead of being arbitrarily different [21:10:28] mglaser: no, please no. $wgAuth is terrible. [21:10:32] e.g. timestamp format could have been char(14) [21:10:41] as the creator of $wgAuth i second that notion, it’s terrible [21:10:42] aude: mglaser yeah I know PG is being used. My point was merely: is it worth the effort? Folks could "just" migrate to MySQL/MariaDB [21:10:42] postgresql does support char(14) [21:10:47] mglaser: yes, but how does the entry get into the wgDatabaseEngines (or whatever) array? [21:11:01] mglaser: there's no LocalSettings.php yet. [21:11:05] hashar: pg has cool stuff like native support for json [21:11:08] and postgis :) [21:11:13] Yeah, we don't have a great history with plugins [21:11:18] reasons to want to use it [21:11:22] DanielK_WMDE__ : true [21:11:24] well, we are redoing extension registration at the moment [21:11:30] and hstore (key value) [21:11:31] Kunal just wrote some POC code [21:11:31] aude: yeah I am convinced . But WMF is never going to migrate to pg anyway :D [21:11:39] aude: indeed, but MW isn't using those [21:11:39] hashar: yeah [21:11:40] DanielK_WMDE__: i suppose we’d do something like, drop the installer extension into a subdirectory and register it with a clickthrough in the installer ui [21:12:04] DanielK_WMDE__: mw is not but suppose an extension might [21:12:20] brion: why not just go through everything that is already in the extensions dir, and register it (by looking at some nice json file there)? [21:12:23] in the proposed new system, extensions are registered with JSON instead of with a .php setup file [21:12:26] mglaser: any notion of resourcing support from users of PG? [21:12:33] brion: some extensions could just expose an installer.json file. [21:12:38] DanielK_WMDE__: yeah that’s probably sensible [21:12:44] so you could totally pull out just the DBMS bit of the JSON file from the installer [21:12:57] brion: sounds nice & easy. should include a version compat check... [21:13:06] brion, good question. I know they report when things break... [21:13:12] brion: i small an rfc :P [21:13:13] <^demon|away> So, before we get that far. We'd need a clean abstraction in core. [21:13:18] err, smell [21:13:44] brion SMW has a lot of corporate users. Chances are good we find some people willing to support pg [21:13:56] ^demon|away: to replace maintenance/*/*.sql? [21:14:14] <^demon|away> That. Plus helping to reduce the differences between the abstractions. [21:14:15] and please please no Doctrine [21:14:19] mglaser: can you follow up on that? it’d be great to have a better idea how seriously we can prioritize keeping pg working [21:14:27] hashar: why? [21:14:34] brion, yes, can do [21:14:37] awesome :D [21:14:58] #action mglaser will investigate PG users and if anyone can provide resources to help PG maintenance [21:15:34] DanielK_WMDE__: Doctrine causes developers to be lazy and it ends up generating very bad sql which the DBA will blame you for long. At worth folks end up using raw SQL to workaround Doctrine producing bad SQL. [21:15:48] hashar: that all has nothing to do with the doctrine/dbal we are talking about using :) [21:16:11] what about MSSQL and Oracle? should we just ditch those for now? [21:16:13] brion: if you could get an item to have Jenkins to run postgre that would be nice. I think it would help better support postgre. I am not volunteering though but will glad to provide support as needed. [21:16:13] although it is a "slippery slope" twords enabling the use of their other library, doctrine/orm [21:16:15] hashar: we already said "no orm" :) [21:16:32] TimStarling: i’m happy to ditch mssql and oracle, they’re known broken right now iirc [21:16:34] i think someone was maitnaining oracle to some extent [21:16:37] <^demon|away> TimStarling: Oracle I know Jure put a ton of work into, but $DAYJOB doesn't have him on that anymore. [21:16:40] DAO ftw. ORM is evil. [21:16:44] fine if they want it an extension [21:16:46] <^demon|away> Oracle's probably not as broken as MSSQL [21:16:47] we can have automated testing for the open source DBMSes, but not so much for the closed source ones [21:16:49] otherwise drop it [21:16:53] well if someone wants to pick them back up as extensions if we provide infrastructure for PG [21:17:00] … then we can kill em now and bring em back as extensions later [21:17:07] yep [21:17:30] <^demon|away> I'll note, I've tried removing MSSQL before as unsupported and broken. [21:17:39] <^demon|away> I get pushback and get told it is supported and works. [21:17:54] I suggest to note that we want if we ant to drop core suppor for some DB abstractions, we should first make sure suppor tcan be added back as an extension [21:17:55] Oracle been maintained by volunteer Jure Kajzer via a company. But I don't think it is still maintained. [21:18:03] wich means work on the installer to make that possible [21:18:12] either oracle or mssql were once completely removed, but came back from the dead when someone got interested [21:18:19] <^demon|away> mssql. [21:18:22] Skizzerz is currently maintaining MSSQL, but I don't know how much time he has to dedicate to it. [21:18:29] (we even had support written for IBM DB2 at one point, but got removed because lack of maintenance / user base). [21:18:36] you know we can do MSSQL and Oracle automated testing if we really want to [21:18:42] <^demon|away> I'll note nobody cried over db2. [21:18:44] <^demon|away> ;-) [21:18:56] if we can do IE testing in selenium we can probably do MSSQL [21:19:07] TimStarling: can we start with adding MySQL to CI?!... [21:19:17] if we want to we can. but that needs resources and that depends on someone caring enough to do it [21:19:18] yeah, that's a good point [21:19:28] mysql would be a good start :D [21:19:44] https://bugzilla.wikimedia.org/show_bug.cgi?id=20343 [21:19:46] * DanielK_WMDE__ looks hopeful @hashar [21:19:48] It would be great to move DB support to an extension like structure [21:20:09] that way, external devs could take on the task more easily [21:20:20] <^demon|away> Well, the only part I think that can't be an extension at the moment is the installer & maybe some db support stuff that's hardcoded. [21:20:29] mglaser: core schema updates could be problematic though [21:20:30] <^demon|away> Other than that, class registration for search backends, etc will all work fine. [21:20:31] we would also know which mw version have working support for dbs [21:20:39] they'd have to be re-implemented for each of these extensions [21:20:56] #info some general interest in extensionizing DBs to let the lesser-used ones be maintained separately. extension schema updates are a question though. [21:21:23] <^demon|away> Well, I think if we support some new abstracted schema thingie it'd be a break in back-compat. [21:21:25] DanielK_WMDE__: if we have folks willing to add Mysql/Postgre supports to our Jenkins jobs I am all for it. It is not a priority of mine though but will be happy to provide support. [21:21:48] we use sqlite because it is fast, right? [21:21:51] #info having DB support as an extension requires a way for extensions to hook into the installer early. maybe the installer could look for special json files in extension dirs. [21:22:15] maybe mysql/postgresql tests should be done periodically, instead of blocking merge [21:22:21] hashar: i have no idea where to start, but maybe hoo can tell me... [21:22:35] or addshore. addshore has been messing with jenkins, right? [21:22:41] at minimum, mysql/postgres can be run on travis [21:22:46] post merge though [21:22:53] and needs folks to care about that when it fails [21:23:17] yep [21:23:27] nobody really care's for MW core travis right now [21:23:33] i'd personally want mysql checked pre-merge, and blocking. if it's not too expensivew [21:23:34] aude agreed. That's better than nothing, though :) [21:23:35] so I doubt anybody will if there's *more* stuff failing [21:23:50] but having the tests run there with other DBs is easy [21:23:55] as long as they are OSS [21:24:01] project scope: I think if any serious core developer opens up this code, there is going to a bad smell wafting out [21:24:08] hoo If we use the extension approach, we could find maintainers for this, i guess [21:24:09] I gather ^demon|away already did it and got a whiff [21:24:15] if travis could post to gerrit or phabricator, that might help [21:24:47] <^demon|away> TimStarling: Yes. It almost got scoped into new-installer. [21:25:04] <^demon|away> But it quickly became a very smell rabbit hole, so we scoped it out to a different branch and never went back to it. [21:25:07] <^demon|away> *smelly [21:25:09] so I don't doubt that there is plenty of work to do just on the first steps towards extensionization [21:25:26] question is: who wants to do that work? [21:25:33] DanielK_WMDE__? [21:25:37] we can have jobs triggered on a daily basis with Zuul, can then be added on patch proposal once we are happy enough with them [21:25:47] * brion is happy to defer that question until mglaser has checked if anyone’s willing to sponsor the PG support [21:25:57] Travis is nice but doesn't have as many eyeballs compared to our Jenkins [21:25:58] .) [21:26:00] <^demon|away> I don't think one precludes the other. [21:26:03] want vs. have the time [21:26:16] TimStarling: it sounds like a cool project, but i don't think i can convince lydia that we need this for wikidata ;) [21:26:20] <^demon|away> I think improving our schema management is important regardless of whether we scare up some additional PG lovers. [21:26:28] Also, MSSQL and Azure could be a good start for getting funded [21:26:42] ^demon|away: you are saying it could be us? [21:26:48] ^demon|away: would dbal be a useful tool for this? [21:26:50] I know MS spent some money on getting MSSQL to work with _some_ MW version [21:27:16] I think they sponsored somebody to add azure support [21:27:22] <^demon|away> TimStarling: Could be. I had had some thoughts about making things easier for WMF dba(s) too, if schema patches are nicely abstracted. [21:27:35] <^demon|away> DanielK_WMDE__: Would have to look closer. [21:27:36] hoo, which is essentially MSSQL [21:27:40] who would be sponsored? an individual or an organisation? [21:28:07] I think in the past they paid for individuals, right? [21:28:12] TimStarling : If I remember correctly, that was an individual back then [21:28:23] mglaser: No, I'm talking about the file backend stuffs, but that's off topic here (just wanted to make the point that people are interested) [21:28:24] ^demon|away: schema maintenance was the reason we wanted to use dbal for wikidata [21:28:35] i havn't worked with it though, so i don't know the details [21:29:14] aude: maybe osm would be interested in sponsoring PG work? [21:29:27] DanielK_WMDE__: osm has no employees and tiny budget [21:29:33] :( [21:29:38] DanielK_WMDE__ : schema maintenance in other DBs is a pain :) I remember trying to get a stored procedure into PG at some point.... imposssible via the current updater [21:30:00] aude: i was more thinking of finding an interrested volunteer to do it. asking osm for money would be silly, if not ironic. [21:30:15] DanielK_WMDE__: unlikely, also [21:30:25] basically I am imagining that we (I guess via mglaser) would put an ultimatum to MS saying that unless $X is spent on maintenance per year, we will drop MSSQL support [21:30:28] stretched thin for volunteers [21:30:28] too bad [21:30:42] and lots of cool osm projects to do :) [21:30:43] i.e. it has to be an ongoing committment [21:30:45] cooler* [21:31:07] MS would say to use Azure I guess. [21:31:24] TimStarling: that could work. [21:31:50] +1 [21:32:01] Again, I guess if we could extensionalize this, MS could even take over the maintenance of MS support. [21:32:19] currently, it's hard, as you need someone with +2 on core to do this [21:32:26] ...sorry, do we have any indication that MS actually wants to do this? Or even cares about mediawiki? [21:32:28] one of the bottlenecks for pg has always been code review [21:32:38] #action Chad to develop scope for MW Core Team project to abstract schema updates etc. [21:32:38] <^demon|away> So, to wrap up this RfC so we can chat about the next one. I guess we should reject this RfC since it's clearly not going to be accepted as-is. I could dust off "Abstract table definitions" again and turn it into something workable. [21:32:39] there always have been patches but not enough +2 people able to review [21:32:53] as an extension, it would be easire to give rights to the appropriate folks [21:33:01] legoktm: Yes, they sponsored Azure support in MW 1.19 or so [21:33:12] ok, but that was how many years ago? [21:33:15] yeah ok [21:33:18] legoktm: if they’re not interested anymore then we just drop mssql [21:33:20] legoktm : two [21:33:35] brion: but if we have a volunteer willing to support it, why does it depend on MS? [21:33:39] #info abandon current RFC since there is some interest in maintaining diverse DBMS support [21:33:53] legoktm: then the volunteer gets to do it? [21:33:53] https://gerrit.wikimedia.org/r/#/q/owner:%22Skizzerz+%253Cskizzerz%2540gmail.com%253E%22+status:merged,n,z [21:34:24] okay [21:34:28] TimStarling: that's kind of odd - we decide to keep broken db support because there's no interest in maintaining suppor for these dbs... [21:34:29] whut? [21:34:37] that wasn't the impression I got from what people were saying earlier. [21:35:17] DanielK_WMDE__: I am repeating what ^demon|away said [21:35:38] <^demon|away> Well also, I think we're all in agreement that the biggest pain point of multiple-dbms support is schema management. [21:35:45] DanielK_WMDE__: we keep all the broken ones because we don't know which one we want to keep and which one we want to drop :D [21:35:51] <^demon|away> Solve for that, and there's less need for dedicated support for those backends. [21:35:56] well, if they are broken... [21:36:07] <^demon|away> People claim they aren't ;-) [21:36:12] ^demon|away is the author so he can unilaterally abandon it [21:36:19] it's time for the next RFC now [21:36:25] DanielK_WMDE__: we can either drop them or fix them and from there properly maintained them. [21:36:38] * ^demon|away exercises his god-like rfc author powers and REJECTS IT [21:36:42] sure, i just find it a bit odd. doesn't mean i'm opposed :P [21:36:48] pg usually does work actually [21:36:59] #topic Allow styling in templates | RFC meeting | https://meta.wikimedia.org/wiki/IRC_office_hours | Please note: Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE) | Logs: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/ (Meeting topic: RFC meeting) [21:37:02] #link https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates [21:37:07] sometimes some schema update gets forgotten then someone submits a patch [21:37:22] hashar: but consensus seems to be to do neither. we'll neither fix them nor drop them. [21:37:30] ok i’d hoped to have a PoC ready but was busy refactoring other stuff [21:37:44] but i do have one main open question about template style additions: [21:37:53] 1) how important is it to scope the styles? [21:38:13] <^demon|away> DanielK_WMDE__: Yeah, but a fruitful discussion nonetheless :) [21:38:24] eg, if someone creates a template that has css #content { display: hidden } <- that might be bad [21:38:44] i’m not sure how well supported scoped