[00:00:21] At least, it wasn't a FOAF! That's even /less/ credible. :-) [00:00:26] supporting porn sites is not really high on my list of priorities [00:01:07] MW is partly software and partly a vehicle for spreading a philosophy of openness [00:01:25] * AaronSchulz holds back inappropriate remarks [00:01:27] That's why it supports complete read restrictions. [00:01:48] * saper checks ... copyleftporn.org is still available [00:02:14] sure, but not fine-grained read restrictions, it's all or nothing [00:02:41] so it encourages larger groups where everyone can see what everyone else is doing [00:02:42] TimStarling: I prefer to make no judgment on what people choose to host, or what they find valuable. :-) In that case, moving to the more-open wiki was desirable, criminal liability less so. I had no objection to helping one and preventing the other. [00:03:53] TimStarling: As a sysadmin, I'm amoral. I push, hint, and coax people into open source, open contents; but my job is to give them the tools to do what /they/ want (though I would just choose to not help someone who strayed too far from my own compass) [00:04:29] That isn't what amoral means. [00:05:01] Joan: Not strictly. I mean in the more colloquail, "morally neutral" sense. [00:05:04] no, it sounds like you're being quite moral in hinting and coaxing [00:05:21] And quite moral in steering clear of what you find objectionable. [00:05:24] colloquial. I wonder if colloquails are small tasty birds? [00:05:28] You could just say you're more open and liberal than others. [00:05:44] Okay, that's a good point. [00:05:48] =) [00:05:51] Domas! [00:06:05] whatsup! [00:06:09] maybe we need a #mediawiki-philosophy channel [00:06:41] Regardless, I'm guessing there was a point about my fugly hack? :-) [00:06:48] I reckon I could do a better job of gerrit's code review interface in about a week in PHP [00:07:06] i.e. less time than it took various MW people to write the CodeReview interface [00:07:08] phabricator is so much better! [00:07:25] and yes, codereview wasn't bad either :) [00:07:29] hey, brion was one of those people [00:08:02] Isn't gerrit open source? [00:08:12] Why doesn't Wikimedia just hijack it and make it not suck? [00:08:12] Oh, hey, is there a reason bug 5445 was never done? That looks like something that would be valuable to solve. [00:08:16] Java. [00:08:28] Well, presumably you were aware it was in Java before choosing it. [00:08:29] Joan: Making java not suck? Tall order! [00:08:30] I'm not sure why that matters. [00:08:50] apparently the JS is generated from Java too [00:08:57] yeah, we'd have more hope of hijacking phabricator, if it wasn't good enough already [00:09:59] 03ning * 10/trunk/extensions/WikiObjectModel/includes/models/WOM_OM_NestProperty.php: apply caption to WOM nest property [00:10:08] Coren: I thought the point regarding your hcak weas that it was antithetical to MediaWiki's objectives and philosophy. [00:10:14] your hack was [00:10:26] is there a big public phabricator instance somewhere? [00:11:12] https://secure.phabricator.com/D192 Username/password: demo/demo [00:11:18] How big is big? https://secure.phabricator.com/ for phabricator [00:11:40] I figured by the username and password box that it wasn't public [00:12:45] Joan: I don't believe that's true. It's certainly at odds with /WikiMedia's/ objectives and philosophy, but the software is just a tool. A restricted wiki, even on the stringent side (which that hack was), is better than a closed CMS with no history, no export. [00:13:07] Are there CMSes with no history? [00:13:30] Joan: Plenty, with no publically accessible history (that's what I meant) [00:13:36] that demo account seems to give you access to a single change [00:13:45] so that's not what I meant by big [00:13:47] Damn my ESL. I'm not even sure I wrote that right. [00:14:23] TimStarling: ask domas for his facebook login details [00:14:23] https://secure.phabricator.com/diffusion/ARC/ [00:14:34] I think those are repos. [00:14:40] Did you login at /D140 or at /? [00:14:50] I see a bunch of commits at /diffusion/ARC/ [00:15:11] https://secure.phabricator.com/diffusion/ is the list of repos. [00:15:20] D192 * [00:15:44] Oh, eew! I need to clean my desk up. I just took a swig of yesterday's coffee. [00:15:53] 1,806 commits to phabricator. [00:15:58] Surely that's big enough. [00:16:54] Okay, so don't click the large rainbow at the top of the window. [00:17:17] What's wrong with nyan cat? [00:18:17] It's against God. [00:18:40] Joan: After all, not everyone uses mediawiki for the same things; I support and participate to free culture, but other uses are no less legitimate for being focused on other things. [00:18:51] is there a reason why it has to fill in the browse repository table with so many slow uncacheable XHR POST requests? [00:19:06] domas: report.py (and you) got a shout-out at https://blog.wikimedia.org/2012/03/15/measuring-site-performance-at-the-wikimedia-foundation/ [00:19:09] Not sure if you saw. [00:19:19] saw that [00:19:26] You're e-famous! [00:19:27] anyway yes it's better than gerrit [00:19:29] I'm not a big believer in measurement [00:19:43] it actually has a working diff feature [00:19:43] I'm a big believer in acting upon measurementsĄ [00:19:44] :) [00:19:55] Heh. [00:19:58] Joan: Like, right now, I'm working on a wiki for play-by-post roleplaying and collective campaing world building (hence, funnily enough, the dice rolling extension). It it produce free culture, but the organization will still be more restrictive than a "pure" wiki. [00:20:18] TimStarling: you know enough to know that it's better than gerrit already? [00:20:27] Coren: Philosophically MediaWiki has opposed granularized read restrictions. [00:20:39] yes [00:20:47] I mean there are two basic features you need in a code review tool [00:20:50] 1. viewing diffs [00:20:53] 2. leaving comments [00:21:01] gerrit does both incredibly poorly, so it's not a high bar [00:21:06] I'm not sure why CodeReview was abandoned. [00:22:06] <^demon> It would've been great to get all of this feedback regarding Git some time ago when I was pushing repos and asking people to play with them. [00:22:22] Joan: I know. I've never quite understood or agreed with that stance; certainly those are laudable (and, indeed, critical) components of what the Foundation needs and wants; and I'd agree 100% to the idea that not a cent should be spent to work on those things from them (in monies or time) [00:22:22] <^demon> Rather than waiting until day zero to start touching it and then going "no fair, it sucks" [00:22:30] does $wgInputEncoding still work when set to UTF-8... what is better [00:23:01] Coren: I'm sure Wikimedia wikis would benefit for better read restrictions. [00:23:05] And better restrictions in general. [00:23:10] Joan: I just never made the leap to "the software should not support it at all". [00:23:24] Tim agrees with you there. [00:23:30] I think. [00:23:34] coren: software supports that [00:23:45] Joan: That's a different debate entirely. :-) Remember, I was on the enwp ArbCom for five long, long years. I saw the worst of it. :-) [00:23:46] you're just supposed to configure that somehow [00:23:52] or use an extension [00:23:53] or whatnot [00:24:00] Coren: Oh? You're a Wikipedian? [00:24:10] Joan: With that username even. [00:24:16] I had no idea. [00:24:20] <^demon> I ran for enwiki arbcom a long time ago. Man oh man I'm glad that never actually happened :) [00:24:30] ^demon: You have no idea. :-) [00:24:39] does $wgInputEncoding still work when set to UTF-8... what is better [00:24:43] domas: Most of the extensions aren't very secure. [00:25:00] !wg InputEncoding [00:25:01] https://www.mediawiki.org/wiki/Manual:$wgInputEncoding [00:25:05] ^demon: well, if we're invested in gerrit, we can probably fix the most obvious problems [00:25:05] Must. resist temptation to write a 'central navigation' standard [00:25:18] Guest92901: I'm not sure why you'd fiddle with that setting (ever). [00:25:23] gerrit needs monobook scheme [00:25:23] It looks like it was even removed from MediaWiki. [00:25:31] didn't you see, openstack people did some work [00:25:41] domas: CSS, classes and IDs are autogenerated [00:25:59] eclipse managed to theme gerrit, but I suppose they are java developers [00:26:08] every other instance I've looked at looks identical [00:26:09] If they couldn't.. [00:26:18] <^demon> Roan and Timo have some basic skinning work in progress. [00:26:19] Joan: But, say, Aaron's extension - IMO - *should* be configurable to prevent reading unflagged revision if that's what the site admin wants/needs. I would also fight very, very hard against that feature being turned on on enwp. (Though /for/ FR in general) [00:26:21] <^demon> So that's doable. [00:26:21] You could change the default CSS. [00:26:27] timstarling: https://review.openstack.org/#q,status:open,n,z ;-) [00:26:31] Oh, the CSS is autogenerated too? [00:26:37] ;) Yes [00:26:39] Coren: no it shouldn't [00:27:06] I have some hook hack code in an FR subpage on mw.org for that [00:27:14] but it's best left out of the code [00:27:17] 03(NEW) LQT comments are not displayed after editing them - 10https://bugzilla.wikimedia.org/35547 normal; MediaWiki extensions: LiquidThreads; (mybugs.mail) [00:27:26] It kind of depends how well it works, doesn't it? [00:27:31] AaronSchulz: Okay, I'll bite. Why? [00:27:33] It sounds hackish and easy to bypass. [00:27:44] So you don't want to give end-users a sense of false security. [00:28:03] anyway I'm not much of an aesthete [00:28:21] it's not the lack of rounded corners or the shade of green that bothers me [00:28:28] New review: Robmoen; "At first glance, wgCentralPagePath looked funny being initialized as false." [mediawiki/extensions/CentralNotice] (master) C: 1; - https://gerrit.wikimedia.org/r/3717 [00:28:38] <^demon> TimStarling: Release notes for upcoming 2.3 release https://gerrit-review.googlesource.com/#/c/33220/9/ReleaseNotes/ReleaseNotes-2.3.txt [00:28:40] it's the lack of a complete unified diff shown on one page [00:28:52] and the inability to generate a diff between changesets [00:28:56] It looks like the gerrit_body class is fairly standard. [00:29:24] btw I did one today using rebase [00:29:31] <^demon> The "diff on merge" issue is definitely on their radar and is being worked on (as of a couple of weeks ago). [00:29:48] <^demon> "Having one unified diff inline" was submitted by Roan and will probably need some prodding to get fixed. [00:29:59] basically you fetch all changesets into their own branches and then rebase each branch in turn to some fixed point (I used master) [00:30:09] then you can do diffs between them [00:30:22] the process could be automated, I will probably at least write a script [00:30:32] is mediawiki using gerrit already? [00:30:37] yes [00:30:39] did the git switch happen? [00:30:41] oh noes [00:30:47] yes, you missed it [00:30:47] https://gerrit.wikimedia.org/ [00:31:24] domas: ;) And we already have release branches where the svn versions have bugs that were fixed in git [00:31:25] domas: it's ok, you can still live hack the site using svn [00:31:39] So it looks like openstack just inserts a