[00:38:21] http://toolserver.org/~robla/crstats/crstats.trunkall.html [00:38:31] # select only FIXMEs [00:38:56] # amazing drop off [09:10:43] morning TrevorParscal [09:11:03] so happy to see me :D [09:11:11] :-D [11:02:29] Reedy: http://etherpad.wikimedia.org/118deployment-scrum [11:02:45] I don't really have anything to report as I'm not really working on 1.18 today [11:02:47] was already in it ;) [11:03:02] Oh I just looked and thought it was empty [11:03:12] Yeah, I don't think Chrome had reconnected [11:03:24] It worries me a bit that the rev report numbers are unchanged from two meetings ago [11:03:34] Hopefully hexmode 's fixme triage will set things in motion [11:03:39] There's more stuff being marked [11:03:43] (If only it weren't held at friggin' 1:30am) [11:03:59] If you flick through the diffs, there does seem to be some churn happening [11:04:11] http://www.mediawiki.org/w/index.php?title=MediaWiki_roadmap%2F1.18%2FRevision_report&action=historysubmit&diff=433032&oldid=432924 [11:04:31] Right [11:04:39] Old stuff falls off, new stuff added at the same rate [11:05:03] We could probably just mark the math stuff ok and be -7 :p [11:05:06] hehe [11:05:20] Well mostly though the old things are hairy revs and the new things are easy followups to those [11:05:31] Brion does look to have being doing some CR on them aswell, so it is progress [11:05:35] Prototypical example is https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/96643 [11:05:35] I triaged the scaptraps [11:05:40] Ah cool [11:05:44] And schema changes too, I saw [11:05:56] Yeah, not finished [11:06:08] Need to go through the extensions, but there is likely not a lot [11:06:27] Most of the regular changes are features things, which have been deployed to a trunk-ish state [11:06:53] Yeah [11:10:22] uhhuh [11:16:30] Yay for having a whiteboard [12:02:30] Do we revert http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84395 out of 1.18? [12:02:40] If needed it can be merged into 1.18wmf1 as a stopgap [12:03:41] Sounds reasonable [12:05:47] Or do I revert it in trunk also? [12:06:45] seems cleaner [12:07:54] That seems sort of evil [12:08:02] To have the code only exist in 1.18wmf1 and not in trunk [12:08:50] Yeah, it works as a short term "fix" if Michael actually needs it... [12:09:11] uuuh, is this even relevant anymore: https://bugzilla.wikimedia.org/show_bug.cgi?id=19897&list_id=26110 ? [12:09:20] I think those messages are no longer existing [12:43:02] So we need to deal with at least 1 more fixme today to keep on track [12:55:31] *RoanKattouw looks at the list [12:55:50] I think 80116 is no longer fixme [12:55:53] I commented on it [12:56:26] Needs Brion to confirm that that's fixed now [12:56:48] 88053 is something Timo is working on I think [12:57:04] 74966 is also blocking on his review [12:57:38] 87992 just needs the devs to reach consensus [12:58:39] hah, 91561 says "I'm not really attached to this revision, and wouldn't object to it being reverted on the basis of it being a bad idea (if you think doing this is a bad idea that is). " [13:00:04] Hmm, 86072 is tagged revert-1.18 [13:00:38] Ooh that's that parser bug [18:01:32] robla: Grah, SIP is broken on my laptop, can't call in [18:01:42] Well I could but not with sound [18:01:56] I'm running a couple min late myself [18:12:33] robla: Version checker script? [18:12:50] RoanKattouw: we'll talk more in a bit [18:12:59] OK [18:20:26] RoanKattouw: the version checker script is something that maplebed and AaronSchulz_ cooked up yesterday.... [18:20:55] it's basically a script to check the version of files after they've been synced/scap'd/whatever [18:22:03] Aah [18:22:07] To ensure consistency [18:22:09] Nice [18:22:13] (I gather the meeting is over now?) [18:22:23] RoanKattouw: yup [18:23:15] AaronSchulz_ and I are still chatting a bit [18:23:34] he's going to scope out how big it is [18:23:47] [ ] [18:23:49] ^ this big [18:24:07] thanks Reedy [18:24:11] np [18:24:13] [x] done [18:24:14] Reedy: that depends on dpi [18:24:57] Hmm [19:35:00] in MW, what does using $wgAutoloadClasses give you that just doing a require_once() doesn't? [19:36:11] <^demon> Sanity? [19:36:40] <^demon> Makes sure your class is available in all codepaths, not just the one you require() it in. [19:37:33] how does $wgAutloadClases['clas name'] = 'path/to/class'; give you any more sanity than require_once( '/path/to/class' ); ? [19:39:43] <^demon> Autoloader will automagically prefix with $IP, if it isn't already. [19:39:50] oh fancy [19:40:00] but so if you explicitly define the full path [19:40:01] <^demon> Which fixes 2 problems....the first is people assuming that . is in include_path, which it might not be. [19:40:13] <^demon> Secondly, saves on stat calls. [19:40:15] yeah [19:40:19] makes sense [19:40:24] cool thanks :) [19:40:44] <^demon> No problem :) [19:41:25] <^demon> Also, if you have two classes that depend on one another (A extends B), it'll handle the magic loading of A.php && B.php if you use the child. [19:41:40] <^demon> Vs. manual require()s, you have to make sure all the classes are loaded. [19:42:38] <^demon> To paraphrase what Tim said some time ago, the autoloader is pretty dummy proof. You're less likely to make (admittedly accidental) mistakes :) [19:49:17] apergos: ping [19:52:14] apergos: ZOMG! I don't suppose that you're away from your keyboard late on a Friday night, are you?? Well, enjoy yourself if you are. [20:24:21] no, just feeling crappy, was resting [20:25:17] and shall be resting again shortly [20:25:19] have a nice day