Wikimedia Meta-Wiki

IRC office hours/Office hours 2014-04-09

< IRC office hours

#wikimedia-office: Language Engineering monthly office hour - April 2014

edit

Meeting started by arrbee at 16:59:52 UTC. The full logs are available at https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-09-16.59.log.html .


Meeting summary

edit


Meeting ended at 18:01:35 UTC.


Action items

edit
  • (none)


People present (lines said)

edit
  • arrbee (84)
  • aharoni (23)
  • Nikerabbit (12)
  • Nemo_bis (9)
  • alolita (8)
  • bd808 (4)
  • wm-labs-meetbot (3)
  • kart_ (3)
  • Pavanaja (1)
  • matanya (1)
  • manybubbles (1)


Log

edit

Time: 17:00-18:00 UTC
Channel: #wikimedia-office
Timestamps are in UTC.
16:59:52 <arrbee> #startmeeting Language Engineering monthly office hour - April 2014
16:59:52 <wm-labs-meetbot> Meeting started Wed Apr 9 16:59:52 2014 UTC and is due to finish in 60 minutes. The chair is arrbee. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:52 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:52 <wm-labs-meetbot> The meeting name has been set to 'language_engineering_monthly_office_hour___april_2014'
17:00:16 <arrbee> Hello, Welcome to the monthly office hour of the Wikimedia Language Engineering team
17:00:37 <arrbee> My name is Runa and I am the Outreach coordinator for our team
17:00:57 <arrbee> IMPORTANT: The chat today will be logged and publicly posted. Also been mentioned in the channel topic
17:01:47 <arrbee> The Wikimedia Foundation's Language Engineering team builds language features and tools to support our wiki communities across the world
17:01:53 <kart_> Hi all
17:02:17 <arrbee> We are a globally distributed team and host office hours on the 2nd Wednesday of every month
17:02:21 <Nikerabbit> hi
17:02:28 <arrbee> Hi kart_ Nikerabbit
17:02:47 <arrbee> Our last office hour was held on March 12, 2014. The logs are at:
17:02:58 <arrbee> #link https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2014-03-12
17:03:44 <arrbee> My team mates present today are aharoni kart_ Nikerabbit divec pginer
17:04:16 <aharoni> Tung!
17:04:23 <arrbee> In today's session we would like to talk about our recent work and end with an open session for Q & A
17:04:49 <arrbee> == Changes in translation file format and LocalisationUpdate ==
17:05:32 <arrbee> A few days back announcements were made about changes in the format of the localization files that are used for the MediaWiki core and extensions
17:06:12 <arrbee> Earlier PHP files were used but due to several shortcomings like huge file sizes and security concerns, it was decided to use JSON format instead
17:06:48 <arrbee> The JSON format was also preferred for interoperability outside MediaWiki, for projects like Visual Editor and Universal Language Selector
17:06:54 <arrbee> VisualEditor*
17:07:13 <arrbee> As a first step, an RFC was created late last year
17:07:24 <arrbee> #link https://www.mediawiki.org/wiki/Requests_for_comment/Localisation_format
17:07:49 <arrbee> Engineers from Language Engineering and VisualEditor teams collaborated on assessing the implementation details
17:08:11 <arrbee> A script was written to create JSON formatted i18n files from the PHP files
17:08:24 <arrbee> #link https://www.mediawiki.org/wiki/Manual:GenerateJSONi18n.php
17:09:09 <arrbee> LocalisationCache and LocalisationUpdate was modified to handle the changes
17:09:51 <arrbee> Earlier this month MediaWiki core code was prepared to begin use of the JSON files for localization
17:10:11 <arrbee> Several extensions have also been converted
17:10:24 <arrbee> More about this change on the following links:
17:10:35 <arrbee> #link https://www.mediawiki.org/wiki/Localisation_file_format
17:10:39 <arrbee> #link https://www.mediawiki.org/wiki/Manual:GenerateJSONi18n.php#Suggested_migration_process
17:11:08 <arrbee> The second URL points to instructions about converting the MediaWiki extensions to use JSON
17:11:44 <arrbee> Nikerabbit: Would you like to add anything more about this update?
17:12:51 <Nikerabbit> yep
17:12:58 <alolita> Nikerabbit: would you like to walkthrough why we migrated to using JSON and the benefits we see
17:13:18 <arrbee> Hi alolita
17:13:34 <Nikerabbit> well, runa quickly went over the benefits already, more details are in the blog post
17:13:53 <arrbee> (which will be published by the end of this week)
17:14:08 <Nikerabbit> will be then ;)
17:14:31 <Nikerabbit> but in short: we have now more secure file format, which is easier to handle in and outside MediaWiki environment
17:14:34 <arrbee> Keep an eye out for the new post on:
17:14:37 <arrbee> #link http://blog.wikimedia.org/c/technology/features/internationalization-and-localization/
17:15:24 <Nikerabbit> there have been some issues related to LocalisationUpdate and updating the Wikimedia cluster, I expect everything to be back to normal next week
17:16:09 <Nikerabbit> Also, if you have extensions not in Gerrit, please take a moment to convert your extension now before you forget, as the old style php files will not be supported forever
17:16:48 <arrbee> Thanks Nikerabbit
17:17:03 <arrbee> Next topic:
17:17:05 <arrbee> == Content Translation ==
17:17:26 <Nemo_bis> Hi Nikerabbit
17:17:36 <arrbee> Development of the Content Translation project continues
17:17:58 <arrbee> Hey Nemo_bis … please go ahead if you have a question
17:19:18 <arrbee> Ok.. I will go ahead with updates on Content Translation :)
17:19:52 <arrbee> Currently we are focusing mainly on the server side development
17:20:57 <arrbee> It is not directly visible to the user, but it is supposed to make the feature perform better and robust thanks to smart caching
17:21:34 <arrbee> There is, however, one notable user-level feature which is being developed now - a red interlanguage link
17:22:19 <arrbee> If a logged-in user sets a different interface language and views an article that is not available in that language, a red link will be shown in the interlanguage links list
17:22:43 <arrbee> Clicking that link will take the user to a translation interface
17:23:03 <arrbee> We plan to deploy an early working version of this feature on our testing site next week
17:23:54 <Nemo_bis> what site
17:23:55 <arrbee> And hope to deploy it as a beta feature in some Wikipedias later this year
17:24:16 <arrbee> Nemo_bis:
17:24:20 <arrbee> #link http://language-stage.wmflabs.org/index.php/Main_Page
17:24:25 <Nemo_bis> k
17:24:36 <arrbee> you can see a prototype here:
17:24:48 <arrbee> #link http://pauginer.github.io/prototype-uls/#mies
17:25:50 <arrbee> Also, adding the ability to have red interlanguage is bug number 11 (from 2004) on the wikimedia bugzilla :)
17:26:00 <arrbee> #link https://bugzilla.wikimedia.org/show_bug.cgi?id=11
17:26:24 <arrbee> aharoni: divec : anything more to add about Content Translation?
17:27:19 <aharoni> Nothing much to add...
17:27:25 <aharoni> I just happen to be very excited about it,
17:27:37 <aharoni> because today morning I gave a Wikipedia workshop,
17:27:51 <aharoni> and a lot of people wanted to translate articles,
17:28:34 <aharoni> and I had to tell them to go to the Wikipedia in the target language, search for the new article, click the red link, write it, and then go to Wikidata to add an interlanguage link,
17:28:47 <alolita> translate from english to hebrew?
17:29:10 <matanya> yeah, it is somewhat troublesome
17:29:34 <aharoni> and I hope that in a few months I'll be able to say: click the red link, write your article and save.
17:29:40 <aharoni> and everything else will be automatic.
17:30:02 <kart_> aharoni: the day it will be! :)
17:30:03 <aharoni> alolita: English to Arabic, Hebrew to Russian, Spanish to Hebrew, and some more.
17:30:31 <arrbee> aharoni: nice!
17:30:52 <aharoni> (The people there also loved Echo and VisualEditor, but that's off-topic now.)
17:31:19 <arrbee> Thanks aharoni :)
17:31:38 <arrbee> Before we go into the Q & A, there is a quick announcement
17:31:39 <aharoni> divec: anything to add about the ContentTranslation backend magic?
17:31:47 <alolita> aharoni: automatic translation is very hard to provide for most language pairs
17:32:41 <alolita> high quality automated translations (machine translation)
17:33:01 <alolita> arrbee: what is the announcement :)
17:33:06 <arrbee> aharoni: I suspect divec stepped out :)
17:33:14 <arrbee> ^^ is not the announcement
17:33:44 <arrbee> We would like to clarify that the ongoing Typography Refresh on Wikimedia sites is not connected with the Universal Language Selector or webfonts (part of ULS)
17:34:11 <arrbee> More about Typography Refresh on the blog from our colleagues in the Design team:
17:34:18 <arrbee> #link https://blog.wikimedia.org/2014/03/27/typography-refresh/
17:34:35 <arrbee> == Q & A ==
17:34:51 <arrbee> open session...
17:35:10 <arrbee> We have 25 more minutes
17:38:37 <Nikerabbit> sneak peek: I am working with kart_ and manybubbles for improving translation memory & translation search performance and stability
17:39:20 <Nikerabbit> it's likely coming to translatewiki.net next week, to WMF perhaps in about a month
17:39:25 <alolita> nice work Nikerabbit!
17:40:24 <aharoni> so I have a question to the audience.
17:40:40 <aharoni> did anybody here try the Compact interlanguage links beta feature?
17:41:23 <Nemo_bis> yes
17:41:34 <manybubbles> yay
17:41:45 <Nemo_bis> folks really need to submit CLDR bugs https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ#How_does_Universal_Language_Selector_determine_which_languages_I_may_understand
17:41:47 <aharoni> Nemo_bis, I'd love to hear your thoughts.
17:42:07 <Nemo_bis> I'm sure everyone can find tons of errors in http://www.unicode.org/cldr/charts/latest/supplemental/territory_language_information.html for their country
17:42:10 <aharoni> +1 :)
17:42:40 <arrbee> more about Compact Interlanguage Links at:
17:42:45 <arrbee> #link https://www.mediawiki.org/wiki/Universal_Language_Selector/Design/Interlanguage_links
17:42:57 <aharoni> Nemo_bis: Things do change there. For example, in the past Yiddish wasn't included under Israel,
17:43:08 <aharoni> and now it is.
17:43:40 <aharoni> But yes - people should submit bugs about their countries.
17:43:55 <aharoni> Also, there used to be a bug with Tagalog, because it was listed as Filipino in CLDR,
17:44:20 <aharoni> so the biggest language of the Philippines didn't actually appear,
17:44:24 <aharoni> so we made it into an alias on our side.
17:46:10 <Nemo_bis> yes, the CLDR committee chief is extremely helpful
17:48:14 <arrbee> Nemo_bis: Thanks for bringing that up. Also did you want to poke about https://gerrit.wikimedia.org/r/#/c/72867/ ?
17:49:44 <Nemo_bis> no
17:50:07 <arrbee> okay
17:50:09 <Nemo_bis> thanks
17:50:20 <arrbee> no worries
17:50:57 <arrbee> Changing context.. there are quite a few session/talk submissions for Wikimania. The list is here:
17:51:01 <arrbee> #link https://www.mediawiki.org/wiki/Language_portal/Wikimania2014
17:52:15 <arrbee> Do please sign up if any of them interests you
17:53:19 <Nikerabbit> whii
17:54:15 <arrbee> We have 5 more minutes
17:55:04 <Pavanaja> Good night/day. bye
17:55:25 <arrbee> Thanks Pavanaja for joining in
17:55:49 <bd808> I'd like to thank Nikerabbit and everyone else who help me debug the l10nupdate issues.
17:56:18 <bd808> And for the record the problem was in scap for a long time
17:56:23 <aharoni> oh bd808 thank you so much from us as well.
17:56:29 <arrbee> :)
17:56:41 <bd808> So it was in no way caused by the json changes (just brought to the surface)
17:56:54 <alolita> bd808: makes scap even more awesome in the long run :-)
17:57:10 <bd808> s/awesome/less broken/ :)
17:57:21 <alolita> bd808: :-)
17:57:24 <Nikerabbit> bd808: thanks to you too
17:57:39 <aharoni> bd808: a song for you inspired by your nick: https://www.youtube.com/watch?v=DAvvqZQZIHE
17:58:04 <kart_> bd808: Thanks!
17:58:55 <arrbee> Closing time. Please join us on #mediawiki-i18n after office hour ends
17:59:03 <arrbee> #info If nothing changes then our next office hour would be on 14 May 2014
17:59:36 <arrbee> Language Engineering office hours are held every 2nd Wednesday of the month at 1700 UTC on this channel
18:00:00 <arrbee> Our mailing list is mediawiki-i18n@lists.wikimedia.org and IRC channel is #mediawiki-i18n
18:00:06 <Nikerabbit> arrbee: I'm flying at that time
18:00:26 <arrbee> Nikerabbit: aha.. then 'something changes'
18:00:48 <arrbee> I will announce if we decide to change the date for May
18:01:06 <arrbee> Thanks for the information Nikerabbit
18:01:26 <arrbee> Thanks everyone. We will post the logs shortly on metawiki.
18:01:35 <arrbee> #endmeeting

Generated by MeetBot 0.1.4 (http://wiki.debian.org/MeetBot)

Time: 22:00-23:00 UTC
Channel: #wikimedia-office
Timestamps are in UTC.
[22:00:20] <sumanah> #startmeeting RfC review ("what next?") | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours
[22:00:21] <wm-labs-meetbot> Meeting started Wed Apr 9 22:00:21 2014 UTC and is due to finish in 60 minutes. The chair is sumanah. Information about MeetBot at http://wiki.debian.org/MeetBot.
[22:00:21] <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
[22:00:21] <wm-labs-meetbot> The meeting name has been set to 'rfc_review___what_next______channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours'
[22:00:28] <sumanah> #chair sumanah brion TimStarling
[22:00:29] <wm-labs-meetbot> Current chairs: TimStarling brion sumanah
[22:00:38] <sumanah> #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-09
[22:00:41] <brion> \o/
[22:00:43] <sumanah> #info Today is a 40-minute meeting
[22:00:43] <sumanah> #info we're asking "is this still valid? what are next steps?" on UserMailer refactor, Nonlinear versioning, Authstack, Abstract table definitions, & support for user-specific page lists in core
[22:01:11] <sumanah> #chair sumanah brion TimStarling mark
[22:01:12] <wm-labs-meetbot> Current chairs: TimStarling brion mark sumanah
[22:01:20] <sumanah> #topic UserMailer refactor
[22:01:25] <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_refactor by Owen Davis
[22:01:34] <sumanah> #info Owen Davis last updated this in late 2013 and hasn't gotten any feedback.
[22:01:35] <sumanah> #info Any objection to moving forward?
[22:01:51] <brion> my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape
[22:01:57] <sumanah> (it's such a short RfC, either it's simple or the RfC is too short)
[22:02:01] <sumanah> #info <brion> my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape
[22:02:12] <awight> I think it's a bad idea to pass the desired mailer class via the send() method.
[22:02:20] <sumanah> #info <awight> I think it's a bad idea to pass the desired mailer class via the send() method.
[22:02:28] <awight> abstracting the mailer is a great idea, however.
[22:02:41] <MaxSem> I don't like the growing number of parameters to the static function, it's scary enough already
[22:02:44] * awight reads http://wiki.debian.org/MeetBot.�
[22:02:46] <MaxSem> use OOP?
[22:03:10] <sumanah> (these seem like things we ought to mention to Owen on the talkpage; I encourage anyone talking now to expand on their thoughts at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/UserMailer_refactor )
[22:03:30] <awight> agreed
[22:03:31] <sumanah> (if they have any expansion on their thoughts)
[22:03:36] <ebernhardson> personally, i find it really odd to even consider a mailer refactor before looking at the underlying mail system (such as Swift_Mailer mentioned in see also)
[22:03:41] <MaxSem> and where's their code?
[22:04:04] <sumanah> good question
[22:04:06] <brion> yeah, it’s a bit light
[22:04:36] <sumanah> parent5446: the end of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140409.txt for the chat till now :)
[22:04:37] <brion> now it seems the point of the rfc is ‘make it easier to merge the wikia changes’
[22:04:45] <parent5446> sumanah: thanks
[22:04:51] <brion> if that’s mostly ‘we have an extra class and adding these params makes it trivial to plug in’ then that’s probably spiffy
[22:04:59] <MaxSem> I think this RFC should be declined
[22:05:04] <ebernhardson> i agree
[22:05:24] <brion> needs moar code
[22:05:34] <MaxSem> a solution would be a class with eg function addAttachment(), not a huge parameter list
[22:05:47] <ebernhardson> and those solutions already exist, we should just be chosing one
[22:06:00] <parent5446> Keep in mind we have a GSoC project working on using SwiftMailer in core
[22:06:13] <parent5446> That would fulfill most of the goals of this RFC
[22:06:32] <brion> #info seems to be some agreement that using SwiftMailer as backend would resolve this better
[22:06:39] <sumanah> so it sounds like someone should summarise this for the RfC talk page, or possibly we should just decline this
[22:07:15] <brion> i’ll add a quick note
[22:07:29] <sumanah> #action brion to summarise this discussion on RfC talk page (re user mailer)
[22:07:39] <sumanah> OK, let's move on to AuthStack
[22:07:45] <sumanah> #topic Authstack
[22:07:49] <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/AuthStack
[22:07:55] <sumanah> #info Tyler updated this earlier this year. He responded to a request and "reduced the scope of the RFC by removing the Permissions infrastructure and the ClientSession class." So we could use a fresh opinion.
[22:07:59] <sumanah> (parent5446 that is)
[22:08:50] <brion> oh authn/z…. what a fun world :D
[22:09:09] <sumanah> csteipp: you probably have opinions ^
[22:09:17] <parent5446> Yeah, so the goal of this is to get rid of the ChainedAuth hook in LdapAuthentication
[22:09:28] <parent5446> B/c it's basically a hack to allow more than one authnz method
[22:09:55] <sumanah> (while I wait for other people to respond: I am writing to you from a hallway at PyCon, the Python convention. It is in Montreal, so I have unearthed the French I learned 15 years ago. Je voudrais acheter un bilet!)
[22:10:06] <csteipp> I really do like the concept in general. The ldap especially makes a compelling use case.
[22:10:30] <parent5446> It also tries to adopt the whole service-oriented architecture theme we have going
[22:11:26] <brion> i’ll defer to those who have been poking at auth code more recently on this one, but it sounds good in theory
[22:11:40] <brion> old AuthPlugin was a bit hacky and was done without benefit of experience in using said plugins :D
[22:12:07] <brion> any implications for LDAP, CentralAuth, etc?
[22:12:09] <parent5446> I do need feedback on one thing. Is it OK to use ExternalUser as a class name? Because it is the same class name as the recently removed ExternalUser experiment.
[22:12:25] * brion whispers “namespaces!”�
[22:12:47] <parent5446> Lol, I can put this stuff in a namespace if we support putting core classes in namespaces
[22:13:34] <brion> parent5446: worst case we can change the class name i guess :)
[22:13:35] <csteipp> Was there an "ExternalUser experiment"? I missed that. The name sounds ok to me, but "ExternalAuthUser" would be fine too
[22:13:49] <brion> actually i’d kinda prefer ExternalAuthUser, that’s more descriptive
[22:13:55] <parent5446> Yeah, I think it was removed in a previous version. I don't think anybody ever used it
[22:14:13] <sumanah> peut-etre Tim pense un quelque chose ici <----- (terrible high school French for "maybe TimStarling thinks something here")
[22:14:22] <parent5446> I'd support ExternalAuthUser as well.
[22:14:44] <sumanah> (since he was the one to comment in July)
[22:14:51] <csteipp> Definitely look into the bug that we have open about initializing users using session setup... just to avoid the situation we're currently in
[22:14:53] <brion> #info some agreement to changing ExternalUser to ExternalAuthUser for clarity and to avoid potential conflict
[22:15:46] * sumanah waits another minute for Tim to speak up before we move on to Abstract table definitions (which should be quick)�
[22:16:03] <brion>  :)
[22:16:16] <sumanah> hmm, anything else to #info here?
[22:16:50] <sumanah> #info a few people like the idea in general
[22:16:51] <parent5446> Once I finish up the Password patch I'll start working on AuthStack code
[22:16:52] <brion> #info people seem to like the general idea — likely to proceed?
[22:16:54] <MaxSem> #info Everyone believes it's generally a good idea
[22:16:58] <brion> :D
[22:17:06] <sumanah> #info <parent5446> Once I finish up the Password patch I'll start working on AuthStack code
[22:17:16] <sumanah> All right
[22:17:16] <sumanah> #topic Abstract table definitions
[22:17:20] <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Abstract_table_definitions
[22:17:24] <sumanah> #info This should be quick. I'm assuming the comment from Tim, "Seek comment on DSL details." from late July 2013, still holds. I don't think this one needs any discussion, I just wanted to give people a heads-up that it exists, in case anyone wants to collaborate with Daniel Friesen on it.
[22:17:40] <MaxSem> okay, my opinion about it was requested and I'm sceptic
[22:17:55] <sumanah> "... this is a proposal for an abstract language for defining tables, indexes, alters, etc... that; Can be sanely written and read. Is not raw sql (we'll probably PEG parse it) and can be used to build the database for any database engine we support. And can be used by extensions too to define their database pieces abstractly so the extension will work in other databases."
[22:18:14] <csteipp> parent5446: bug 41201
[22:18:25] <MaxSem> what's abstract in proposed "table hitcounter {
[22:18:25] <MaxSem> @ENGINE(HEAP)
[22:18:25] <MaxSem> @MAX_ROWS(25000)
[22:18:25] <MaxSem> hc_id uint
[22:18:25] <MaxSem> }" ?
[22:18:37] <awight> I think it's much cleaner to use a basic SQL syntax and transform that to make use of extensions when possible. But parsing is a pain.
[22:18:42] <MaxSem> it's just MySQL-specific DDL in a different wrap
[22:18:51] <parent5446> csteipp: Thanks. That's for the the ClientSession part
[22:19:14] <brion> so the last time i tried something like this was for StatusNet
[22:19:23] <brion> using structured arrays rather than a DSL so no parsing ;)
[22:19:35] <awight> Yeah, Drupal uses that approach. It's pretty heinous...
[22:19:37] <brion> but i also tried to be clever about auto-applying schema updates, and that was hell
[22:19:48] <MaxSem> I guess StatusNet didn't need to support holy Oracle?
[22:19:50] <brion> explicit updates are probably better
[22:19:53] <saper> we are close to getting structural arrays in DatabaseUpdaters
[22:20:03] <brion> no, oracle could take a flying &$^# for all we cared ;)
[22:20:11] <MaxSem> ...together with SQL server and a bunch of FLOSS DBs
[22:20:13] <sumanah> ok, so I was wrong and this does inspire discussion :-)
[22:20:21] <parent5446> Has anybody looked at Doctrine DBAL's schema generator?
[22:20:41] <sumanah> #info skepticism.
[22:20:41] <MaxSem> NO FRAMEWORKS IN CORE!!1 :P
[22:20:46] <brion> nope, got a link handy?
[22:20:49] <parent5446> It's not the same as this RFC, but provides some of the same deliverables
[22:20:52] <parent5446> http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html
[22:21:07] <awight> Hehe. we'll probably need a code generation step in core anyway
[22:21:21] * brion kind of hews to the idea that mysql *is* a database abstraction layer…. from SQL to myisam/innodb/etc ;)�
[22:21:44] <sumanah> Since Daniel isn't here, I feel like I should just point him to this log and ask whether he has any responses
[22:21:52] <MaxSem> can we just ditch myisam support?
[22:22:14] <sumanah> #action sumanah to point Daniel Friesen to log
[22:22:14] <brion> people keep wanting postgres and sometimes oracle and mssql, so it seems like there’d be interest in having consistent support, but without the abstraction nobody maintains them
[22:22:39] <saper> MaxSem: do we support myisam at all?
[22:22:50] <MaxSem> last time i checked
[22:23:05] <brion> parent5446: looks mostly code-based, gets pretty verbose?
[22:23:06] <sumanah> anyone in the WMF SF office? can you see whether Steven Walling &/or Ori Livneh are around? because we're about to move on to their RfC
[22:23:25] <awight> swalling isn't here
[22:24:06] <parent5446> Yeah it's mostly code-based
[22:24:27] <parent5446> But it's a lot easier to integrate than inventing our own SQL replacement
[22:24:33] <brion> my main worry there is verbosity kills maintenance
[22:24:37] <brion> true :D
[22:24:42] <awight> re: doctrine, isn't there a pure YAML schema syntax?
[22:24:44] <sumanah> I'm about to change topic - if people wanna keep talking about the wonderful world of SQL, ORMs, etc., take it to #wikimedia-dev ? :)
[22:24:45] <brion> scary DSLs also kill maintenance ;)
[22:24:52] <brion> ok i’m done :)
[22:25:06] <parent5446> http://doctrine-orm.readthedocs.org/en/latest/reference/yaml-mapping.html
[22:25:12] <saper> I'd love we had record locking under control instead... every second SELECT has now FOR UPDATE or so :(
[22:25:21] <sumanah> #topic support for user-specific page lists in core
[22:25:33] <sumanah> This is Ori & Steven's RfC.
[22:25:34] <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Support_for_user-specific_page_lists_in_core
[22:25:41] <sumanah> #info Ori and Steven last updated this in September 2013. When we discussed it then, we agreed "to expand this RFC somewhat" and that "no one dislikes the basic idea, but ... it's large enough that it's hard to sign off on it completely without further work"
[22:26:18] <awight> fwiw, this work is probably getting rolled into an EducationProgram rewrite
[22:26:20] <sumanah> #info TimStarling said "I will add some comments about the potential need to abstract the backend"
[22:26:30] <sumanah> #info Adam Wight relates: "this work is probably getting rolled into an EducationProgram rewrite"
[22:26:36] <sumanah> awight: around whennish?
[22:27:06] <awight> sumanah: I don't know if that's on the roadmap yet, currently the work is focused on generalizing Campaigns
[22:27:24] <sumanah> AaronSchulz: perhaps you can speak on behalf of your performancey colleague ;-)
[22:27:28] <awight> But the big picture is that StevenW wants to add functionality like the user page lists as components.
[22:28:37] <brion> i like the basic idea; there’s some open question about how tags would be managed though
[22:29:07] <sumanah> looks like we won't have ori or StevenW in this chat today. That's ok
[22:29:08] <brion> …and someone might have to take a flamethrower to some existing watchlist code to clean it up
[22:31:21] <sumanah> awight: do you need Tim to follow up on making comments re abstracting the backend?
[22:31:41] <AaronSchulz> brion: it could work, though it inherits all the sorting problems watchlists have now
[22:31:48] <AaronSchulz> though brad already mentioned that it seems
[22:31:51] <brion> *nod*
[22:31:57] <awight> sumanah: I'm pretty far from that work, but mentioning the complications would be a good idea.
[22:32:13] <AaronSchulz> reminds, we figured out a fix for the externallinks thing he mentioned...someone should do that :)
[22:32:40] <sumanah> #action TimStarling it would be nice if you could add a note to the user specific page lists in core RfC talkpage about abstracting the backend
[22:32:56] * sumanah hopes AaronSchulz or someone else will phrase the externallinks fix thing as an #info�
[22:33:26] <sumanah> (sounds like we can move on pretty soon to Nonlinear versioning which will be candy to some folks)
[22:33:52] <sumanah> #action someone should consult AaronSchulz and anomie re how to fix the externallinks issue
[22:34:02] <AaronSchulz> well that's not actually related, it just reminded me
[22:34:34] <sumanah> oh here
[22:34:37] <ori> hello
[22:34:50] <sumanah> ori: the end of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140409.txt for the chat till now :)
[22:35:30] <sumanah> (in a minute we'll be talking about brainbreaking branching wiki repo stuff)
[22:35:55] <ori> thanks
[22:36:44] <sumanah> I will not be a draconian jerk if you want to follow up a little during the next topic :-)
[22:36:51] <sumanah> #topic Nonlinear versioning
[22:36:56] <sumanah> #link https://www.mediawiki.org/wiki/Requests_for_comment/Nonlinear_versioning
[22:37:01] <sumanah> #info Adam Wight last updated this in August 2013. This feels super experimental so I don't know whether any next actions are necessary; should we encourage Adam to prototype this?
[22:37:15] <awight> There's also a human-language RFC at https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica
[22:37:17] <sumanah> awight: ^ :) I could be wrong!
[22:37:29] <sumanah> #link https://meta.wikimedia.org/wiki/Grants:IdeaLab/Edit_your_replica human-language RfC
[22:37:30] <awight> sumanah: no, you nailed it. I need to know if anyone out there cares.
[22:37:44] <awight> Technically, it's almost straightforward.
[22:37:53] * sumanah imagines awight singing his plaintive lament on a stage. "does anyone caaaaaare"�
[22:37:56] <TimStarling> "It has been pointed out that the current "revision" table already supports arbitrary directed graphs"
[22:38:00] <TimStarling> no it doesn't
[22:38:18] <awight> revision.parent can point to anything...
[22:38:27] <brion> yeah but not much uses rev_parent
[22:38:33] <awight> oic!
[22:38:35] <brion> most stuff assumes order
[22:38:42] <brion> by timestamp and/or id
[22:38:45] <TimStarling> if you actually used that for branches, you wouldn't be able to display a single branch efficiently
[22:38:59] <TimStarling> you would have to actually traverse the rev_parent linked list, which would take forever
[22:39:21] <awight> I think I had a shortcut for that... yeah, a link table which marks each revision with a branch name.
[22:39:27] * brion hrms�
[22:39:36] <awight> so, along a given branch, the history would look linear.
[22:40:04] <TimStarling> a link table which would pretty much replace the revision table for paging purposes?
[22:40:19] <TimStarling> hundreds of GB of extra indexes etc.?
[22:40:25] <awight> probably, but the history pager would... be a totally different animal.
[22:40:35] <sumanah> awight: I know there are people out there - not so much in the active wikitech-l community, but out there - who care about this sort of thing. David Gerard is one
[22:40:37] <sumanah> I think
[22:41:11] <awight> Possibly, a compelling use case is: "Handle massive editing demand for breaking news articles"
[22:41:17] <sumanah> I feel like I keep hearing people at conferences who want to expound on this sort of idea after a beer or two
[22:41:23] <awight> lol i bet
[22:41:34] <TimStarling> the questions I have about this are:
[22:41:38] <TimStarling> 1) do we want it?
[22:41:47] <TimStarling> 2) how much hardware are we willing to buy to get it?
[22:42:11] <MaxSem> 1) I think it's going to be helluva confusing for most users
[22:42:14] <TimStarling> 3) how do you make efficient use of that extra hardware? what schema, what server, etc.?
[22:42:27] <sumanah> #action awight http://opensourcebridge.org/blog/2014/03/submit-your-2014-proposals-today/ ;-) (I bet people would come to your talk)
[22:42:28] <awight> MaxSem: agreed, the complexity should be hidden most of the time.
[22:42:50] <sumanah> is this maybe less for Wikimedia wikis and more for other wikis that people run for other purposes?
[22:43:01] <brion> branching in svn and git is hard enough for devs who work with it every day. a good UX for a branching mechanism is HARD
[22:43:09] <awight> Yes absolutely.
[22:43:11] <sumanah> digital humanities stuff, SMW installs, art projects?
[22:43:25] <TimStarling> you know that we are considering redesigning the revision system along SOA lines
[22:43:31] <awight> The first phase would probably not be long-running branches. It would be conflict resolution.
[22:43:34] <sumanah> awight: have you already looked at SparkleShare/Glitter Gallery which attempts to make git usable by designers?
[22:43:59] <awight> sumanah: thx, I'll check it out
[22:44:21] <awight> TimStarling: no, pls send a link if you have it
[22:44:23] * sumanah slightly ignores 40-minute meeting limit but doesn't want to go much above 45 or 50�
[22:44:38] <TimStarling> there's no link afaik
[22:44:41] <sumanah> #info <TimStarling> you know that we are considering redesigning the revision system along SOA lines
[22:44:53] <awight> My personal next step is to collect edit conflict statistics, so we know if the massive demand to edit current news is a valid use case.
[22:44:54] <TimStarling> gwicke has been plugging the idea
[22:45:14] <sumanah> #info this might be better for non-Wikimedia wikis, or for use by massively multiplayer editing on fast-breaking news topics
[22:45:31] <TimStarling> you can reduce edit conflict rates without branching
[22:45:37] <sumanah> #info Tim's questions: 1) do we want it? 2) how much hardware are we willing to buy to get it? 3) how do you make efficient use of that extra hardware? what schema, what server, etc.?
[22:45:41] <awight> hehe by fixing oldid for example ;)
[22:46:17] <TimStarling> you know we still just use diff3 for edit conflict merging
[22:46:29] <sumanah> #info performance, how to alter the DB schema, what does the current schema support
[22:46:33] <TimStarling> a system which must have taken less than an hour to implement
[22:46:59] <awight> TimStarling: yes, but word-based conflict resolution is currently unsolved AFAIK
[22:47:08] <awight> I think it's gonna remain a human task
[22:47:56] <TimStarling> unsolved? you're saying someone has tried to solve it?
[22:48:37] <awight> The second use case that I think is relevant to WMF is to improve article protection, to make articles editable by anyone, all the time, but to shift the work from spam patrolling on suspicious edits to having a merge-resolution work queue.
[22:48:40] <TimStarling> but what proportion of edit conflicts result from intraline editing? in my experience, it is mostly adding new lines to the ends of lists
[22:48:57] <awight> TimStarling: that's the thing... we don't have any statistics on edit conflicts. They are not logged.
[22:49:30] <sumanah> they aren't? I did not know that
[22:49:47] <awight> Argh, I had a patch for that and... cannot find it.
[22:49:48] <TimStarling> well, we can already make articles editable by anyone, all the time
[22:50:15] <sumanah> We're now 10 min over
[22:50:24] <sumanah> next steps for awight?
[22:50:26] <TimStarling> it's called pending changes
[22:50:48] <awight> TimStarling: it's linear however, so vandalism still affects future editing, right?
[22:51:10] <TimStarling> yes, but that's not why it's underused, is it?
[22:51:36] <awight> no, it'
[22:51:49] <awight> it's probably because it creates a huge workload that nobody is ever going to do ;)
[22:52:25] <awight> also, perhaps cos FlaggedRevs is overdue for a rewrite.
[22:53:50] <sumanah> so: my opinion is that I want Adam to keep investigating this but it would need more thinking before getting to something where we want to prototype it, and he should have more detailed answers to Tim's 3 questions
[22:54:28] <awight> Sure, but fwiw I cannot answer (1) myself
[22:54:37] <sumanah> and Adam ought to reach outside the wikitech-l community to find potential users
[22:54:40] <TimStarling> I would like to see some more rationale on the RFC
[22:54:53] <awight> TimStarling: did you look at the IdeaLab page? I put the motivations there...
[22:54:55] <TimStarling> comparing it to other ways of implementing a draft feature
[22:55:09] <TimStarling> not yet, no
[22:55:31] <sumanah> awight: maybe you should just transclude that stuff onto the RfC - the RfC will basically be the canonical document for motivation & implementation/architecture
[22:55:38] <sumanah> (or just copy-n-paste)
[22:55:46] <awight> makes sense, thanks
[22:55:48] <sumanah> ok, I'm declaring some next actions :)
[22:56:34] <sumanah> #action awight to keep investigating this, move motivations from Idealab page onto RfC, compare his idea to to other ways of implementing a draft feature, try to answer Tim's questions 2 & 3, and look for potential users (maybe 3rd party wikis)
[22:56:54] <sumanah> #endmeeting

RFC meeting

edit

See mw:Architecture meetings/RFC review 2014-04-09.

Retrieved from "https://meta.wikimedia.org/w/index.php?title=IRC_office_hours/Office_hours_2014-04-09&oldid=15268764"