[00:01:24] <saper>	 To ssh://saper@gerrit.wikimedia.org:29418/test/mediawiki/extensions/examples ! [remote rejected] master -> master (prohibited by Gerrit)
[00:01:48] <saper>	 it's not ssh key related, ssh -v "saper@gerrit.wikimedia.org -p 29418" works
[00:02:04] <saper>	 (er "ssh -v saper@gerrit.wikimedia.org -p 29418")
[00:03:57] <sumanah>	 hi saper - just wanted to thank you for your work
[00:04:05] * sumanah  returns to lurking

[00:04:29] <RoanKattouw_away>	 I think that's because Chad locked that repo?
[00:04:39] <robla>	 yo
[00:04:43] <RoanKattouw_away>	 Or maybe you don't have the required permissions in Gerrit
[00:05:57] <robla>	 bsitu: 20% day tomorrw, right?
[00:05:59] <Krinkle>	 saper: Are you trying to push to the repo directly or using git review  ?
[00:06:31] <RoanKattouw_away>	 Oh, yes
[00:06:33] <RoanKattouw_away>	 That's what he's doing
[00:06:47] <RoanKattouw_away>	 A direct git push doesn't work
[00:07:40] <bsitu>	 robla: yes
[00:07:54] <robla>	 TimStarling: is there anything you think bsitu and kaldari should focus on for their 20% day tomorrow?
[00:08:10] <robla>	 hexmode: what looks like the most severe issues?
[00:08:21] <robla>	 *look
[00:08:26] <kaldari>	 apparently RefToolbar is broken on the Spanish Wikipedia, so I'm going to take a look at that
[00:08:43] <kaldari>	 due to 1.19
[00:08:50] <kaldari>	 although it's working on en.wiki now
[00:09:07] <robla>	 there's a few IE7 bugs which we should probably get knocked out
[00:09:19] <kaldari>	 I can look at those
[00:09:29] <kaldari>	 any bug #s in particular?
[00:09:35] * robla  looks

[00:10:01] <Krinkle>	 AaronSchulz: found it!
[00:10:03] <chrismcmahon>	 34822, 34823, 34825
[00:10:15] <chrismcmahon>	 kaldari: ^^
[00:10:33] <robla>	 I'm bumping 34822 down to "high" (was highest)
[00:10:38] <robla>	 !b 34822
[00:10:39] <mw-bot>	 https://bugzilla.wikimedia.org/show_bug.cgi?id=34822
[00:11:08] <robla>	 we still should look into this, but I think it's quite possibly site code/template problem
[00:11:10] <kaldari>	 weird
[00:11:38] <chrismcmahon>	 I repro'd all of those today, just to be sure they weren't flukes
[00:11:49] <robla>	 chrismcmahon: 34822 refers to the search box in the middle of the page, correct?  not the top right search box?
[00:12:29] <chrismcmahon>	 robla: yes, searching in the box under "Wikipedia Help"
[00:12:57] <kaldari>	 that's bizarre. It's just a regular text input
[00:13:12] <kaldari>	 if that's broken, I imagine others would be as well
[00:14:10] <robla>	 kaldari: examples of where chrismcmahon might possibly test?
[00:14:11] <chrismcmahon>	 kaldari: could be.  I haven't done any kind of exhaustive check in IE7
[00:15:09] <bsitu>	 robla, which one do you want me to work on?
[00:15:22] <robla>	 chrismcmahon: could you test on http://meta.wikimedia.org/wiki/Help:Help  ?
[00:15:35] <chrismcmahon>	 robla: looking
[00:15:57] <sumanah>	 hi bsitu
[00:16:06] <bsitu>	 hello sumanah
[00:16:29] * robla  looks at the list for stuff for bsitu

[00:16:50] <chrismcmahon>	 robla: IE7 can type in meta Help, but it is a completely different page than on enwiki
[00:17:23] <robla>	 chrismcmahon: true, but I think that confirms that it's not purely inputbox at play
[00:17:37] <chrismcmahon>	 true. checking one other thing on meta
[00:19:17] <chrismcmahon>	 seems specific to how Help:Contents is manifested on enwiki
[00:19:55] <kaldari>	 Yeah, I think it has something to do with the layout of the elements. The input actually works, but the browser is confused about where it's located.
[00:20:24] <sumanah>	 bsitu: you could review patches, but I bet robla wants to find SVN backlog code for you to review.
[00:22:19] * robla  is still searching the bug list...it's a little harder to look through now that everything is off the 1.19deploy milestone

[00:23:14] <robla>	 aha!
[00:23:15] <robla>	 https://bugzilla.wikimedia.org/show_bug.cgi?id=34781
[00:23:28] <robla>	 bsitu: ^ this one
[00:23:44] <bsitu>	 okay, :)
[00:23:44] <robla>	 RoanKattouw_away can provide guidance on this
[00:24:22] <RoanKattouw_away>	 Looking
[00:24:29] <RoanKattouw>	 Oh that one
[00:25:10] <RoanKattouw>	 robla: You want bsitu to fix that? Should I go over to his desk and explain the situation?
[00:26:10] <robla>	 RoanKattouw: yeah, he won't start on it until tomorrow, but I'm assuming that's probably a good thing to get knocked off on a 20% day
[00:26:14] <bsitu>	 RoanKattouw, my 20% time  is tomorrow, do you have time to discuss it tomorrow
[00:27:01] <robla>	 RoanKattouw: if you think it's more involved than that, let me know
[00:28:08] <RoanKattouw>	 Sure
[00:28:11] <RoanKattouw>	 That sounds fine
[00:28:21] <RoanKattouw>	 Well -- I do have to go to the consulate in the morning
[00:28:33] <RoanKattouw>	 When are you coming into the office tomorrow, bsitu ?
[00:29:01] <AaronSchulz>	 Krinkle: nice
[00:29:19] <robla>	 RoanKattouw: bsitu: oh...yeah, just in case, you should probably talk sometime today
[00:29:57] <RoanKattouw>	 My appointment isn't until 9:30, but I don't know what time bsitu usually comes in
[00:30:09] * AaronSchulz  sifts through Html:: attribute escaping

[00:30:19] <bsitu>	 RoanKattouw, we can chat a little today
[00:35:47] <saper>	 chrismcmahon: solved, it was HEAD:refs/for/master problem, not SSH key
[00:36:28] <sumanah>	 did you do that aliasing thing?
[00:36:34] <sumanah>	 per https://www.mediawiki.org/wiki/Git/Workflow#How_to_submit_a_patch
[00:36:37] <saper>	 Krinkle: git review not installed
[00:36:42] <sumanah>	 git config alias.push-for-review "push origin HEAD:refs/for/master"
[00:36:49] <saper>	 sumanah: no I just stupidly did "git push"
[00:37:13] <sumanah>	 saper: you might just want to alias "git push" to "git push-to-review" or whatever, just for our repo, if that is possible
[00:37:23] <saper>	 yeah I know, I know :)
[00:37:30] <sumanah>	 OK :)
[00:37:35] <saper>	 sorry for whining
[00:37:45] <sumanah>	 It's understandable, this stuff is confusing
[00:38:08] <sumanah>	 but if you find any problems in https://www.mediawiki.org/wiki/Git/Workflow#How_to_submit_a_patch or the rest of that page, please do fix or signal the problem on the talk page
[00:38:19] <sumanah>	 we do want to improve it....
[00:38:21] <saper>	 sumanah: added already
[00:38:34] <saper>	 what's confusing - there mediawiki.org help page and labs help page
[00:38:36] <sumanah>	 :)
[00:38:53] <saper>	 labs help page is the same with ops repo URLs
[00:39:10] <saper>	 and mediawiki.org is almost the same with mediawiki test repo URLs
[00:39:20] <saper>	 we don't want to maintain two guides
[00:39:41] <Krinkle>	 saper: Known issue, there is a plan to merge it already
[00:39:42] <sumanah>	 could you point to the specific pages that are confusing? I am a little confused :)
[00:40:25] <Krinkle>	 Right now the tech-oriented docs on Labs are most up to date. The docs for understanding and getting to know how it works are on mediawiki.org
[00:40:35] <saper>	 https://www.mediawiki.org/wiki/Git/Workflow vs https://labsconsole.wikimedia.org/wiki/Git
[00:41:44] <saper>	 we should have "One Help"(tm) doesn't matter if you are mediawiki user, wikimedia contributor or WMF staff
[00:42:23] <sumanah>	 saper: this is a good goal, yeah. We're inching towards that but it takes time to unify docs and so far, I have been one of the main authors and I have other stuff I have to do
[00:45:31] <robla>	 sumanah: btw, I added something to mw-bot about git access stuff
[00:45:35] <robla>	 !git-access
[00:45:35] <mw-bot>	 Everyone who already has SVN access should request Git access.  If you don't have SVN access, see https://www.mediawiki.org/wiki/Commit_access   If you do have SVN access, see https://labsconsole.wikimedia.org/wiki/Help:Access#Access_FAQ
[00:45:42] <sumanah>	 Thanks robla
[00:45:49] <robla>	 np
[00:46:11] <sumanah>	 saper: if you want to help.... :-)
[00:46:44] <jorm>	 GAH I FUCKING HATE THESE FOREIGN REPO KEYS.
[00:46:50] <jorm>	 "accept permanently" never fucking works.
[00:48:23] <saper>	 sumanah: last evening we were looking at [[:mw:Localisation]] pages, we tried to stuff more "wikimedia-specific" and "translatewiki-specific" stuff in there,  one of the small steps to improve
[00:49:42] <saper>	 robla: maybe you can add something like @i-want-access - paging all nicks who have recessary rights (like it's done on #wikimedia-stewards)
[00:51:08] <saper>	 or @admins
[00:53:55] <Krinkle>	 saper: In general the techies prefer stalk words instead of ping words I think
[00:54:13] <Krinkle>	 so that those who have the rights add that to their watchlist instead of having a bot ping them all and having to maintain that
[00:54:18] <Krinkle>	 stalklist*
[00:54:37] <Krinkle>	 But that does sound like a good idea :)
[00:55:00] <saper>	 "stalk word" is IRC client highlight?
[00:55:06] <Krinkle>	 yes
[00:55:19] <Krinkle>	 not all irc clients have the ability to change that
[00:55:24] <Krinkle>	 pretty much all clients highlight your user name
[00:55:24] <sumanah>	 Hm
[00:55:26] <saper>	 I have only "checkuser" and "cu" :)
[00:55:36] <saper>	 it would be difficult for all people here to manage all their roles
[00:55:36] <sumanah>	 My only stalk words right now are my first name and my nick
[00:55:40] <Krinkle>	 but many clients allow users to add more things like "!help"
[00:55:47] <Krinkle>	 though a few things are required from the requestor before action can be taken, perhaps we can add a help word to mw-bot instead
[00:55:57] <sumanah>	 Thanks for the doc fixes, saper
[00:56:45] <Krinkle>	 !commit
[00:56:45] <mw-bot>	 http://www.mediawiki.org/wiki/Commit_access_requests
[00:58:21] <saper>	 Krinkle: sure, but !git-access is unhelpful if I already read the docs, what's the next step? I know I can *always* ping robla or sumanah
[00:58:45] <Krinkle>	 !git-access
[00:58:45] <mw-bot>	 Everyone who already has SVN access should request Git access.  If you don't have SVN access, see https://www.mediawiki.org/wiki/Commit_access   If you do have SVN access, see https://labsconsole.wikimedia.org/wiki/Help:Access#Access_FAQ
[00:58:52] <saper>	 sumanah: need to do some coding while svn lasts :>
[00:59:10] <sumanah>	 saper: aieee! well, if you're doing anything major, I hope you'll line up a reviewer ahead of time
[00:59:32] <Krinkle>	 saper: Right now the primary mediawiki commit method is SVN. The method to get that is under the page of !commit (read a few steps, and send mail to commit-access-requests@wikimedia.org)
[00:59:36] <sumanah>	 saper: so, we talked about that recently on wikitech-l -- whom newbies should ping
[00:59:46] <Krinkle>	 saper: For Gerrit the boundry will likely be lower as we have gerrit in between
[00:59:54] <saper>	 and access_faq says don't talk to robla: it could read: "say @i-want-my-mtv on #wikimedia-dev"
[01:00:20] <sumanah>	 saper: could you point to 'access_faq'? is that a bot response?
[01:00:48] <sumanah>	 or are you speaking of what could be, potentially, rather than what currently exists?
[01:00:52] <saper>	 sumanah: I have all my changes reviewed on time, I stuff tags until somebody notices :)
[01:01:01] <saper>	 https://labsconsole.wikimedia.org/wiki/Help:Access#Access_FAQ
[01:01:49] <saper>	 sumanah: yeah I read my 1 month backlog on wikitech-l and it said "march 3rd" so I panicked and came here
[01:02:25] <RoanKattouw>	 Oh it's been delayed since
[01:02:31] <RoanKattouw>	 The migration is now March 21st
[01:03:19] <saper>	 I read that 30 messages later ;)
[01:03:46] * sumanah  looks at https://labsconsole.wikimedia.org/wiki/Help:Access#Access_FAQ

[01:06:00] <sumanah>	 saper: I've corrected that page to be slightly more helpful
[01:07:37] <saper>	 sumanah: are Sara and Chad on IRC?
[01:08:05] <sumanah>	 saper: I know Chad often is, Sara less often
[01:08:58] <saper>	 ah it's ^demon!!! why don't we say in the first place:)
[01:09:16] * sumanah  adds some stuff to that pg

[01:10:11] <sumanah>	 saper: by the way, if you know any promising students, we're recruiting potential participants for Google Summer of Code
[01:10:19] <sumanah>	 !gsoc
[01:10:19] <mw-bot>	 MediaWiki participates in the Google Summer of Code mentorship program. http://www.mediawiki.org/wiki/GSoC Please read http://en.flossmanuals.net/GSoCStudentGuide/ if you're thinking of applying to GSoC.
[12:53:16] <^demon>	 hashar: Good morning :)
[12:53:36] <hashar>	 hello :-)
[12:53:48] <hashar>	 post lunch actually :-b
[12:54:19] <^demon>	 My latest core dump is down to 105M. That was without trimming off the extensions (which I've still found no way to do)
[12:54:48] <hashar>	 yeah you are making progress!
[12:55:06] <hashar>	 have you managed to remove the few very big objects such as the ogg videos ?
[12:55:12] <^demon>	 No :\
[12:55:21] <^demon>	 I haven't tried, tbh. I just got the tags right again :)
[12:55:43] <hashar>	 I am not too worried about tags since we can add them manually later on
[12:55:57] <^demon>	 Yeah but will someone take the initiative if I don't do it?
[12:56:04] <^demon>	 I've fixed it, so it's a non-issue now
[12:56:13] <hashar>	 \o/
[12:57:47] <^demon>	 I'm pushing a new copy to test/mediawiki/core.git
[12:57:50] <^demon>	 Gonna see how it turns out
[12:58:37] <^demon>	 If the clone looks good to you afterwords, I'll go ahead and push it to mediawiki/core.git
[12:59:09] <^demon>	 We might have some leftover unattached objects, don't know yet. Those (should) be pretty trivial to clean out.
[12:59:41] <hashar>	 well  git gc  --some-good-agressive-options-there
[12:59:54] <hashar>	 isn't it supposed to find out orphans object and wipe them out?
[13:00:04] <^demon>	 git gc isn't very intelligent.
[13:00:09] <^demon>	 You're better off doing it by hand
[13:00:15] <^demon>	 Like I do with git-repack
[13:02:01] <^demon>	 ugh ugh. Repo just doubled in size. Doing a push --force twice is badddd.
[13:02:16] <^demon>	 Oh wait, nvm.
[13:02:20] <^demon>	 Was looking at the wrong thing
[13:03:07] <hashar>	 while you are around, regarding disabling viewvc in robots.txt, it seems there is no standard to explicitly allow a directory
[13:03:12] <hashar>	 will have to test
[13:03:50] <hashar>	 that was change 2888 https://gerrit.wikimedia.org/r/#change,2888
[13:03:59] <^demon>	 You can't do Allow: foo/* like we originally planned?
[13:04:14] <hashar>	 does not seem to be supported
[13:04:23] <hashar>	 I need to find out a reference on google
[13:04:23] <^demon>	 Phooey.
[13:04:40] <hashar>	 maybe they extended it to support Allow:
[13:04:49] <hashar>	 .....
[13:04:55] <hashar>	 of course just have to look at their http://www.google.com/robots.txt
[13:13:32] <hashar>	 updated :)  https://gerrit.wikimedia.org/r/#change,2888
[13:19:17] <^demon>	 Do you know anything about https://gerrit.wikimedia.org/r/#change,2289 ?
[13:21:50] <hashar>	 nop
[13:24:50] <hashar>	 ^demon:  I have a local git repo on gallium which track my ongoing refactoring of jenkins jobs
[13:25:07] <hashar>	 still have to clean it up a bit and then upload back to gerrit
[13:26:42] <^demon>	 Right. I have no clue what that pylint stuff is for.
[13:28:08] <^demon>	 haha, gerrit's so silly.
[13:28:08] <^demon>	 https://labsconsole.wikimedia.org/w/index.php?diff=2386
[13:29:28] <hashar>	 ^demon: I think the analytic team uses python
[13:30:22] <^demon>	 I know that. But I didn't know anything about us putting it in gerrit, and that commit's been around for almost a month w/o merging
[13:30:26] <hashar>	 for that diff, what we really need a is a link to the gitweb firstpage
[13:30:28] <^demon>	 s/gerrit/jenkins/
[13:31:08] <hashar>	 aka https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git
[13:32:34] <^demon>	 What about it? Where are you wanting that link?
[13:32:52] <^demon>	 \o/ https://gerrit.wikimedia.org/r/gitweb?p=test/mediawiki/core.git;a=summary
[13:33:06] <^demon>	 Feel free to clone and tell me what you think. I'm going to get some breakfast.
[13:33:22] <hashar>	 ^demon: I am having a looonnng nap this afternoon
[13:38:26] <^demon>	 Final clone is 214M. 146M of that is the .git directory.
[13:45:45] <hashar>	 seems we have some octopuss merges :-)
[13:45:56] <hashar>	 f3caa3e
[13:46:56] <^demon>	 yeah, our merge history is a mess.
[13:47:14] <^demon>	 And there's about zilch I can do about it without a bunch of manual work.
[13:47:20] <^demon>	 I gave up trying to make our history sane
[13:47:47] <hashar>	 http://imgur.com/j2rVI
[13:47:59] <hashar>	 got a bug in git somehow :)
[13:48:15] <hashar>	 the diff show several  - and +
[13:48:49] <^demon>	 hm
[13:49:01] <hashar>	 maybe cause that is an octopuss merge ?
[13:49:22] * ^demon  shrugs

[13:49:56] <^demon>	 Other than silly merge history...how's it look?
[13:51:12] <hashar>	 silly http://imgur.com/3OYjt :-)
[13:51:18] <hashar>	 just like a Los Angeles highway
[13:52:40] <hashar>	 that is really silly
[13:53:04] <hashar>	 Sam apparently merged the iwtransclusion branch by chunk of 1000 revisions
[13:54:13] <^demon>	 Yeah, that branch was a mess. We could delete it maybe :p
[13:54:23] <^demon>	 Although I was asked to copy it because it hasn't been merged.
[13:54:58] <hashar>	 ef2aa7b - iwtransclusion/phase3: MFT 77000-78000 (10 months ago) <Sam Reed>
[13:55:01] <hashar>	 ohh
[13:55:15] <hashar>	 that is a merge of trunk to iwtransclusion ...
[13:56:15] <^demon>	 Hmmm. I should make him sort that out :p
[13:56:22] <hashar>	 we could squash the merge commits. maybe it would help
[13:56:35] <hashar>	 cause that severely clutter the history around 1.16
[13:56:49] <^demon>	 You could do that probably.
[13:56:59] <^demon>	 Then force push the branch to rewrite the history
[13:57:21] <hashar>	 but we have to do that before switching from svn to git
[13:57:43] <hashar>	 cause later on rewriting the history would be insane since every sha1 will changes
[14:03:56] <hashar>	 well
[14:04:03] <hashar>	 at least master looks fine:
[14:04:04] <hashar>	 $ git lg --simplify-by-decoration
[14:04:04] <hashar>	 * ff68719 - (HEAD, origin/master, origin/HEAD, master) * (bug 34768) Set width a
[14:04:04] <hashar>	 * d82c14f - Initial revision (9 years ago) <Lee Daniel Crocker>
[14:04:52] <hashar>	 HUHO BEING BOLD:  cb7ae3a - (1.9.2) DO NOT FUCK WITH RELEASE TAGS! THEY ARE PARTICULAR SNAPSHOTTED REVISIONS. (5 years ago) <Brion Vibber>
[14:06:56] <hashar>	 well nap time
[14:36:18] <guillom>	 gwicke: around?
[14:41:53] <qchris>	 Is it safe to assume that "assert"s are deactivated on the wm production servers? (Hence, we may use "assert"s without penalty for the wm's preduction servers?)
[14:50:09] <^demon|away>	 qchris: assert() as in the php function? We don't really use it anywhere.
[14:51:01] <qchris>	 ^demon|away: yes. But in some Database code it would be usefull. But I do not want to use it, if it couses slowdowns for production
[14:51:28] <qchris>	 ^demon|away: Besides, it can help to spot hidden assumptions
[14:51:57] <^demon|away>	 I'd have to see diffs.
[14:52:12] <^demon|away>	 We've gone this long without using them, I'd rather not introduce them now without good cause.
[14:54:09] <qchris>	 ^demon|away: Well they are actually a feature not a problem. But it's ok.
[14:54:59] <^demon|away>	 There's lots of other features we don't use either ;-)
[14:55:04] <^demon|away>	 Like filter.
[14:55:44] <^demon|away>	 Actually, we've got a few assert()s. DarikDiff seems to be the worst offender.
[14:55:50] <^demon|away>	 I'd like Tim's input on it, hrm.
[14:56:11] <qchris>	 ^demon|away: Sure. But some database functions require mConn to be set. others do not. Having an assert in the beginning of functions that rely on mConn could help to see the requirement and automatically detect the problem in debug settings -- without affecting production servers
[14:56:41] <^demon|away>	 You could also just check if( $this->mConn ) and throw an exception.
[14:56:48] <Platonides>	 what's its slowness?
[14:56:58] <^demon|away>	 That's more sane than skipping the assert and then hitting some fatal in production.
[14:57:07] <Platonides>	 I don't see why it would be slower than a check
[14:57:07] <^demon|away>	 Then you get error reporting in test & production :)
[14:57:07] <qchris>	 ^demon|away: That's true. But it would slow down production machines. assert would not.
[14:57:23] <Platonides>	 wouldn't it?
[14:57:24] <^demon|away>	 No it doesn't.
[14:57:31] <^demon|away>	 We already throw exceptions in hundreds of places.
[14:57:38] <^demon|away>	 Well, maybe not hundreds.
[14:57:41] <^demon|away>	 But many many many.
[14:57:52] <Platonides>	 I don't think assert contents are magic for the parser
[14:57:59] <MaxSem>	 and do wfDebug() in even more, though logging isn't enabled in production
[14:58:01] <qchris>	 But ppl would kill me if I add a gourd an all DatabaseMysql function that relies on mConn :D
[14:58:07] <qchris>	 geurd -> guard
[14:58:19] <Platonides>	 get some numbers?
[14:58:23] <MaxSem>	 qchris, don't fix if it ain't broken
[14:58:54] <qchris>	 MaxSem: I am just in the process of fortifying DatabaseMysql :)
[14:59:12] <MaxSem>	 is it broken?
[14:59:25] <qchris>	 Platonides: numbers of how many asserts, or what performance penalty when I add guards?
[15:00:31] <qchris>	 MaxSem: It is use heavily. So it should not suffice to be "not abviously broken". We should invest time in making code understandable, maintainable and readable. and hardened
[15:00:32] <^demon|away>	 assert() would be slower than if( $mConn ). You've got function call overhead on the former.
[15:00:35] <^demon|away>	 Even if it's disabled.
[15:01:19] <qchris>	 ^demon|away: You tested that? This does not meet my experiences.
[15:01:58] <qchris>	 ^demon|away: I'll run some tests for mediawiki code and come back with numbers.
[15:02:01] <^demon|away>	 I suppose I can waste time writing some benchmarks.
[15:02:19] <qchris>	 Ok, then I do not need to spend time on it :D
[15:02:34] <^demon|away>	 I'm being sarcastic. I really don't think this is necessary at all.
[15:03:22] <qchris>	 Ok. Then I'll skip on asserts :(
[15:05:08] <^demon|away>	 I wonder if we really need that assert() in XCF. I should ask Brian.
[15:24:06] <liangent>	 can someone start a mediawiki instance to run trunk code?
[15:24:19] <liangent>	 sorry wrong channel
[15:49:19] <gwicke>	 guillom: ping
[18:22:46] <Krinkle>	 TrevorParscal: nice one on the diffs :)
[18:23:03] <Krinkle>	 didn't have time yesterday
[18:24:29] <hexmode>	 could https://en.wikipedia.org/w/index.php?diff=479777598 ("slow deletion") be the same as https://bugzilla.wikimedia.org/34717 (slow file reversion)?
[18:25:06] <hexmode>	 oh, yeah, think it is
[19:58:42] * siebrand  hops over hashar.

[19:59:08] <hashar>	 siebrand: hops hops
[19:59:17] <hashar>	 siebrand: I have been told you were in Paris recently
[19:59:34] <hashar>	 siebrand: if so, I should have taken a train there :-D
[20:00:13] <siebrand>	 hashar: we had the "Wikimedia Finance meeting 2012" organized by WMFR next to the Bercy stadium/Novotal.
[20:00:16] <siebrand>	 Novotel.
[20:00:30] <siebrand>	 hashar: we'll meet in Berlin in June, right?
[20:00:34] <hashar>	 hopefully
[20:01:11] <hashar>	 or I might decide to take a week in Amsterdam and visit the dutch staff
[20:01:21] * hashar  is out of wine

[20:02:46] <siebrand>	 hashar: no office here, but WMNL could host a "work meeting" inUtrecht, I guess..
[20:02:57] <hashar>	 would be great
[20:03:05] <siebrand>	 hashar: but now RoanKattouw_away fled the country, as you know..
[20:03:13] <siebrand>	 hashar: as has Diederik a while ago.
[20:03:18] <hashar>	 oh my god
[20:03:26] <hashar>	 everyone is fleeing the debt crisis !!!
[20:04:04] <siebrand>	 but we still have Andre Engels, GerardM, Krinkle, mark, myself. Did I forget anyone?
[20:04:31] <hashar>	 seems you have them all
[20:23:03] <SPQRobin>	 Could the sr wikis please be upgraded back to 1.19? I am updating the MediaWiki pages for bug 34832.
[20:25:01] <Krinkle>	 Sal
[20:25:03] <Krinkle>	 !sal
[20:25:03] <mw-bot>	 http://bit.ly/wikisal
[20:27:22] <Krinkle>	 siebrand: could and unofficially has :) (Roan and I last year a few times)
[20:27:32] <Krinkle>	 wmf dutchees office
[20:27:54] <siebrand>	 wee
[20:28:09] <Krinkle>	 more a stroopwafel office than a chees office I suppose
[20:44:50] <[Bergi]>	 Who of you could mw-bot make trust me?
[20:56:13] <hexmode>	 etherpad is acting wonky
[20:56:20] <hexmode>	 5min to triage
[20:59:15] <hexmode>	 guillom: !
[20:59:24] <guillom>	 hexmode: !
[20:59:40] <hexmode>	 is everyone clearing off the etherpad today?  It seems pretty horrible.
[21:00:21] <guillom>	 hexmode: wait, what?
[21:01:26] <hexmode>	 guillom: from the talk on the mailing list, it looked like everyone was encouraged to start archiving etherpad to wiki
[21:01:38] <guillom>	 Yes.
[21:01:41] <thedj>	 hexmode: btw. might be good to add old bugs in the 'code-update-regression' tag to a triage session some time in the future. because there are things there that are in at least 3 releases now.
[21:01:53] <hexmode>	 guillom: and etherpad is only letting me type one or two things now
[21:02:08] <bawolff>	 hexmode: I noticed that on etherpad, you're not listed on the list of users
[21:02:11] <hexmode>	 thedj: good point.
[21:02:15] <bawolff>	 currently editing the pad
[21:02:27] <Krinkle>	 [Bergi]: Got a nickserv account ?
[21:02:28] <hexmode>	 https://etherpad.wikimedia.org/119triage
[21:03:39] <hexmode>	 ok, so I'm doing this differently, so I hope to run through bugs quickly
[21:04:06] <hexmode>	 I basically only want to verify that these are bugs that need to be fixed before we do a tarball
[21:04:20] <Krinkle>	 hexmode: https is not reliable for etherpad,
[21:04:24] <Krinkle>	 read-only basically
[21:04:54] * hexmode  disables https-everywhere and tries again

[21:05:06] <hexmode>	 oo! now I see everyone!
[21:05:10] <Krinkle>	 :)
[21:05:16] <bawolff>	 hexmode: whee, I see you
[21:05:36] <hexmode>	 tarball  or no?    http://bugzilla.wikimedia.org/26411 -- Entries for non-existent categories should be deleted from the 'category' table
[21:05:50] * bawolff  votes no

[21:06:19] <hexmode>	 bawolff: should it be pre-1.20wmf deploy
[21:06:39] <hexmode>	 and I'm willing to go fast enough so that it only takes one vote
[21:06:45] <hexmode>	 so speak up fast :)
[21:07:13] <Krinkle>	 I'd say 1.20.0 normal enhancement
[21:07:16] <thedj>	 i see little priority. it's 'mess' but apparently not problematic
[21:07:17] <bawolff>	 Unless someone ops related says that all those extra category table entries are actually causing problems, I don't think its an important issue
[21:07:58] * bawolff  agrees with krinkle

[21:08:54] <hexmode>	 y o n?     http://bugzilla.wikimedia.org/29542 -- mw.jQueryMsg.js doesn't wrap HTML tags around included templates/links
[21:09:08] <thedj>	 anything in the "Oooh, I like this idea." stage should not be blocking release 1.19
[21:09:18] <thedj>	 n
[21:10:04] <hexmode>	 thedj: good point. so "enhancement", too :)
[21:10:42] <hexmode>	 y o n?     http://bugzilla.wikimedia.org/31173 -- Implement $wgResourcesPath and $wgResourcesDirectory in 1.19
[21:10:50] <hexmode>	 ugh
[21:10:55] <thedj>	 n
[21:10:56] <hexmode>	 enhancement
[21:10:57] <Krinkle>	 yes
[21:11:10] <Krinkle>	 should've been in 1.17
[21:11:13] <hexmode>	 its a tie!
[21:11:16] <bawolff>	 On the surface that seems a very easy enhancement though
[21:11:30] <Krinkle>	 well, wikis that have multiple versions online need it (wmf as well)
[21:11:32] <hexmode>	 Krinkle: can you do that?
[21:11:44] <Krinkle>	 we work around it by prepending all load.php with the domain name in bits.wimedia.org
[21:11:50] <hexmode>	 I'll leave it in 1.19 and assign to you
[21:11:53] <Krinkle>	 OK
[21:12:39] <hexmode>	 y o n:     http://bugzilla.wikimedia.org/31533 -- Check environment and display new results every time when ?page=Welcome is accessed
[21:12:53] <hexmode>	 hrm, I say y
[21:13:07] <Krinkle>	 hexmode: what does <a> mean on the etherpad ?
[21:13:10] <hexmode>	 since this is important for installer
[21:13:12] <Krinkle>	 <a> *
[21:13:15] <Krinkle>	 <s> *
[21:13:17] <thedj>	 i ran into that one as well during the SF hackaton
[21:13:24] <thedj>	 thoroughly confusing...
[21:13:32] <^demon>	 It does redo the checks if you go back -> forward.
[21:13:35] <hexmode>	 Krinkle: what browser are you using?
[21:13:35] <^demon>	 Installer relies on posting.
[21:13:51] <Krinkle>	 hexmode: what meaning are you addressing to striking the bugs on the list
[21:14:16] <hexmode>	 Krinkle: I'm just trying to keep track of where we are
[21:14:39] <Krinkle>	 hexmode: ok, suggest to use bold instead and striking for "done" or "no longer blocking 1.19.0"
[21:14:40] <hexmode>	 but we can <b> the current one, too
[21:14:48] <Krinkle>	 ok :)
[21:15:43] <hexmode>	 guys who just joined, this is a quick going through of 1.19.0 blockers.  That list has grown a lot since we did the deploy and I want to make sure it is right
[21:16:04] <^demon>	 That installer thing isn't a blocker. It's mildly annoying, but it's not a straightforward fix.
[21:16:27] <^demon>	 All pages in the installer are based on posting. It's not just displaying info, it's saving config stuff too based on the detection.
[21:17:00] <hexmode>	 ^demon: could you add your comments from here about what is neede to fix it?
[21:17:11] <hexmode>	 (to the bug)
[21:17:19] <^demon>	 I'm not entirely convinced it needs fixing.
[21:17:26] <thedj>	 it needs UI fixing
[21:17:31] <^demon>	 Just restart. It's only the first step.
[21:17:41] <thedj>	 yet people can't find it :D
[21:17:44] <^demon>	 Or click <- back, ->forward
[21:17:52] <^demon>	 In the installer ui.
[21:18:22] <hexmode>	 ^demon: at least a note about that could be added
[21:18:29] <hexmode>	 so people don't get confused
[21:18:30] <^demon>	 You'd have to muck about in WebInstaller::execute()
[21:19:18] <hexmode>	 moving on:     http://bugzilla.wikimedia.org/31755 -- Styling in headers breaks sortable tables
[21:19:24] <hexmode>	 y or n
[21:20:14] <Krinkle>	 hexmode: I've added about 6 bugs to milestone 1.19.0 that were still open from < 1.19.0
[21:20:22] <Krinkle>	 (1.18wmf1 and 1.19wmf1)
[21:20:32] <hexmode>	 Krinkle: just now you did?
[21:20:38] <Krinkle>	 yes
[21:20:44] <hexmode>	 hrm...
[21:20:48] <Krinkle>	 can be dealt with later
[21:20:57] <thedj>	 let's do this first.
[21:21:12] <hexmode>	 Krinkle: what do you think about 31755 since that seems to be your area?
[21:21:20] <Krinkle>	 checking ou
[21:21:37] <Krinkle>	 comment 7 says it well
[21:21:59] <Krinkle>	 "We need to rewrite the sortable tables to make the indicator a separate element [instead of assuming nobody ever sets a background color]."
[21:22:09] <Krinkle>	 should be a fairly simple change
[21:22:20] <Krinkle>	 imho should've blocked 1.19wmf1, but I care too much about frontend :)
[21:22:31] <thedj>	 simple but with quite a bit of fallout potentially. you are changing the entire way the table is constructed and toggled.
[21:22:37] <Krinkle>	 many old sortable tables lost their buttons because of it
[21:22:49] <Krinkle>	 thedj: not really, it's the way it was before 1.19/1.18
[21:23:00] <Krinkle>	 the background-image and position was new in jquery.tablesorter
[21:23:17] <thedj>	 yes. but still.
[21:23:35] <Krinkle>	 Padding + background image + position is nice in an ideal case scenario
[21:23:48] <Krinkle>	 but the only way I see that happen is if we use a different classname for it
[21:23:54] <Krinkle>	 so that we don't need to be compatible
[21:24:19] <Krinkle>	 e.g. mw-sortable
[21:24:23] <hexmode>	 thedj: you said an element... are you sure it isn't an attribute?
[21:24:43] <hexmode>	 Krinkle: ^^
[21:24:44] <thedj>	 hexmode: where ?
[21:24:53] <hexmode>	 sorry, thedj ... wrong nick
[21:25:06] <Krinkle>	 right now jquery.tablesorter adds a background image to the <td> in the <thead> and positions it to the top right and adds padding so that no text is there
[21:25:08] <Krinkle>	 that's very nice
[21:25:14] <thedj>	 no seperate element. it actually needs to be a child html element.
[21:25:20] <Krinkle>	 but many wikis override the background of the <td> so the image isn't seen
[21:25:23] <Krinkle>	 or override the padding
[21:25:33] <Krinkle>	 which was previously fine since there was no background image there
[21:26:14] <Krinkle>	 It can't even be picked up in a tour the wiki because these styles are very commonly inside the actual articles
[21:26:21] <hexmode>	 k, so is this a 1.19 fix?  Sounds like if you've mucked with background image in your own install you could fix this, no?
[21:26:26] <Krinkle>	 thedj: how's the compromise of using a different class and sticking with the ideal solution?
[21:26:58] <Krinkle>	 hexmode: that's asking editors to edit 10,000s of articles because we decide to change everything about class="sortable"
[21:27:15] <thedj>	 details. we could use the old 'sortheader' class if needed. also saves us from adding noprint mode, which we forgot last time.
[21:27:46] <hexmode>	 sounds like we should def have sort of regression testing on this
[21:28:14] <hexmode>	 k, leaving 1.19 and moving on
[21:28:25] <hexmode>	     http://bugzilla.wikimedia.org/33506 -- Installer: database selection JS is flaky on page=DBConnect with Opera
[21:28:28] <hexmode>	 y or n
[21:29:49] <bawolff>	 I'd say yes, that seems bad if people can't select other dbs
[21:30:00] <hexmode>	 ^demon: opinion?
[21:30:26] <hexmode>	 hrm, not waiting
[21:30:28] <hexmode>	     http://bugzilla.wikimedia.org/33520 -- $wgMaxRedirects totally broke at some point
[21:30:30] <siebrand>	 normal prio because it's not a top 3 browser.
[21:30:33] <hexmode>	 y or n
[21:30:38] <hexmode>	 siebrand: agreed
[21:30:45] <^demon>	 people use opera?
[21:30:45] <^demon>	 :p
[21:30:49] <^demon>	 ^ My thoughts
[21:31:14] * hexmode  lowers the priority more

[21:31:21] <bawolff>	 No to the max redirect bug
[21:31:34] <bawolff>	 That's a not often used option that's been broken since like 1.16
[21:31:54] <siebrand>	 +1 on brian
[21:31:59] <^demon>	 I don't think it ever worked 100%
[21:32:12] <^demon>	 And file redirects in particular have always been flaky.
[21:32:55] <hexmode>	 next:     http://bugzilla.wikimedia.org/33558 -- update.php stuck on update revision on large db
[21:34:41] <hexmode>	 no thoughts?
[21:34:59] <thedj>	 my thought is "not my field" :D
[21:35:04] * hexmode  is tempted to n it

[21:35:11] <Krinkle>	 if update.php doesn't work, that's a problem
[21:35:30] <bawolff>	 Sounds like its possibly just something funky happening to that particular person possibly
[21:35:44] <hashar>	 it is petan
[21:35:46] <hashar>	 n
[21:36:10] <hashar>	 but I don't think asher had any issue when doing the schema changes
[21:36:17] <hashar>	 might not have used the update.php script though
[21:36:40] <binasher>	 wmf never uses update.php
[21:37:14] <hashar>	 binasher: thanks for confirming!
[21:37:25] <hexmode>	 so, I'm gonna remove it from tarball blocker until we can get someone else who things it should be on there
[21:37:26] <binasher>	 but yes, that revision table alter in 1.19 really sucks.. it still hasn't been done on enwiki
[21:37:36] <hashar>	 I guess we want to try to reproduce 33558 with Peter using the labs
[21:37:42] <hashar>	 then we will be able to investigate the issue
[21:37:50] <hashar>	 not much we can do right now
[21:37:54] <binasher>	 as it takes about 30 hours per server with enwiki on our current production dbs
[21:38:24] <binasher>	 that would appear to "hang"
[21:38:46] <bawolff>	 perhaps we should change "Adding rev_sha1 field to table revision..." to
[21:38:52] <hashar>	 just adding the  rev_sha1 field or does it includes populating it also ?
[21:38:53] <bawolff>	 Adding rev_sha1 field to table revision, this will take a long time...
[21:39:04] <binasher>	 just adding
[21:39:04] <^demon>	 binasher: +1. I think it's unlikely that it's "hung" and more likely that it will appear to lag.
[21:39:08] <hashar>	 cause at some point we had a niceee progress report
[21:39:10] <^demon>	 bawolff: Better might be progress markers.
[21:39:30] <hexmode>	 ^demon: ooo! feature request :)
[21:39:32] <bawolff>	 Is it possible to have a progress meter for the alter part?
[21:39:41] <^demon>	 Oh hmmm, no.
[21:39:43] <^demon>	 Population yeah
[21:39:50] <hashar>	 ^demon: we already had a progress meter. The very first version of the patch had one
[21:40:14] <hexmode>	 ok removed from blocker
[21:40:17] <hexmode>	 next: http://bugzilla.wikimedia.org/33689 -- Upgrade to 1.18 on Postgres fails due to incomplete query when trying to defer foreign key for externallinks
[21:40:27] <^demon>	 hashar: How on earth did you put a progress marker on mysql_query()?
[21:40:45] <hashar>	 ^demon: I mean when we compute the sha1 for each files and insert them in the DB
[21:41:13] <^demon>	 Oh, yeah it's easy to do progress markers there.
[21:41:21] <^demon>	 But it's pretty hard to do it for the ALTER TABLE
[21:41:22] <hashar>	 oh I have missed bin ash comment about 30 hours being for the ALTER TABLE statement :/
[21:41:57] <binasher>	 alter table progress reports can be done in hackish methods.. proper progress reporting is only available in new mysql variants and maybe mysql 5.6
[21:42:11] <^demon>	 *nod*
[21:42:31] * hexmode  is gonna leave Bug 33689 on 1.19

[21:43:09] <hexmode>	 next:     http://bugzilla.wikimedia.org/33766 -- Sidebar ignores templates in MediaWiki 1.18
[21:43:17] <hexmode>	 1.19 blocker?
[21:43:17] * ^demon  swore he will never install postgres again

[21:43:18] <^demon>	 :)
[21:43:40] <hexmode>	 ^demon: yeah, I think we neet to get some pg peeps to do it
[21:43:43] <bawolff>	 eww, people doing icky things with sidebar
[21:43:56] <hexmode>	 seems like we have more pg people now
[21:44:02] <bawolff>	 We need a stick to hit people with everytime they do something like that to mediawiki:Sidebar
[21:44:08] <hashar>	 we should drop support for PG
[21:44:10] <thedj>	 sidebar issue dosn't seem to be a big problem.
[21:44:10] <hashar>	 just like IE
[21:44:35] <^demon>	 Who was it who introduced templates to the sidebar anyway?
[21:44:44] * ^demon  wants to go back in time and whack them...hard

[21:45:14] <hashar>	 hexmode: we need to bisect this one
[21:45:20] <^demon>	 As if the sidebar wasn't crappy enough, someone decided to be brilliant and add templates to it too. Ugh.
[21:45:25] <hashar>	 hexmode: seems to be a regression of some sort
[21:45:53] <hashar>	 we need to just drop all the sidebar and use a nice form
[21:46:07] <hashar>	 that would make a great and easy project for a volunteer
[21:46:10] * bawolff  bets the templates still work if they are only a single line

[21:46:24] <siebrand>	 ^demon: don't you know by now that templates and parser functions should fork everywhere? Flex!
[21:46:25] <hexmode>	 hashar: k, I'll let you handle that :)  Not assigning, just making a note.
[21:46:32] <hashar>	 nooo
[21:46:33] <siebrand>	 work, even
[21:46:34] <hashar>	 please
[21:46:34] <thedj>	 so not blocking i guess :D
[21:46:41] <hashar>	 not the sidebar :-D
[21:47:08] <hexmode>	 k, I'll add a note and say not blocking
[21:47:08] <thedj>	 perhaps it could be the first message to support lua ? /me hides
[21:47:09] <siebrand>	 well, we could revert the feature altogether it we really think it's a bad idea..
[21:47:14] <hexmode>	 next!
[21:47:18] <^demon>	 I think it's a crappy idea.
[21:47:59] <Krinkle>	 hey, cross-wiki tranclusion for the sidebar :!
[21:48:12] <Krinkle>	 we totally need to do that
[21:48:24] <Krinkle>	 :P
[21:48:27] <hashar>	 what we really need is a common database
[21:48:43] <hashar>	 but that is a different subject :--)
[21:48:47] <hexmode>	 next, y or n:    http://bugzilla.wikimedia.org/33878 -- HTML dump is missing all images due to new FileBackend code
[21:48:49] <Krinkle>	 j/k (I was)
[21:48:53] <saper>	 ^demon: isn't 33766 a reminscent of the fact that MediaWiki: namespace was _the_ template namespace in a galaxy far far away?
[21:49:04] <thedj>	 hexmode: seems like easy commit and it's done. so yes
[21:49:28] <bawolff>	 Does anyone actually use html dump?
[21:49:30] <Krinkle>	 Hm.. I thought mediawiki namespace came after templates, not sure though
[21:49:49] <hexmode>	 next, y or n:    http://bugzilla.wikimedia.org/34016 -- Special:GlobalUsers subpage parameter mistaken for &username=
[21:49:54] <Krinkle>	 nope, template=10, mw=8
[21:49:58] <hashar>	 bawolff: yes some people use it
[21:50:12] * hexmode  goes and assigns #33878 to thedj

[21:50:47] <hashar>	 hexmode: thedj: aaron fixed it, we need to backport the fix to 1.19 and test it there
[21:50:55] <^demon>	 saper: Not really, no. The sidebar's been special since its introduction.
[21:51:06] <bawolff>	 Krinkle: from what I understand, it was used for templates before it was used for localization. There's some weird stuff in enwikipedia in the mw namespace from way back
[21:51:15] <^demon>	 But yes, a long long time ago (before my time even), the template NS was split off the MW NS
[21:51:18] <hexmode>	 hashar: but he didn't but the rev there
[21:51:19] <Krinkle>	 k
[21:51:29] <hashar>	 https://www.mediawiki.org/wiki/Special:Code/MediaWiki/110703
[21:52:43] <hashar>	 I have updated summary
[21:52:54] <hashar>	 grr
[21:53:07] <hashar>	 I have made a summary for 33878
[21:53:39] <hexmode>	 k, y or n: http://bugzilla.wikimedia.org/34016 -- Special:GlobalUsers subpage parameter mistaken for &username=
[21:53:53] <bawolff>	 for 34016 i'd vote yes, but on borderline
[21:54:42] <hashar>	 yes a block
[21:54:46] <thedj>	 needs labs to verify due to globalusers, but probably easy enough.
[21:54:49] <hashar>	 certainly easy to fix
[21:55:01] <saper>	 Krinkle: we still have {{msg:...}}
[21:55:09] <hashar>	 one can have a look at the very similar bug 31638 fixed by r100516
[21:55:19] <hexmode>	 k, next:     http://bugzilla.wikimedia.org/34083 -- New FileBackend code breaks WebStore extension
[21:55:20] <hashar>	 (adding that last sentence to bug report)
[21:55:36] <^demon>	 Nobody uses WebStore.
[21:55:42] <^demon>	 It's not a blocker to anything
[21:55:51] <hexmode>	 saper: do you see the etherpad we're using: http://etherpad.wikimedia.org/119triage
[21:56:16] <hexmode>	 ^demon: that was easy :)
[21:56:19] <saper>	 hexmode: visited a couple of times
[21:56:40] <hashar>	 I guess we need a BREAKING CHANGE in release notes so
[21:56:59] <hexmode>	 next: http://bugzilla.wikimedia.org/34238 -- mwstore:// URLs appear in various error messages
[21:57:05] <hashar>	 or maybe Aaron fixed it
[21:57:22] <^demon>	 I know he said he was going to.
[21:57:22] <thedj>	 actually aareon probalby fixe the webstore bug from the looks of it. just not verified...
[21:57:47] <hexmode>	 why don't people close bugs when they fix them?
[21:57:50] * hexmode  grumps

[21:57:56] * ^demon  checks

[21:58:03] <hashar>	 I fix them once the fix is deployed
[21:58:08] <thedj>	 hexmode: because, unverified.
[21:58:30] <^demon>	 I see no updates to WebStore.
[21:58:34] <^demon>	 Was it a change in core he made?
[21:58:41] <hashar>	 (we could use a DEPLOYED status :-)  )
[21:58:47] <Krinkle>	 "VERIFIED" ?
[21:58:49] <thedj>	 ^demon: he fixed filebackend to be backwards compatible i think.
[21:58:52] <hexmode>	 ^demon: I think they were talking about the next one
[21:59:04] <^demon>	 thedj: Ah, very possible :)
[21:59:15] * AaronSchulz  doubts that WebStore works

[21:59:21] <saper>	 hexmode: bugzilla orignally had "RESOLVED/FIXED" (done, in trunk) "VERIFIED" (by originator) and later "CLOSED" (deployed) - but we lost CLOSED some time ago I think
[21:59:27] <^demon>	 AaronSchulz: That's what I said ;-)
[21:59:46] <saper>	 s/hexmode/hashar/ ^
[21:59:58] <hexmode>	 saper: It still has them, but we just don't use them
[22:00:00] <hashar>	 saper: yeah someone decided that CLOSED was unwanted :-)
[22:00:13] <hexmode>	 we could start using them like you say
[22:00:42] <Krinkle>	 except that in most cases fixed ==verified and deployed follows en-mass a month later
[22:00:53] <hashar>	 I think bugzilla 4 comes with a different workflow anyway (unconfirmed, confirmed, in_progress, resolved, verified)
[22:00:56] <Krinkle>	 so probably more maintenance than use I think
[22:01:18] <hashar>	 hexmode: 34238 you can keep it as a blocker
[22:01:54] <Krinkle>	 (saper http://i.imgur.com/bxhYU.png )
[22:02:00] <hexmode>	 hashar: someone FINALLY said something about that one! :)
[22:02:02] <Krinkle>	 hashar:
[22:02:13] <Krinkle>	 it comes with no workflow, you make one :)
[22:02:25] <hashar>	 hexmode: opened by Tim, with Aaron working on it. So that should be fine.
[22:03:10] <hexmode>	 next y o n:     http://bugzilla.wikimedia.org/34372 -- New User hook broken for PG, breaks normal logging
[22:03:14] <hexmode>	 pg again
[22:03:22] <hexmode>	 y
[22:03:36] <hexmode>	 but we need to get a pg person on these
[22:03:37] <hashar>	 arent we dropping postgre support ?
[22:03:38] <saper>	 Krinkle: I used to close mine https://bugzilla.wikimedia.org/show_activity.cgi?id=17488
[22:04:02] <hexmode>	 hashar: where did you hear that?
[22:05:16] <hexmode>	 next:     http://bugzilla.wikimedia.org/34798 -- Diffs on recent changes feed should have the same formatting of the on wiki diffs
[22:05:26] <Krinkle>	 Oh, we're unfriendly to minors ?
[22:05:32] <hashar>	 looks like it is a regression in the way we pass page_id to some new user hook . So I guess 34372 should be 1.19 blocker.
[22:05:36] * Krinkle  can't help associate "PG" with US television

[22:05:55] <hexmode>	 heh
[22:05:56] <Krinkle>	 34798 : yes, todo, easy
[22:06:11] <hexmode>	 Krinkle: yeah, sooner rather than later
[22:06:31] <hexmode>	 next:    http://bugzilla.wikimedia.org/34801 -- Function applyDiffStyle uses regexes which do not detect CSS classes appropriately
[22:06:41] <Krinkle>	 Trevor/I should have done that at the same time. but nobody thinks about that akward inline css for feeds
[22:06:59] <hexmode>	 Krinkle: you mean #34801?
[22:07:05] <Krinkle>	 hexmode: no
[22:07:13] <Krinkle>	 don't know that that bug is
[22:07:20] <hexmode>	 ah, k
[22:07:20] <Krinkle>	 ah, related.
[22:07:43] <hexmode>	 so y
[22:07:53] <hexmode>	 now we get to the fun part
[22:07:54] <Krinkle>	 maybe, maybe not. it's worked so far of the last X years
[22:07:56] <hexmode>	 IE7 hell
[22:07:59] <Krinkle>	 not blocking
[22:08:05] <Krinkle>	 34801
[22:08:16] <hexmode>	 k
[22:08:21] <hexmode>	 next:    http://bugzilla.wikimedia.org/34822 -- IE7: cannot type in Help:Contents search box
[22:08:35] <chrismcmahon>	 kaldari was looking at that yesterday
[22:09:10] <kaldari>	 Oh yeah, haven't poked it today, but I'll do that next
[22:09:39] <hexmode>	 kaldari: are you the IE7 guy who I can torture with IE7 bug?
[22:09:43] <hexmode>	 bugs
[22:09:47] <kaldari>	 looks like it's a weird formatting/layout bug in IE7
[22:09:51] <^demon>	 hashar: And mysql. We're all moving to mongodb.
[22:09:59] <hashar>	 ahh it was about time
[22:10:04] <kaldari>	 hexmode: I hope not ;)
[22:10:21] <hashar>	 ^demon: I am constantly trolled at my local hacker group for us using MySQL :/
[22:10:39] <^demon>	 Do they tell you how mysql is not web scale?
[22:10:41] <kaldari>	 Yeah, we should switch to Excel
[22:10:51] <hexmode>	 kaldari: chrismcmahon: so a general q: should IE7 bugs be tarball blocking?
[22:11:11] <^demon>	 kaldari: While we're suggesting bad ideas, how about Access? :)
[22:11:16] <^demon>	 Or flat file.
[22:11:16] <Krinkle>	 hexmode: If it's mediawiki core, then yes
[22:11:18] <kaldari>	 Even better :)
[22:11:20] <Krinkle>	 we even support IE6
[22:11:22] <chrismcmahon>	 hexmode: I honestly don't know
[22:11:28] <Krinkle>	 but those IE7 bugs are either extensions or local wiki scripts
[22:11:47] <Krinkle>	 at least from what I've seen, but we'll see when we get to the others
[22:11:52] <hexmode>	 I had a mongodb recuiter call me twice about being their php open source evagelist if anyone wants that one
[22:11:53] <Krinkle>	 this one is InputBox extension
[22:12:15] <kaldari>	 hexmode: They could be, but I haven't seen any yet that would warrant blocking the tarball.
[22:12:36] <hashar>	 hexmode: the rest of the bugs, there is not much I can do so I am heading to bed & weekend.
[22:12:40] <kaldari>	 I should have a better idea by the end of the day
[22:13:08] <hexmode>	 hashar: l8r
[22:13:22] <hexmode>	 how about this one: http://bugzilla.wikimedia.org/34823 -- IE7: js error from Special:CentralAuth
[22:13:35] <[Bergi]>	 Shouldn't http://bugzilla.wikimedia.org/31576 - Magic words are considered to be (non-existing) templates be on the list as weel?
[22:13:38] <hexmode>	 not core
[22:13:47] <chrismcmahon>	 34823 should be minor, doesn't prevent function, it's just ugly
[22:14:04] <hexmode>	 k
[22:14:32] <hexmode>	 next:     http://bugzilla.wikimedia.org/34825 -- Special:WhatLinksHere breaks on IE7 (Operation aborted, webpage could not be displayed)
[22:14:34] <thedj>	 we have more ugly CentralAuth issues
[22:14:37] <thedj>	 np :D
[22:14:45] <Krinkle>	 34825 is very much blocking
[22:14:47] <chrismcmahon>	 34825 is pretty bad
[22:14:51] <Krinkle>	 it's so bad, it's almost cool
[22:15:06] <Krinkle>	 Ie7 just fries on that one
[22:15:15] <Krinkle>	 but...
[22:15:24] <Krinkle>	 I'm 99% sure it's a local JS issue
[22:15:44] <Krinkle>	 doesn't happen on trunk via localhost on IE7 and not on mediawiki.org or test.wikipeida.org in IE7
[22:15:48] <Krinkle>	 (bug 34825)
[22:16:20] <chrismcmahon>	 Krinkle: that's news to me, i saw it consistently (but I believe you, my IE7 is on an old VM)
[22:16:24] <thedj>	 could also be ACP, autoclick or any of the other dozens of scripts that are en.wp specific.
[22:16:36] <Krinkle>	 chrismcmahon: I'm seeing it consistently too, but only on en.wikipedia
[22:16:37] <thedj>	 eh clickTracking i mean
[22:16:39] <Krinkle>	 (in  IE7)
[22:16:43] <chrismcmahon>	 ah
[22:17:28] <hexmode>	 next:     http://bugzilla.wikimedia.org/34885 -- RTL with IE-7 (or IE 8/9 in "compatability mode") does not show any toolbar
[22:19:46] <hexmode>	 hrm... lack of votes, I'm leaving it, though, and asking SPQRobin to fix it
[22:20:07] <hexmode>	 next:     http://bugzilla.wikimedia.org/34832 -- $wgOut->addWikiText() doesn't run language converter
[22:20:16] <SPQRobin>	 since when do votes count? :)
[22:20:29] <hexmode>	 SPQRobin: for this triage only
[22:20:50] <hexmode>	 SPQRobin: and it is only a straw poll of devs
[22:21:15] <hexmode>	 SPQRobin: can you look at/fix 34885 ?
[22:21:49] <SPQRobin>	 hexmode: will take a look at it later
[22:21:55] <hexmode>	 k
[22:21:57] <hexmode>	     http://bugzilla.wikimedia.org/34832 -- $wgOut->addWikiText() doesn't run language converter
[22:22:06] <hexmode>	 def leaving that one on there
[22:23:01] * hexmode  thinks hasha r was the only person kind enough to say "good night"

[22:23:04] <hexmode>	 ;)
[22:23:16] <hexmode>	 next:    http://bugzilla.wikimedia.org/34841 -- Edit links seen on previous page versions
[22:23:20] <hexmode>	 y
[22:23:48] <thedj>	 that needs fixing
[22:24:39] <hexmode>	 well, they *all* need fixing.  We're just prioritizing their importance :)
[22:24:51] <hexmode>	 Krinkle: this one is for you   http://bugzilla.wikimedia.org/34853 -- Shouldn't break ALL gadgets if an unknown dependency is informed in only one of them
[22:25:07] <Krinkle>	 ok
[22:25:46] <thedj>	 hexmode: it's 23:25 here, please forgive me for being terse :D
[22:25:46] <hexmode>	 Krinkle: keeping for 1.19 or are they insane?
[22:26:23] <hexmode>	 thedj: np Its a friday night, too.
[22:26:31] <Krinkle>	 It's a fair bug report for ResourceLoader, not even gadget specific
[22:26:44] <hexmode>	 :)... keeping then
[22:27:19] <hexmode>	 y or n: http://bugzilla.wikimedia.org/34862 -- Missing account data, contributions and history
[22:29:36] <hexmode>	 seems like a SUL-only bug. removing from blocker
[22:30:29] <Krenair>	 I don't think I quite understand that bug.
[22:30:43] <Krenair>	 That Special:Contributions is not empty
[22:31:38] <hexmode>	 Krenair: k, I've removed it already, but maybe it was an intermittant problem
[22:31:55] <hexmode>	 Krenair: ask person reporting it if they still see it?
[22:32:04] <thedj>	 i need to sleep. good luck everyone.
[22:32:05] <Krenair>	 Although the Special:UserList link didn't show the user.
[22:32:13] <hexmode>	 thedj: night!
[22:32:26] <hexmode>	 thedj: also, tyvm for your input
[22:33:31] <hexmode>	 next, seems wonky: http://bugzilla.wikimedia.org/34873 -- problems listing contributions for users who are attached to multiple user ID's
[22:34:00] * Krinkle  might be half-way solving bug 34823

[22:35:03] <hexmode>	 \o/
[22:36:20] <hexmode>	 I think the comment that re-opened #34873 doesn't merit something to block 1.19 tarball
[22:37:46] <hexmode>	     http://bugzilla.wikimedia.org/34877 -- Broken logs after special page name change
[22:39:01] <hexmode>	 Nikerabbit's comment ("It has an alias. But logs use the stored canonical version, which has changed.") makes this look like a non-blocker
[22:40:25] <hexmode>	     http://bugzilla.wikimedia.org/34887 -- revert link on page move feature produces error message
[22:40:44] <hexmode>	 that one looks like a blocker def
[22:41:20] <hexmode>	 3 more bugs, even if everyone else has left :)
[22:41:33] <hexmode>	 everyone but me, that is
[22:41:37] <hexmode>	     http://bugzilla.wikimedia.org/34889 -- [Regression] Normalize user name on Special:Contributions
[22:41:47] <chrismcmahon>	 I'm still around, I just lack context :)
[22:42:27] <hexmode>	 chrismcmahon: well, thanks for saying something ... makes me feel not alone
[22:42:28] <hexmode>	 :)
[22:42:41] <Krenair>	 I'm still here
[22:43:32] <hexmode>	 Krenair: yeah, I'm just acting needy.  I'll stop now :)
[22:43:51] * hexmode  pokes at 34889

[22:44:41] <hexmode>	 robla: do you know who Michael M is? from bug 34889?
[22:44:49] <hexmode>	 Is he the SMW dev?
[22:45:22] * robla  doesn't

[22:45:43] <hexmode>	 hrm, he has been actively reporting a few bugs
[22:45:48] <hexmode>	 I should contact him
[22:46:05] <hexmode>	 and the SMW guy is Michael E. so probably not him
[22:47:03] <hexmode>	 oh, look! he is the WikiEditer dev and Sumanah asked him for help on the 21st
[22:47:21] <hexmode>	 it all comes together ... go sumanah!
[22:48:15] <[Bergi]>	 [[de:User:Schnark]]
[22:48:40] <hexmode>	 http://bugzilla.wikimedia.org/34893 -- Jump-to accesibility links feature broken
[22:48:46] <hexmode>	 one more
[22:49:03] <[Bergi]>	 see http://de.wikipedia.org/w/index.php?title=Wikipedia:Fragen_zur_Wikipedia#MW1.19:_Problem_-_Vorlage:Benutzer_.28erl..29 for bug 34889
[22:49:58] * hexmode  clicks

[22:51:01] <[Bergi]>	 but I can't confirm this happens since 1.19
[22:54:13] <hexmode>	 [Bergi]: ty, updated bug with that link
[22:55:13] <hexmode>	 looks like Krinkle is on top of     http://bugzilla.wikimedia.org/34893 -- Jump-to accesibility links feature broken
[22:55:18] <hexmode>	 so I'm leaving it
[22:55:27] <Krinkle>	 I'm not
[22:55:32] <[Bergi]>	 Yeah, but its that section isn't really more information
[22:55:43] <Krinkle>	 I think it's either a dupe of that bug I mentioned, or something I don't understood correctly from the summary
[22:56:01] <Krinkle>	 thedj: might be able to elaborate
[22:56:03] <[Bergi]>	 most of it is about template syntax and urlencoded wikilinks
[22:58:40] <SPQRobin>	 hexmode: about https://bugzilla.wikimedia.org/show_bug.cgi?id=34885, while it's for RTL, I don't think it's really an RTL bug in itself. The toolbar is also not something I'm familiar with, so I can't easily fix it.
[22:59:45] <hexmode>	 SPQRobin: k, thanks for looking
[23:00:49] <hexmode>	 final one: http://bugzilla.wikimedia.org/34901 -- Link styles in Monobook are broken
[23:01:28] <[Bergi]>	 I think that one should be trivial - much luck!
[23:01:45] <hexmode>	 hrm, think I saw some talk on WP:VPT about this, but I dunno
[23:02:01] <Krinkle>	 probably just removing the code from monobook, issue solved ?
[23:02:11] <hexmode>	 yeah...
[23:02:14] <hexmode>	 leaving it
[23:02:20] <thedj>	 depends on wether the color differs...
[23:02:30] <Krinkle>	 in your summary it doesn't
[23:02:47] <thedj>	 then it can probably be removed.
[23:02:49] <Krinkle>	 else we adjust the selectors
[23:02:54] <hexmode>	 ok, 2 hours at this, I'm done.
[23:02:57] <thedj>	 but we have to check the other skins as well.
[23:03:34] <hexmode>	 thedj: aren't you asleep?
[23:03:57] <thedj>	 not yet. was brushing teeth and stuff like that :D
[23:05:37] <hexmode>	 thedj: and I think you're right about regression tag...  ugh 19 bugs.... will do another one with that