[14:30:36] * andre__ wonders where Deskana is [14:31:23] so let's wait another 3 minutes [14:31:29] ah, people are showing up :) [14:31:29] o/ [14:31:51] hey andre__ [14:31:58] heja DanielK_WMDE__! [14:32:27] Morning. :) [14:32:35] hi Deskana! [14:32:41] So welcome everybody to the bugday! We haven't had one for a while :) [14:33:02] central page is https://www.mediawiki.org/wiki/Bug_management/Triage/20140429 [14:33:11] and Etherpad is https://etherpad.wikimedia.org/p/BugTriage (in case we need it) [14:33:32] And we want to ;look a bit at tickets in bugzilla.wikimedia.org filed under "MediaWiki > General/Unknown" [14:33:43] which is the fallback component for "I have no idea where to put this" so it needs some cleanup from time to time [14:34:16] I see three aspects that we might want to focus on in those next ~120 minutes of this bugday [14:34:27] Check if the priority of a ticket is correct (lowering might be realistic sometimes if nobody plans to work on an item). [14:34:34] errm ^ 1. [14:34:43] 2. Check if there is a better Bugzilla component that fits better - https://bugzilla.wikimedia.org/describecomponents.cgi?product=MediaWiki [14:34:56] 3. Check if there are some folks/devs in that specific area who could be CC'ed on the ticket to provide input. [14:34:57] So we can use this search for the bug list: https://bugzilla.wikimedia.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=PATCH_TO_REVIEW&bug_status=REOPENED&bug_status=VERIFIED&component=General%2FUnknown&list_id=310392&product=MediaWiki&query_format=advanced&resolution=--- [14:35:10] Anything that's not resolved or closed in that component. [14:35:23] yes! [14:35:34] or we could also use the table with the looong link in https://etherpad.wikimedia.org/p/BugTriage [14:35:45] which has all these tickets as "severity x priority" [14:35:57] basically it's a bit about "thinking aloud" here on IRC [14:36:04] or asking others for help when being not sure [14:37:16] * andre__ pinged on https://bugzilla.wikimedia.org/show_bug.cgi?id=63251 as that looks fixed to me [14:37:59] https://bugzilla.wikimedia.org/show_bug.cgi?id=63614 has an unanswered question to another commenter, so I'll ask that question again [14:38:37] Deskana: any questions? Confusion? Ideas? :) [14:38:59] All's good here. I'm looking at bugs. [14:39:01] and is DanielK_WMDE__ also in for triaging some tickets, or did you just say hello here? :) [14:39:11] fwiw my motivation is to kick bugs that haven't seen any any activity for a longest time: https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&component=General%2FUnknown&list_id=310391&order=changeddate%2Cbug_id&product=MediaWiki&query_based_on=&query_format=advanced&resolution=--- [14:39:14] i'm closing https://bugzilla.wikimedia.org/show_bug.cgi?id=18544 as wontfix. visual glitch with line height in ie6 [14:39:28] thedj, hi! awesome, you're around too :) [14:39:30] welcome [14:39:56] yeah, probably wontfix, indeed. [14:40:45] Reedy, the bug related with this Bug Day that hasn't seen any activity in a longest time is actually yours: https://bugzilla.wikimedia.org/show_bug.cgi?id=26333 [14:41:01] :D [14:41:13] Reedy, (and I don't even understand it, so there is little I can do) [14:41:17] https://bugzilla.wikimedia.org/show_bug.cgi?id=21318 WONTFIX as Growth is now handling onboarding and there are smarter ways to onboard users than make messages more persistent [14:43:16] I ping again the reporter on https://bugzilla.wikimedia.org/show_bug.cgi?id=64220 - this needs more info about the FastCGI webserver configuration [14:43:41] ("WebRequest.php:682: Web server doesn't provide either REQUEST_URI, HTTP_X_ORIGINAL_URL or SCRIPT_NAME") [14:44:10] Requests for hooks don't have any better component than General/Unknown? https://bugzilla.wikimedia.org/show_bug.cgi?id=24297 [14:44:27] Krinkle, yours ^^^^^ [14:44:48] https://bugzilla.wikimedia.org/show_bug.cgi?id=62443 Aaron Schulz was working on ActiveUsers recently and I think allowing sorting might make it incredibly nonperformant... I'll ping Aaron for input [14:45:13] qgil, not that I'm aware of. Today's bugday might also be a good way to find out which "keywords/components" we might miss [14:45:51] Deskana: ah, this is info where it's helpful to have your brain around :) [14:46:06] qgil: said private wiki no longer exists. I no longer care about this bug. [14:46:38] use case hasn't come up since as most people either dont have advanced needs or they dont use the built in hitcouter (e.g. they might use google analytics instead) [14:47:04] andre__: :) [14:47:35] which test server had tidy disable again ? [14:48:16] oh wait, my own of course [14:52:36] In https://bugzilla.wikimedia.org/show_bug.cgi?id=63872 ("Wikimedia and MediaWiki footer buttons should be SVG or HiDPI") I'm adding the "easy" keyword (for people who can handle an SVG editor) [14:54:23] https://bugzilla.wikimedia.org/show_bug.cgi?id=30072 Just going to set that to low and leave it at that [14:54:51] I'll close https://bugzilla.wikimedia.org/show_bug.cgi?id=62641 as WORSKFORME - no reply by reporter after two pings [14:56:53] Reedy, for stuff like https://bugzilla.wikimedia.org/show_bug.cgi?id=62896 (Fatal error: Call to a member function preSaveTransform() on a non-object in EditPage.php on line 3260) it would be awesome if you could mention how often it happens, as that influences the priority :) [14:57:16] (or if it *still* happens nowadays, as in this bugday) [15:00:26] https://bugzilla.wikimedia.org/show_bug.cgi?id=36911 [15:00:37] Setting to low... I echo andre__'s comments. :) [15:01:09] evening [15:01:42] hello [15:02:04] hi [15:02:13] * andre__ retests https://bugzilla.wikimedia.org/show_bug.cgi?id=58172 but still valid :-/ [15:02:20] hi everybody! [15:02:28] Krinkle, https://bugzilla.wikimedia.org/show_bug.cgi?id=24297 wontfixed. Thank you. [15:03:42] Nikerabbit, Edokter, Krenair: If you want to join triaging some general MediaWiki tickets a bit, the Bugzilla query is in https://etherpad.wikimedia.org/p/BugTriage [15:04:03] https://bugzilla.wikimedia.org/show_bug.cgi?id=2939 Orange bar of doom bug, so moved to Echo and set to invalid [15:04:11] found it. in what order are we doing them? [15:05:14] Edokter: Whatever order you like. :) [15:05:25] Edokter, whatever tickets sound interesting to you, may that be the summary topic, or age, or priority, .... [15:05:32] OK [15:05:47] I'm picking things based on title if I think I can add something to them. [15:06:14] "Print more information about uncallable hooks" https://bugzilla.wikimedia.org/show_bug.cgi?id=62448 sounds useful but nobody CC'ed. Wondering who could work on that [15:06:21] i went trough trivial [15:07:11] Is Daniel Friesen around? ref https://bugzilla.wikimedia.org/show_bug.cgi?id=13634 [15:08:55] found one: 55555 seems to be a Firefox bug [15:08:56] qgil: he is unassigned from the tracking ticket that this blocks. [15:09:08] https://bugzilla.wikimedia.org/show_bug.cgi?id=55555 [15:09:16] * andre__ closes https://bugzilla.wikimedia.org/show_bug.cgi?id=62631 as WONTFIX [15:09:55] Edokter, I never managed to reproduce that one [15:10:04] trying now [15:12:06] thanks thedj , marked the report as Lowest [15:13:19] I moved https://bugzilla.wikimedia.org/show_bug.cgi?id=64602 so it would get some attention from the right people [15:13:30] (General/Unknown → Internationalization) [15:13:31] Krenair, thanks [15:14:12] System hangs when installed without extensions on 1.22RC2 - https://bugzilla.wikimedia.org/show_bug.cgi?id=57671 and runJobs.php - I guess I'll ask if it's still an issue [15:14:13] Now all the bugs at https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&component=General%2FUnknown&list_id=310391&order=changeddate%2Cbug_id&product=MediaWiki&query_based_on=&query_format=advanced&resolution=--- have seen any action at least in 2011 [15:14:21] qgil, \o/ [15:14:32] (it was 2008) :) [15:15:10] uhm [15:15:42] Please take a look at this report https://bugzilla.wikimedia.org/show_bug.cgi?id=63483 on shifting from phpmailer to swiftmailer. Not much progress around :( [15:15:44] Kicked about 5 reports to more precise components, wontfixed 2, triaged about 12. Must go now to prepare the ECT showcase starting in 45 minutes. [15:16:00] qgil, thanks! [15:16:57] tonythomas: you set that to high priority yourself. Did you reach out for discussion on wikitech-l@? [15:17:30] andre__: actually, it was put up in wikitech-i, will paste the link in a min [15:18:04] tonythomas, link in bug report welcome. or pinging again on wikitech-l@ if you need more feedback. But in general if you want things to happen, you need to make them happen :) [15:18:27] plus probably a good analysis of pros and cons [15:19:00] http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075653.html [15:19:10] not much progress there too [15:19:16] https://bugzilla.wikimedia.org/show_bug.cgi?id=41373 [15:19:41] i'm sure we have some tickets around with these 2 issues being pointed out. anyone wanna help find them ? [15:20:21] tonythomas, paste the link in the Bugzilla ticket, collect pros and cons of switching, ping again on the mailing list? [15:20:41] andre__: ok. will do that rightway [15:20:54] thedj: uh, that funny format. https://bugzilla.wikimedia.org/show_bug.cgi?id=41371 might have some more items listed as dependencies [15:23:02] andre__: got them both [15:23:05] thedj: I'd remove "Future Release" TM from https://bugzilla.wikimedia.org/show_bug.cgi?id=41373 (other thumbnail issues happen way more often) and rephrase the summary to mention "small width, large height" or such [15:23:26] because the filename doesn't tell us what the issue is [15:24:15] andre__: closed as dupe [15:24:26] thedj, oh awesome. Thanks for finding it! [15:25:05] andre__: perhaps we should put a multimedia team person on the CC of https://bugzilla.wikimedia.org/show_bug.cgi?id=16416 ? [15:25:18] * thedj doesn't know their email address :( [15:25:49] thedj: Try mtraceur, gdubuc [15:25:57] Bugzilla should autocomplete them [15:26:03] fflorin cannot hurt either [15:26:22] thedj: also, I'd add "blocks: 41371" to 16416 [15:26:29] because it affects thumbnails [15:30:15] Edokter, thanks for closing https://bugzilla.wikimedia.org/show_bug.cgi?id=55555 - I'm never sure with this stuff [15:30:37] it's very difficult to be sure there :D [15:30:56] but Edokter has recently spent some time on the topic, so that helps [15:31:06] You can never be sure, but I was 99% sure it was not something we cound fix. [15:32:31] yeah, Edokter either really knows about fonts, or is got in making me think that he knows about fonts. ;) [15:32:34] *good [15:32:52] :) [15:33:45] little bit of both... [15:36:38] * andre__ sets https://bugzilla.wikimedia.org/show_bug.cgi?id=52129 to low prio as patch was abandoned [15:36:49] (Globals should be explicitly declared in PHP) [15:38:22] I'm moving https://bugzilla.wikimedia.org/show_bug.cgi?id=50973 to CLDR; stacktrace looks like I18N territory [15:42:05] andre__: it's not cldr [15:42:25] Nikerabbit, any better place in mind, seeing that stacktrace? [15:42:32] still looks like I18N to me? [15:43:08] part of it is dupe of 50606 and one part I have not been able to reproduce ;) [15:43:27] Nikerabbit, feel free to move further to "MediaWiki > I18N" then if it's not CLDR [15:43:41] I'm still bad reading PHP stacktraces, I'm more used to C when it comes to this :) [15:44:06] Deskana: any idea who could help (=CC'ing) debugging a bit further "Large Pages not shown: Allowed memory size exhausted (PHP 5.5)" https://bugzilla.wikimedia.org/show_bug.cgi?id=50922 [15:44:27] (might turn out to be a support question though and not a bug, who knows) [15:45:27] andre__: hmm I have seen similar stack trace in other bug I have commented in, but can't find it yet... [15:47:52] andre__: General performance stuff like that could be directed to Aaron Schulz. [15:49:02] Deskana, true, CC'ing him [15:50:52] andre__: found it [15:51:00] Nikerabbit, yay. I was searching for it too [15:55:40] Found https://bugzilla.wikimedia.org/show_bug.cgi?id=5732, which I think needs to be adressed, as it is quite old. [15:56:49] ^ Deskana: What do you think? [15:56:56] * andre__ will have a 5min break to have a cigarette [15:58:07] also away for 5 mins [16:01:16] Let's see. [16:01:26] thedj: For future reference we're in #wikimedia-multimedia, but I'll add myself and a few others to the bug [16:02:34] Yeah, that sounds a bit backwards. [16:03:16] back [16:05:46] anyone know if this is still a problem: https://bugzilla.wikimedia.org/show_bug.cgi?id=26753 [16:05:52] autoloader + skins [16:06:06] Krinkle you reported it originally [16:07:39] * andre__ in parallel joining the Engineering Community Team monthly showcase, so slightly slower in reacting here [16:08:20] i'm about to call it quits. it's dry outside, need to make use of that. [16:09:12] Probably [16:09:37] Nikerabbit, can I trick you into commenting on https://bugzilla.wikimedia.org/show_bug.cgi?id=46612 ? [16:12:16] * andre__ moves https://bugzilla.wikimedia.org/show_bug.cgi?id=36662 to Echo [16:13:31] andre__: possibly, let me finish this meeting first [16:13:41] ah, sorry [16:14:26] * andre__ takes a look at https://bugzilla.wikimedia.org/show_bug.cgi?id=37539 - Image thumbnailing on WAMP sometimes locks up [16:14:59] andre__: well, that's it for me. good run [16:15:08] thedj, thanks so much for joining! [16:15:20] and lucky for me that i'm waiting for a restore of a backup, causing me to have some time to participate :) [16:15:27] hehe [16:15:30] I like :) [16:16:03] andre__: Can you check I set this stuff correctly? https://bugzilla.wikimedia.org/show_bug.cgi?id=5732 [16:20:49] Deskana, looks good to me [16:21:19] Deskana, just wondering if you have anybody in mind who could be added to CC [16:23:51] closed https://bugzilla.wikimedia.org/show_bug.cgi?id=17365 as wontfix; minor Monobook design issue [16:27:06] lowering priority on https://bugzilla.wikimedia.org/show_bug.cgi?id=37539, marking as thumbnail issue, unclear if still an issue [16:28:41] LAST CALL FOR TICKETS! We've got two minutes left (but I won't stop you from continuing) [16:30:25] Closed https://bugzilla.wikimedia.org/show_bug.cgi?id=18679 for being too old [16:30:44] Deskana, do you know if https://bugzilla.wikimedia.org/show_bug.cgi?id=40508 was intentional? [16:31:48] Alright. I declare this bugday closed. :) [16:31:55] Thanks a lot everybody for showing up and helping! [16:32:04] I hope you had as much fun as I had! [16:32:23] Again, thanks everybody & see you soon for the next bugday (if you're interested)! :) [16:33:32] Cool. Buglist is down from 582 to 553 tickets. Nice [16:33:58] less then 10% :( [16:34:44] gotta go, until next time [16:35:38] I don't think too much in percentage, more in total numbers [16:35:54] and we commented on way more tickets, these are just the ones that we moved to a better component [16:40:30] andre__: oh hmm that thing... well the short answer that no nothing has been done to my knowledge [16:40:45] Nikerabbit, heh, okay. Feel free to add that as a comment :) [16:41:36] k [16:52:37] Deskana: And thanks for joining this! I hope you also had some fun and that it was interesting! [16:52:42] * andre__ slowly going to sleep now [21:51:33] 10 minutes till we discuss Ryan's and Tyler's RfCs here https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-29 [21:55:50] parent5446: hey there! Happy Tuesday [21:56:23] Hi Ryan_Lane [21:56:34] Hi! Thanks! [21:56:48] howdy [21:57:32] Ryan_Lane: is it fair to introduce your idea by saying "Ryan does not have time to implement this himself but would love to discuss & refine this idea, and would be happy to see someone else take it over"? [21:57:44] well, apparently it's already done [21:58:09] https://gerrit.wikimedia.org/r/119939 ? [21:58:25] yep. that [21:58:26] https://www.mediawiki.org/wiki/Talk:Requests_for_comment/MediaWiki_libraries - right [21:58:27] ok [21:58:41] so, that would be part 1 [21:58:51] part 2 would be actually moving everything else into that directory [21:59:06] and also making it reasonable to move some extensions into that directory [21:59:26] ok. Will say that in intro [22:00:06] parent5446: and I'll be asking you for what you'd like out of today specifically as well :-) in 30 min [22:00:20] brion: Tim-away andrewbogott - shall we start? :-) [22:00:25] \o/ [22:00:34] #startmeeting RfC review: MediaWiki libraries and third-party components | Channel is logged and publicly posted (DO NOT REMOVE THIS NOTE). https://meta.wikimedia.org/wiki/IRC_office_hours [22:00:34] Meeting started Tue Apr 29 22:00:34 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:34] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:00:35] The meeting name has been set to 'rfc_review__mediawiki_libraries_and_third_party_components___channel_is_logged_and_publicly_posted__do_not_remove_this_note___https___meta_wikimedia_org_wiki_irc_office_hours' [22:00:49] #chair sumanah brion andrewbogott [22:00:50] Current chairs: andrewbogott brion sumanah [22:00:56] #link https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-04-29 [22:01:35] Thanks for coming all [22:01:43] First, an announcement of a few RfCs that need some help [22:01:50] #topic asking for help with a few RfCs [22:02:00] #info Jon Robson needs help writing the initial code for https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templates [22:02:09] jdlrobson - tell me if that's wrong :) [22:02:15] #info https://www.mediawiki.org/wiki/Requests_for_comment/Scoping_site_CSS and https://www.mediawiki.org/wiki/Requests_for_comment/Book_management need new coauthors to move forward [22:02:23] so check those out. [22:02:56] OK, now on to the first topic today, Ryan_Lane's MediaWiki libraries RfC. Then we'll move on to parent5446's RfC on 3rd-party components [22:03:01] #topic MediaWiki libraries [22:03:12] #link https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_libraries Ryan Lane's proposal (better handling and versioning libraries that are MW extensions) [22:03:12] * marktraceur frows at Book Management [22:03:36] #chair sumanah brion andrewbogott TimStarling [22:03:36] Current chairs: TimStarling andrewbogott brion sumanah [22:03:41] So I have a question about this RfC. It mentions LdapAuthentication as an example. What library in LdapAuthentication would we be packaging with core? [22:03:46] #info See https://www.mediawiki.org/wiki/Talk:Requests_for_comment/MediaWiki_libraries - we just need to merge "Add Composer managed libraries" https://gerrit.wikimedia.org/r/#/c/119939/ in order to complete part I of this. [22:03:47] #info Then Part II is actually moving everything else into that directory, and also making it reasonable to move some extensions into that directory. [22:04:05] B/c I understand the RFC in the context of the Gerrit patch [22:04:19] Libraries that are being used in core will need to be managed somehow [22:04:23] parent5446: a number of extension use LDAP as a library [22:04:31] i’m not sure i understand this rfc; is the idea to package specific libraries in mediawiki core? [22:04:40] I'd split the necessary functionality out of the LDAP extension into a common library [22:04:44] or to provide a general place to put libraries? [22:04:48] ...how? Are there extensions that use LDAP other than LdapAuthentication? [22:04:54] I think the idea is to create a separate class of extensions that you put in libs/ instead of extensions/ [22:05:05] TimStarling: yep [22:05:13] first question: why? [22:05:25] second question: what needs to be different other than the filename ‘extensions’ -> ‘libs’? [22:05:36] because there's now a lot of extensions being used as libraries and they aren't being versioned with mediawiki [22:05:40] OK, but the gerrit patch makes it look like we'd be packaging them with core. So it makes it sound like we'd be packaging libraries within core that are not actually used in core. [22:05:45] third question: does that patch adding a libs directory help or hinder this rfc’s recommendations? [22:05:53] (the patchset is by bd808 in case he wants to comment) [22:05:57] most of these could be bundled with core [22:06:11] we have includes/libs already for things that are bundled [22:06:13] and should definitely be versioned with releases [22:06:28] TimStarling: that's for things that core depends on, but not for things extensions may need to depend on [22:06:45] so is this directory’s contents something is fixed, that extensions can depend on always being present? [22:06:55] or is it something extensible, that extensions can rely on having a way to install things there? [22:07:09] I don't really think it's a good idea to package extension libraries as part of core if core is not using it. [22:07:23] The best solution for Ryan's RFC would probably be enabling the full use of Composer (or a similar system) with wm-core [22:07:27] Maybe an extension needs a different library version, and can't use it because core decided to package it [22:07:48] * sumanah invited Jeroen to discuss composer-y stuff with us in this chat but - ah, there's JeroenDeDauw! [22:08:03] Just saw calendar notification now [22:08:07] Anout to head off [22:08:14] so, maybe I should describe my issue, rather than this specific solution? [22:08:18] JeroenDeDauw: http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140429.txt starting at 2200 in case you wanna see our talk till now [22:08:26] s/talk/chatter/ [22:08:29] with composer, I'd like to know whether you think extensions should be in mediawiki/* or mediawiki/extensions/* [22:08:32] Ryan_Lane: yes please :D [22:08:42] in the package names [22:08:44] #info the Composer RfC: https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer [22:08:57] so, we have extensions. those extensions for a long time only had a dependency on a specific mediawiki version [22:09:02] because JeroenDeDauw put a few in mediawiki/*, but it seems a bit weird to me [22:09:14] now we have extensions that only exist as libraries for use by extensions [22:09:14] TimStarling: vendor/package [22:09:18] TimStarling: two levels [22:09:24] (many extensions require external dependencies as well…) [22:09:52] extensions can also be hooks onto other extensions -- but that doesn't make the 'parent' extension a library [22:11:03] * aude waves [22:11:10] hmm [22:11:12] this seems to be mostly an argument about our release process... in theory, everything in a release is stably versioned and has release branches for backports [22:11:43] well, it's more an issue that we have no reasonable way to specify extension compatibility [22:12:00] and now we need to specify extension compatibility with mediawiki and with other library extensions [22:12:02] I mean, this is basically what composer was made to do [22:12:21] Ryan_Lane: don’t you just grab them from the same version branch? [22:12:21] Except people don't want to use composer in core [22:12:34] * sumanah sees parent5446's point. If this is a configuration/dependency management problem, maybe we should go with the thing that does that [22:12:41] brion: very few people use version branches [22:12:52] Ryan_Lane: how would this solve that? [22:12:59] we're cutting the version branches automatically now [22:13:14] mwalker: but everyone else still uses tarballs [22:13:16] my proposal was to have the common libraries shipped with mediawiki and locked with the version [22:13:22] … [22:13:31] so something that’s common to a group of extensions, and has no relation to mediawiki core... [22:13:34] … would be shipped with core? [22:13:38] Shipping common libraries is kind of like a band-aid to the actual problem [22:13:39] I think it's fine to have extensions that depend on other extensions [22:13:49] parent5446: I think we are open to using composer in core, but new need to figure out how to do that in a way that works for JeroenDeDauw's use case and mine (which is basically the same as Ryan_Lane's) [22:14:07] the issue is that most of these library extensions probably should just be core [22:14:09] drupal has a DIY system for this [22:14:18] or of course we could use composer [22:14:25] I thought the main problem was that people didn't like how it didn't interact properly with Git? [22:14:29] if 20 extensions are using an extension, why isn't it a core feature? [22:14:30] Emufarmers: Dantman: would love to have your input here as people who work on non-WMF MediaWiki installations [22:14:33] or support any other package management system, like PEAR or .deb or whatever [22:14:50] Ryan_Lane: are those 20 extensions all specific and only used by a tiny minority of installations? [22:14:54] greg-g, we bundle extensions into our release tarballs... [22:14:55] or are they used all the time by most? [22:15:05] to be fair, I'd be fine with composer, if it can be used reasonably [22:15:23] Well many extensions have already been made to work as composer libraries [22:15:24] if a facility is widely used, I think it can be in core, you know that I am not one of the people who has a narrow view of what core should be [22:15:25] mwalker: yeah. (/me doesn't want to derail, it was a minor point) [22:15:27] it feels like the solution here is “a dependency-managing installation system for extensions" [22:15:38] TimStarling: I'm not saying you are :) [22:15:42] but yes, we need extension dependencies for various reasons [22:15:42] Which means we should check out https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer [22:15:51] and maybe expand it [22:16:04] sumanah: I'm not 100% certain of the topic, or even whether "extensions as composer modules" is included in this or excluded. [22:16:18] not just for libraries -- some extensions hook others, for example [22:16:28] yep [22:16:41] it's something we've been punting on forever [22:16:43] Dantman: sounds like we're talking about including it, maybe [22:16:44] some use RL modules from another extension [22:17:09] Dantman: the topic is https://www.mediawiki.org/wiki/Requests_for_comment/MediaWiki_libraries Ryan Lane's proposal (better handling and versioning libraries that are, or are used by, MW extensions) [22:17:22] so, let's drop this proposal and maybe talk about the composer suggestions? [22:17:43] or is that not how this process works? heh [22:17:53] Well if we need to itemize this to dependencies on individual RL modules and hooks, there's not really any system that handles that [22:18:06] With composer it's either you depend on the entire extension or you don't [22:18:12] Well this idea of extensions as composer modules has annoyed me over and over again. [22:18:14] Unless you separate into further libraries [22:18:15] Ryan_Lane: I'm fine with the process working like that, if you want to abandon your RfC and become a coauthor on the Composer one :) [22:18:53] Extension management with composer would allow managing dependent libraries as well, for the extensions. My use-case of wanting an external library for core is slightly different, but could pervert the system by using a basically empty extension just to get the library management. [22:19:00] andrewbogott: I guess one question for you as Ops representative is how Ops feels about Composer (although I assume if Ryan's fine with it then you would be too) [22:19:02] wasn't that another RfC that was in the queue for today? [22:19:20] Ryan_Lane: no, it wasn't; it is one that I wanted people to have fresh in their memory because I predicted it would interrelate [22:19:24] the current implementation of composer doesn't fit with our deployment process [22:19:31] #topic Extension management with Composer [22:19:38] #link https://www.mediawiki.org/wiki/Requests_for_comment/Extension_management_with_Composer [22:19:45] Yeah, I was going to say: I don't think Ryan_Lane is fine with it :) [22:19:47] but since Markus isn't here and JeroenDeDauw needs to head off, it's suboptimal. Ah well [22:20:22] composer, as currently implemented, means you need to run composer on every node you deploy to. it also makes it impossible to disable any individual extension [22:20:30] I don't think there's any reason to use composer in production [22:20:38] Ryan_Lane: no [22:20:44] you make a build [22:20:57] with all the stuff installed [22:20:59] run tests on it [22:21:00] The ops concerns can be dealt with for the WMF cluster using a technique like I used in the Scholarships app (which uses Composer and is live on the cluster). [22:21:05] then deploy that [22:21:14] all the stuff checked in, including composer.lock [22:21:17] what about other people using similar deployment methods? [22:22:06] what aude has described is basically how we're having to deploy Node.JS apps [22:22:08] it's also possible to have an internal satis (packagist) system [22:22:24] The technique in patch https://gerrit.wikimedia.org/r/#/c/119939/ is very similar to what Scholarships does to freeze the external libs. [22:22:24] that only knows about our own stuff [22:22:26] I'd rather not have any kind of external dependency for source in production -- just our own git servers [22:22:33] so, does this assume that all WMF extensions will also have composer data? [22:22:48] can composer use private repos? [22:22:50] the wikidata thing is to run composer locally and then push the result into git, right? [22:22:51] probably our own satis + a build would work [22:22:53] brion: yes [22:22:57] Technically it should be trivial to convert most extensions to a composer library [22:22:59] yes looks like good [22:23:00] :D [22:23:14] TimStarling: yes [22:23:28] so what does it look like to composer-ize an extension? what sort of migration path would we be looking at? [22:23:38] including it's important to carefully check composer lock and the diff [22:23:40] and would this just handle fetching files, or would it also handle installation, enabling, etc? [22:23:45] You make a composer.json file that tells composer to include the main extension file [22:23:47] brion, http://www.bn2vs.com/blog/2013/11/24/introduction-to-composer-for-mediawiki-developers/ [22:23:54] plus all our tests run and then only after they pass, it gets merged [22:23:59] composer fetches files and handles class autoloading [22:23:59] thanks [22:24:02] #link http://www.bn2vs.com/blog/2013/11/24/introduction-to-composer-for-mediawiki-developers/ [22:24:36] it has its own autoload system, and does clever things like scanning .php files on install for class definitions [22:24:41] some of a problem will be when some other extension wants to use same library that wikidata uses [22:24:58] in addition to PSR-0 of course [22:25:01] would be nice to have it registered in a shared place [22:25:01] related question: [22:25:12] obviously small installations would love an extension installation manager. [22:25:23] would tying to composer force us to require CLI for extension setup? [22:25:37] or would it allow for a web control panel as well, given appropriate permissions on server? [22:25:42] ok, it sounds like there is a lot of interest in Composer usage. Ryan_Lane does this interest you enough to make you wanna collaborate on investigating things after today, working on the RfC with Markus Glaser or whoever else wants to work on this? JeroenDeDauw maybe? [22:25:43] TimStarling: we also use composer option to dump a classmap (helps optimize) [22:25:54] because we're not gonna figure all this out and approve it today [22:25:57] so in the end it is like AutoLoader.php [22:25:58] we can support any number of pacakge management systems in parallel [22:26:01] brion: Yes, unless we make a PHP interface for composer, which we can [22:26:13] parent5446: that works for me [22:26:13] we don't need to support composer exclusively [22:26:20] ^that as well [22:26:26] hmmmmmmmmmmm [22:26:30] i hate mixing package managers though [22:26:38] +1 to brion [22:26:40] brion: a php interface would be cool, but not aware of one [22:26:46] as long as we document dependencies as well as putting them in composer.json, people can keep on installing things the old way [22:26:50] sumanah: I can't really spend time on this. I need this as a user of mediawiki, though [22:26:50] I also have doubts about being able to do a web interface around composer. [22:26:50] probably would be fairly simple [22:27:00] Especially a secure one. [22:27:00] Ryan_Lane: totally fair - just wanted to check [22:27:27] Dantman: secure is the hard part. wordpress updates for instance seem to jump through weird hoops to ssh into itself or some weird shit :D [22:27:32] it scares me [22:27:38] but is an oh-so-useful feature [22:28:04] it's a bit more secure than just using the web user for installation [22:28:25] chmod 777 [22:28:26] at least after installation, the source tree is not writable by the webserver [22:28:31] yeah :D [22:28:35] Wordpress also allows using FTP to update [22:28:39] Most of the important metadata is still in PHP. So you can't read it without first fetching and installing the extension. [22:28:41] *shudder* [22:28:45] Google found https://github.com/derrabus/composer-webui for me [22:29:36] Looking at the code for what bd808 just posted, you can basically just include composer itself, and use it's internal interface [22:29:36] hexmode: you talk to Markus a lot, I assume :-) Do you know whether Markus has time to respond to any of these points soon? [22:29:43] (since he proposed Composer-y stuff) [22:30:11] It's also a dead end if you can't do shell execution from php. (Don't we still sort of support that?) [22:30:12] sounds like we’ve got a lot of questions and ideas to queue up for that :D [22:30:30] brion: help me summarize for the notes? [22:30:36] Side note on composer itself. [22:30:44] You wouldn't need shell access to use composer from PHP [22:31:00] Hmmm... right. [22:31:33] #info The ops concerns can be dealt with for the WMF cluster using a technique like I used in the Scholarships app (which uses Composer and is live on the cluster). The technique in patch https://gerrit.wikimedia.org/r/#/c/119939/ is very similar to what Scholarships does to freeze the external libs. [22:31:44] Composer is similar to other package managers that install things locally. [22:31:49] #info Technically it should be trivial to convert most extensions to a composer library [22:31:52] Like npm and bower. [22:32:37] However it's unique (in a flawed way) at being the only one that requires that every installed package be present inside the .json file. [22:32:47] #info Wikidata team has some Composer experience per aude's explanation [22:33:32] Both bower and npm can install packages locally without adding them to the .json file you commit. (If you want to add it you use --save) [22:33:37] how would registration be handled? [22:33:38] #info discussion of whether to deal with multiple packaging systems or just one, use something like https://github.com/derrabus/composer-webui for a web UI, CLI vs web (doing web UI securely is ?) [22:33:45] You can add arbitrary libraries using Composer at the command line, but it writes them into the lock file [22:34:05] [15:28:39] Most of the important metadata is still in PHP. So you can't read it without first fetching and installing the extension. <-- Yeah, I was thinking about that as well. I had an idea that we could just put all the extension registration stuff (hooks, classes, basically [[mw:User:Legoktm/extension_registration]]) into a JSON file, so anything can read it without actually installing the extension [22:34:21] Which is very similar to using a require.txt file with pip in python or ruby's bundler [22:35:14] would composer installation somehow register the extension? or would registration require a line to be added manually to LocalSettings.php? [22:35:32] TimStarling: can be done wither way [22:35:59] i prefer manually registration for prodution [22:36:00] that may be a question for discussion on the RFC page then [22:36:20] TimStarling: If you set the autoloader to include the main file, it would not need lines added to LocalSettings [22:36:25] so we can enable something for one wiki but not an other (e.g.) [22:36:35] My point is, if it weren't for that flaw in composer. It would have never been necessary to delete the composer.json that we used to have in core. [22:36:36] like we do w/o composer [22:36:45] A composer extension can register several customization scripts to hooks -- https://getcomposer.org/doc/articles/scripts.md [22:37:11] #idea question for composer-for-extensions: best way to fit in with our source-control-based deployment? [22:37:12] #idea question for composer-for-extensions: web ui possible for small installations? (compare with wordpress’s installer & extension manager) avoid chmod 777 [22:37:12] i hope i’m using the right magic tags [22:37:12] #idea question for composer-for-extensions: avoid proliferation of package managers, but make sure we can still install extensions manually if need be or for migrations [22:37:12] brb [22:37:38] brion: yeah, you are :-) https://wiki.debian.org/MeetBot #idea works [22:37:46] ok ... [22:37:53] did we get the key points? [22:38:04] also #info #action #help #link [22:38:11] maybe we should have our own admin console for registration [22:38:21] whoa colloquy just dropped the last 5 minutes on me in a batch :D [22:38:38] and it would detect extensions installed by composer for the purposes of displaying the list [22:38:53] Dantman: Part of the problem is that core is both a library and an application. Composer doesn't grok that. [22:38:55] that way you can disable them, but it is still easy to use [22:38:57] TimStarling: i like that [22:39:08] composer for physical installation, but we have a separate activation as we do now [22:39:19] this works well for multi-site farms as well as for shipping defaults etc [22:40:36] you could pull the list of enabled extensions out of the DB or some other web-writable place [22:40:46] * sumanah invited folks from Wikia, ShoutWiki, & wikiHow to come talk about this; will try to get them to talk on the talkpage [22:40:59] #info A composer extension can register several customization scripts to hooks -- https://getcomposer.org/doc/articles/scripts.md [22:41:02] iterate, invoke some autoloaded static function for registration [22:42:16] #action sumanah to get input from Wikia, ShoutWiki, wikiHow, & other 3rd-party folks on the Composer RfC talk page [22:42:21] so, i guess... with wikidata, we disabled autoloading of wikibase client and repo by default [22:42:40] those are then loaded via CommonSettings based on config [22:42:54] should we talk about parent5446' [22:42:55] once one of those is loaded, all the dependencies are autoloaded [22:43:00] should we talk about parent5446's RFC now? [22:43:01] #action sumanah to bring this spirited discussion to the attention of Markus and ask him if he can move forward, incorporate suggestions, maybe talk to aude from Wikidata & bd808 for specific HOWTO recommendations to incorporate [22:43:06] I think so TimStarling [22:43:10] #topic MediaWiki libraries [22:43:16] #topic Third-party components [22:43:20] #link https://www.mediawiki.org/wiki/Requests_for_comment/Third-party_components [22:43:26] #info Tyler Romeo's proposal (replacing some MW components with more widely used libraries, especially Symfony libraries) [22:43:39] it would be cumbersome to manually register all the dependencies of wikibase [22:43:41] #info parent5446 is looking for feedback on the general concept. [22:43:46] which requires a package manager :) [22:44:17] I don't see any one replacement jumping out at me yet as "oh yes, let's do that replacement right now" [22:44:19] Hence the advantage of discussing these two RFCs together [22:44:24] bd808: yep [22:44:41] but I like the idea. As parent5446 says: "other open source projects have created entire libraries that do the same thing as the MediaWiki components, except are better maintained and much more functional. This RFC aims to replace one or more MediaWiki components with third-party open source components." [22:44:50] *nod* [22:45:01] I don't think I am in favour of this general direction [22:45:02] this seems like something that’ll be easier to treat once we have a consistent dependency manager :D [22:45:06] hmm [22:45:26] I like the idea of using a full mail library. But I don't like the replacement of WebRequest. [22:45:29] when we maintain our own small libraries, we can make changes to them [22:45:42] the more we use external libraries, the more we will be blocked waiting for upstream [22:46:04] with our own code, we maintain some flexibility [22:46:26] for complicated things like JS minification, sure, use an external library [22:46:26] we can maintain local patches but that way lies madness [22:46:35] but I don't think it makes sense for simple things like curl wrappers [22:46:42] How are those other (external) libs hosted? Would managing them drastically increase the scope of what composer has to do? [22:46:48] the more we use external libraries; the more we'll start running into libraries that pull in other libraries (which at worst are not compatible and at best are redundant) [22:47:16] isn't this chain of logic the way to wheel reinvention hell? [22:47:31] I wouldn't use the extreme as the norm [22:47:40] wheel not reinvented here :) [22:47:41] Not all libraries are dependency hell or hard to get things fixed upstream [22:47:57] maybe one way to balance this is to actually do the kind of inventory that parent5446 has done every so often, and check ourselves [22:48:03] I don't really believe in that phrase [22:48:19] I think there's a difference between making a wheel and inventing a wheel [22:48:38] having studied many wheels, a good engineer can make a wheel for a specific purpose without much difficulty [22:48:40] Making a custom mail library when SwiftMailer already exists in re-inventing the wheel [22:48:50] the same is true of libraries [22:49:04] Is there a general-case question implied by that RFC? Or is it just a question of considering each possible replacement case-by-case? [22:49:11] I agree with parent5446 that there are good externals and bad. We should only use the good ones. :) [22:49:23] * andrewbogott doesn't know if relying on any one external library already involves overhead that isn't done yet [22:49:27] "don't reinvent the wheel", taken literally, encourages study, not recycling [22:50:00] as parent5446 says on the talkpage, "This RFC is not advocating replacing all of MediaWiki with third-party components; it's just an attempt to consider the possibilities and see what might be worth replacing." [22:50:40] do we have anyone here who has maintained jQuery in core? I feel it is a good case study [22:50:47] so it sounds like one principle is: the more complicated the kind of thing we're trying to do, the more likely it is we ought to check what external libraries are available [22:51:01] I think I could have gotten my implementation for the Structured logging RFC merged already if I had just written my own logging library, but I'd rather not. [22:52:13] we can discuss individual proposals on their merits, of course [22:52:57] but parent5446 is asking for general thoughts, and so this is my position, pretty much at the other end of the spectrum as far as opinions on reuse go [22:53:40] parent5446: the individual proposals I presume are most congruent with the "replace complicated things" principle would be around config and maintenance/console. What's your assessment? [22:54:03] I have read a lot of code, and most of it was worse than what we have in the MW core [22:54:08] and subject to less review [22:54:19] ^ the review this is important for fundraising [22:54:21] (other principles that are probably pretty obvious: the replacements should be high quality code, friendly & responsive upstreams, etc. HHVM would be an example?) [22:54:47] Yeah I haven't really looked at code, so I can't make a statement on specific libraries [22:54:59] (not a replacement really, but us choosing to work with an existing project instead of going it alone) [22:56:07] #link https://www.mediawiki.org/wiki/Upstream_projects [22:56:11] part of the issue with the way we do things now is that, while being potentially superior along many vectors (performance, reliabilitiy, security), we seem to fall down on reusability, which is unfortunate [22:56:49] The larger PHP community has made great strides in code quality in the last 4-5 years. There is still a lot of nasty stuff out there, but in the PHP 5.4+ library space there are a lot of high quality components. [22:57:11] I got to head out. Sorry for leaving a bit early on my own RFC. [22:57:25] It's ok parent5446 [22:57:31] * sumanah decides to sum up [22:57:36] #info this seems like something that�ll be easier to treat once we have a consistent dependency manager :D [22:57:51] i also agree with bd808, while there is alot of crap php out there, there is also a ton of clean, modular code with minimal or no dependencies [22:58:02] and that has all happened in only the last couple years [22:58:10] +1 [22:58:33] monolog being good example [22:58:41] #info we feel mixed about the general concept of choosing to reuse external stuff instead of writing it ourselves - depends on code quality, which you gotta take on a case-by-case basis [22:59:00] #info part of the issue with the way we do things now is that, while being potentially superior along many vectors (performance, reliabilitiy, security), we seem to fall down on reusability, which is unfortunate [22:59:42] Most of the Symphony2 code I've read is solid. There's some "javification" in parts but in general that happens when you build flexible libraries. [22:59:52] #info also, we're more likely to be interested in a replacement if the feature is quite complicated, e.g., JS minification [23:00:16] #info examples of good PHP code out there that's reusable: monolog, Symfony2 stuff [23:00:47] All right, I think that's about it today - next week we have no IRC meeting, because of the Zurich hackathon [23:01:00] where we'll talk about performance guidelines and, I hope, thumbnails [23:01:00] yay, hackathon! [23:01:09] Thank you all [23:01:19] woo! [23:01:22] I really appreciate your consistent thoughtfulness [23:01:25] #endmeeting [23:01:25] Meeting ended Tue Apr 29 23:01:25 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:01:25] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-29-22.00.html [23:01:25] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-29-22.00.txt [23:01:25] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-29-22.00.wiki [23:01:26] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2014/wikimedia-office.2014-04-29-22.00.log.html