[01:30:03] |- [01:30:03] | (small|medium|large).dblist || Database lists of wikis arranged into their relevant size [01:30:03] |- [01:30:32] becomes [01:30:34] [01:30:34] medium|large).dblist [01:30:34] Database lists of wikis arranged into their relevant size [01:30:36] [01:35:17] oh, pipes [01:35:18] FAIL [01:36:15] Or not.. [01:37:31] Bedtime [12:31:38] New patchset: Zfilipin; "Gems needed for tests to run on Windows" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/56590 [12:31:38] New patchset: Zfilipin; "Updated Ruby gems" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57056 [15:30:37] Can anybody tell me why "git review -d 37564" [15:30:37] gives me "Could not parse json query response: u'Code-Review'" [15:31:07] <^demon> git review sucks. [15:31:23] <^demon> Probably because CRVW was renamed to CodeReview and VRIF was renamed to Verified, internally. [15:31:33] <^demon> Breaking changes sucks. [15:32:40] Yes, I'm not a fan of git review, and it seems to dislike me too [15:34:09] <^demon> You can do it all with vanilla git commands, if your git-fu feels ready. [15:34:33] my git fu is better than my gerrit fu [15:36:01] <^demon> So, to push something to gerrit for review, you can do `git push origin HEAD:refs/for/master` [15:36:16] <^demon> This is a long-form git push command, and what git-review is really doing behind the scenes. [15:36:47] <^demon> You can swap origin for any other remote, HEAD for other commits, and master in refs/for/master to any other destination branch. [15:37:27] <^demon> (I have this command aliased to `git push-for-review`) [15:41:52] thanks ^demon, you at least reassured me it's not my specific gerrit disability [15:42:04] <^demon> yw. [15:42:26] I just use the latest git-review from git [15:43:03] They managed to break 1.20 somehow so I can't update to the official release [15:43:57] I'm still on 1.18 [15:49:06] chrismcmahon, again an IP address is updating QA status pages. Is that you? [15:51:03] I don't understand how foundation staff manage to edit logged out so much [15:51:35] chrismcmahon, also, I dunno, there is so much work put into QA and then it is not reflected at all in the monthly reports... :( [16:05:16] Krenair, thank you for the useful feedback at http://www.mediawiki.org/wiki/Talk:Technical_communications/Dev_wiki_consolidation#Where_to_draw_the_line_25778 [16:05:45] Krenair, could I deduce that all the rest is more or less fine with you? :) [16:07:05] andre__, I didn't realize the Bugzilla call is at the same time than the bug day. You are excused. :) [16:07:13] you're welcome [16:07:23] I'm not too happy with the idea of kicking the devs off of mediawiki.org [16:07:37] qgil, I'll try to do both :) [16:08:06] wikimedia engineering tasks, stuff which is useless to third parties and only wikimedia specific should go to wikitech, yes. [16:08:19] but API docs, extension dev tutorials, etc. are all very much relevant to mediawiki [16:08:35] Krenair, you are convincing me about this, yes. [16:09:10] I see interwiki redirects are mentioned on the page [16:09:39] Krenair, yes, mentioned by Susan I believe but I don't know how technically feasible is that. [16:09:50] IIRC those don't get followed automatically unless set up to do so in the database [16:10:02] Krenair, exactly [16:10:19] It has the same effect as browsing to a redirect page with ?redirect=no [16:10:49] So https://test.wikipedia.org/w/index.php?title=Test_interwiki_redirects [16:11:33] Krenair, ah ok. I thought the proposal referred to automatic redirects. [16:12:00] Krenair, we'll see. If the line makes sense and the bridges are well defined I don't see a big problem, or not a problem at all [16:13:31] sorry, I got disconnected again. yeah generally redirects are expected to be automatic rather than click-through [16:20:23] I don't really understand wikimedia's interwiki setup, but I think this has to do with whether the wikitech interwiki is considered local or not (iw_local) [16:30:52] If you are interested in MediaWiki page and skin rendering: Just a quick heads up that there is a bugday starting now in #wikimedia-office and everybody is free to join and help cleaning up and retesting bug reports. See https://www.mediawiki.org/wiki/Bug_management/Triage/20130402 for more info! [16:41:10] andre__: stupid question, why aren't those bugdays in #mediawiki? have they always been in -office and I just didn't notice (bad me) [16:41:40] heh [16:43:19] greg-g: they'd been in this channel before [16:45:00] <^demon|lunch> I don't like -office. Less people idle in there. [16:45:18] greg-g, good question. They have been in #wikimedia-dev before. That's good because devs might provide drive-by comments, and bad because it's noisy. [16:45:36] so this time we try office. I can say hi to people joining, but there might be less drive-by comments. [16:45:47] * greg-g nods [16:45:56] let's bikeshed the channel names and purposes! [16:51:18] <^demon|lunch> greg-g: In my day, we had like 3 channels. And we liked it :) [16:51:31] ^demon|lunch: :) [16:53:28] ^demon: hey, let me bikeshed a little: let's make the gerrit notifications in #mediawiki have some color so I can parse them quicker, yeah? ;) [16:53:45] <^demon> They're totally puppetized. [16:53:55] <^demon> Anyone can change those hooks and push for review. [17:01:26] ^demon: did you just tell me to shut up? ;) [17:02:01] <^demon> No, I'm just saying the code's there, {{sofixit}} ;-) [17:02:13] yeah, that's what I thought [17:02:24] * greg-g looks [17:08:55] sure, he leaves right when I'm going to complain about needing deal with .jars [17:19:09] ^demon: An RT ticket just came in about deploying a bugzilla change. Is that your bag? [17:19:18] <^demon> Nope. [17:19:34] ok, I'll ask in ops channel [17:19:47] <^demon> That really freaking needs to be puppetized. [17:20:13] yes! [17:37:27] any API knowledgable reviewers to review Brad's change here? https://gerrit.wikimedia.org/r/#/c/57067/ [17:38:51] yurik: ^ [17:38:57] this is very high priority -- breaks some bots (particularly anti-vandalism) [17:40:17] greg-g: andre__: fyi ^ that's the fix for bug 46787. see my last comment on the bug [17:40:21] !b 46787 [17:40:21] https://bugzilla.wikimedia.org/46787 [17:41:21] ah thanks [17:55:52] <^demon> robla: +2'd. [17:56:03] cool, thanks [18:03:54] Looking at CurlHttpRequest.execute() in HttpFunctions.php ... [18:04:29] <^demon> xyzram: What about it? [18:04:39] The result of curl_error() is used as if it were a numeric code [18:04:57] But the docs for it say it is actually a message string. [18:05:07] <^demon> Lemme look. [18:12:26] zeljkof: Hi! Do you have any time available to work on the script? I'm not sure if you're still available now? [18:14:14] hi rachel99 :) I do not have the time today, but any other day this week works for me [18:14:35] rachel99: I have to go now, send me an e-mail message with date/time that is good for you [18:14:42] zeljkof: Ok. thanks [18:18:30] <^demon> xyzram: I'm just going to remove that stuff...you're right, it's totally bogus. [18:18:36] <^demon> Will have a patch in a moment. [18:19:02] Ok, thanks. [18:21:17] Different question: Http.request() just returns false if an error occurs giving the caller (MWSearch) no way to get at the content error message. So ... [18:23:43] I'm considering 2 possibilities: (a) Modify request() so it returns content even for errors if a special option is present (e.g. "needError") or (b) always send success status from lucene and let the caller sort it out. [18:23:43] <^demon> Yeah, http::request() and get()/post() are pretty old code and only return false || content. [18:23:49] <^demon> You can do something like this instead: [18:24:24] <^demon> $req = MWHttpRequest::factory( $url, $options ); [18:24:35] <^demon> Then you can do $req->execute() and have all the other methods from it. [18:25:33] <^demon> https://gerrit.wikimedia.org/r/#/c/57097/ - here's the fix for curl_error() [18:27:19] Ok, that suggestion looks promising. [18:30:29] <^demon> So, bit of history...a long time ago we only had Http::get(), Http::post() and Http::request(). The latter of the 3 was a giant function with tons of if/else code to support both backeneds. We rewrote it as MWHttpRequest and its two subclasses. The Http class is retained for back-compat and for shorthand utility access (eg: when status doesn't matter) [18:30:32] Patch looks good but why is host-unreachable removed ? [18:30:46] <^demon> Message is unused now [18:30:53] OK [18:31:18] <^demon> http-timed-out is still used by the non-curl implementation, which is why I left that one. [18:31:18] awjr: Hi [18:31:27] hi Krinkle [18:31:44] awjr: It's not documented, and I'm not sure it should, though I understand your confusion. [18:31:50] "Submit" is gerrit language for "Merge" [18:32:07] The button is supposed to be self-explanatory [18:32:15] Don't push "Submit" if you want jenkins to merge it. [18:32:27] sure, but i still expect the tests to be run - so it's really language for 'bypass safeguards and merge' [18:32:42] or rather, tests to be run and merge to fail if the tests fail [18:32:59] Hashar, Chad and I have all took turns on wikitech-l telling people not to merge manually anymore but only publish CR+2 comments, and let jenkins merge it. [18:33:20] awjr: Yes, so don't merge it manually. [18:33:33] No, it doesn't bypass safeguards. [18:34:11] i feel like if this is something that's had to be reiterated on wikitech-l, it's worth documenting and just pointing folks to the documentation in the future [18:34:35] Thanks for that historical note (sometimes I'm struck by how similar code evolution and species evolution are). [18:35:32] awjr: I don't know how many times to repeat it, it won't help. I've pointed it out several times. All that's left to do is to remove the Verified and Submit UI, which I've already started doing [18:35:50] <^demon> Krinkle: In an ideal world, jenkins would always merge and we could remove the submit from humans and remove some of the confusion. [18:35:51] awjr: I query logs periodically, you're the last one left still doing submit manually :) [18:35:56] lol [18:36:00] :( [18:36:14] old habits die hard [18:36:16] ^demon: In VE we already removed Verified and Submit from the UI, no problems. [18:36:49] <^demon> We've had problems off and on with deployment branches, and I don't think 100% of extensions are covered yet, otherwise I'd do that for mediawiki/* [18:36:50] alright Krinkle, hopefully this time it will stick for me :) [18:36:58] If something is super important, we'd probably bypass gerrit anyway and hack it in the cluster and commit later. [18:37:48] There are some errors popping up occasionally, yes. But afaik those are always fixed in a few minutes (hours at most). [18:37:54] The commit can just sit during that. [18:38:08] If it's super urgent, commit on fenari locally? [18:38:53] anyway, extensions that aren't covered yet can keep the override, I don't mind [18:39:03] As long as we're all aware that we're moving towards fixing it and removing it. [18:39:13] <^demon> Yeah. [18:39:16] ^demon: any extensions in particular I should know about? [18:39:40] <^demon> None offhand. [18:39:43] OK [18:39:48] <^demon> It was just general hand-waving :) [18:56:39] rachel99: I am back, if you would like to arrange day/time for the next coding [18:56:48] ok, sure. [18:56:57] tomorrow? [18:57:16] sure, either before 11:45am or after 2:30pm (EST) [18:57:45] rachel99: let me see what time that is in my time zone [18:57:51] Krinkle: are you saying that we should not hit "Publish and Submit" on gerrit? Instead, just "CR+2 + Publish"? [18:58:30] bsitu: Yes. Touching Verified+/- score or pushing ".. and Submit" is to be considered disallowed and has been for several months. [18:58:45] Unless you intentionally have to override any tests [18:59:03] rachel99: 10am your time tomorrow? [18:59:51] zeljkof: Sure, 10am is fine. (I think we're on EDT now, btw) [18:59:52] If you have access to a repository where you are able to use Verified/Submit and tests are passing, you could ask ^demon to update the gerrit configuration for that project and remove those confusing buttons. [19:00:15] mediawiki/core has all tests passing, but there are other reasons we still have them there. [19:00:22] Krinkle: Thanks! [19:00:28] rachel99: I will send you google calendar invite for the event, it should have time in your time zone [19:01:06] <^demon> Krinkle: I'd really really rather not do it on a per-repo basis :\ [19:01:15] ok, great. Also, regarding specs needed for a new PC that I am getting, is Windows 8 ok to get? [19:01:18] <^demon> I'd much rather fix the jenkins cases for mediawiki/* as a whole, and do it once. [19:01:52] ^demon: So I gather that it is possible to tighten it on a per-repo base. [19:01:59] <^demon> It is. [19:01:59] ^demon: Is the opposite possible? [19:02:08] <^demon> Yes [19:02:08] rachel99: I have sent the invite. yes, any windows should be fine [19:02:25] <^demon> Could DENY at mediawiki/* and ALLOW at a given repo, or the reverse. [19:02:29] E.g. revoke verified/submit on mw/* and enable for /core until we are certain deployment branches are working properly. [19:02:34] zeljkof: Thanks! see you tomorrow. [19:02:46] rachel99: see you tomorrow [19:03:07] ^demon: If so, I'd be okay with doing that right away. Though we'll want to make sure nobody is still making it a habit of having breaking tests and merging. [19:03:21] <^demon> Truth. [19:03:25] afaik all those cases are already covered by having jenkins tests for those cases non-voting. [19:03:43] <^demon> As long as it doesn't catch anyone unawares....I think it'd be fine. [19:03:45] and it will always V+1 and V+2 because the -merge tests is always voting. [19:11:51] @labs-project-instances tools [19:11:55] nvm [19:48:46] can people look at this and see if there are glaring errors? [19:52:12] New patchset: Krinkle; "Enable voting for mwext-AbuseFilter-jslint." [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/57168 [19:53:52] Change merged: Krinkle; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/57168 [20:17:51] ori-l: TrevorParscal: Can one of you merge this please? https://gerrit.wikimedia.org/r/#/c/57092/ Then I can get on with enabling qunit on extensions [20:43:11] ori-l: done, https://gerrit.wikimedia.org/r/#/c/57092/ [20:44:49] Krinkle: merged [20:46:14] ori-l: You reviewed the follow up that cleans it up [20:47:58] (that was https://gerrit.wikimedia.org/r/#/c/57181/, not https://gerrit.wikimedia.org/r/#/c/57092/) [20:49:06] Krinkle: i meant to merge both, actually, but the first one hung on submit review, and i hadn't noticed [20:49:13] k [20:49:14] anyways, reloaded and submitted. [20:49:27] Gerrit tends to hang on "Working..." from time to time [20:49:31] I've seen that too [20:54:55] AaronSchulz: Fancy reviewing 4 [20:54:58] grlkm4wapoimf3apo [20:55:10] AaronSchulz: Fancy reviewing 5 few line patches for Collection? [20:55:21] https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/extensions/Collection,n,z [20:56:33] I guess not [20:57:14] * @param $props array the lilst of the proposals [20:57:31] I was going ot fix that typo too [20:57:32] see if people used type hinting while testing some of these errors probably wouldn't exist [20:57:41] or there would at least be useful backtraces [20:58:20] $this->mLinkList = is_array( $props ) ? $props : array( $props ); [20:58:32] is that actually what is needed? A single prop string comes in? [20:58:50] or is that just there to avoid the exact fatal and cause some error somewhere else? [20:59:17] It's something that can't be iterated over [20:59:36] And as it's only a warning, we don't get any more info from our logs [21:00:02] yes, but would it actually do something sensible? [21:02:26] https://gerrit.wikimedia.org/r/#/c/54625/2/Collection.suggest.php [21:02:34] Reedy: did you mean "if ( !$resolved )" ? [21:02:58] yup [21:04:08] I see Krinkle said the same thing about the array thing [21:04:30] Flew by in #mediawiki, I see you're talking about it here. Ha, yeah, same thing :) [21:06:02] Reedy: https://gerrit.wikimedia.org/r/#/c/54625/4/Collection.suggest.php [21:06:13] are you assume __toString() was used before? [21:06:27] eh? [21:06:38] The getText() is moved down below the if [21:06:58] still there, just a few lines lower [21:07:03] I see [21:08:17] Reedy: Changing it to array( $props ) might mask an error instead of fixing it. Better figure out a bit more about this one before changing it like that. [21:08:27] $proposals = new Proposals( [21:08:27] $_SESSION['wsCollection'], [21:08:27] $_SESSION['wsCollectionSuggestBan'], [21:08:27] $_SESSION['wsCollectionSuggestProp'] [21:08:27] ); [21:08:30] Perhaps drop it and else to array() instead of array( $props ); [21:08:40] I had it as that originally [21:08:42] I just changed it [21:08:46] oh [22:23:17] AaronSchulz: is there some reason you still prefix your topics with 2012/? [22:23:53] force of habit, who knows [22:24:22] it's funny that all the last things have that though [22:24:30] I don't see any 2013s in there :) [22:25:06] I see gerrit has a quick topic edit button [22:25:47] yeah, some people have tried using it on your commits [22:27:07] all 2013 now [22:27:13] nope [22:34:11] TimStarling: I noticed that SqlBagOStuff will bubble up connection exceptions (unlike the other BagOStuff functions), I blame 30d6510f63f8209e7284252904bce8313d52b093 [22:34:44] * AaronSchulz ran into this with $wgSessionsInObject cache on a testwiki [22:35:51] it also means pc1-3 being down is a bit of an outage again [22:35:55] * AaronSchulz runs from binasher [22:38:29] mmm, the getDB() calls were moved outside of the try block [22:39:06] only in getMulti though [22:39:13] get() calls getMulti() [22:39:16] I guess when I tested connection errors, I used some other function [22:39:30] surely not... [22:39:32] * AaronSchulz wonders what silly person reviewed that, oh... :) [22:39:53] I should have tested every function [22:47:23] next( $msleep ) ?: 1000 [22:47:43] TimStarling: I'm surprised that didn't make you fly out your chair at the offense [22:49:18] you have to pick your battles :) [22:50:16] actually I think ?: is a nice innovation, if it's used sparingly [22:50:53] it's equivalent to the Lua "or" operator, which can be used to good effect [22:51:03] the alternative could be next( $msleep ) ? current( $msleep ) : 1000, which is less elegant [22:51:28] so I will just read ?: as "or" [22:51:35] "lua or" [22:53:17] it's a bit weird that it's documented as a passing note in the section on ternary operators [22:53:43] maybe it is really treated like a ternary operator in the PHP compiler, who knows [22:53:50] the PHP compiler is weird [22:54:29] no doubt it works with a space in it [22:55:02] actually, Python is like this too with "or" [23:18:31] TimStarling: yeah, I can't tell what that $this->clear(); is actually accomplishing in WikiPage [23:19:00] it probably dates from 2002 [23:20:20] and it's only called form ?action=purge and API purge [23:20:40] actually action=purge was only introduced in 2006 [23:21:47] and it wasn't there at the time [23:25:12] TimStarling: https://svn.wikimedia.org/viewvc/mediawiki?view=revision&revision=79116 [23:25:53] right... [23:26:23] "$this->mTouched = wfTimestampNow();" would be playing safe [23:26:42] with $this->clear(), you don't know what you're going to get next time you call getTouched() [23:30:05] so, everyone already knows about git new-workdir (https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir) and i'm just late to the party, right? [23:32:47] TimStarling: https://gerrit.wikimedia.org/r/#/c/57217/ [23:33:04] I saw [23:33:28] want me to merge the onTransactionIdle thing now? [23:34:04] or whenever :) [23:35:09] oh, there is still that inline comment [23:35:26] can be fixed in a separate commit though [23:35:50] * AaronSchulz didn't notice [23:36:22] gerrit is pretty good at hiding comments [23:39:02] why is that page info thing in there? [23:39:40] hm? [23:40:33] ori-l, I didn't know about that... thanks [23:40:41] just wondering why Title::invalidateCache() is doing things that aren't in the doc comment [23:42:01] the HTMLFileCache::clearFileCache() call is redundant with some callers [23:42:02] you know this is MediaWiki code right? [23:45:40] yeah, it would be Tyler wouldn't it? [23:46:06] I don't know why everyone was so keen to give him +2 rights [23:47:21] I think people thought he was a tough reviewer by giving lots of things -1 [23:47:30] lol [23:47:36] so no one though there would be any risking of bad things getting merged [23:47:47] you saw the !votes for that on mw.org right? [23:48:34] briefly [23:49:11] anyway, I didn't feel strongly about it and didn't comment, and I don't see any new difficulties arising [23:49:26] *no one thought [23:49:42] * AaronSchulz feels the need to correct obvious typos way after the fact sometimes [23:52:05] TimStarling: the main problem is excessive use of -1 (which anyone can do anyway), I haven't seen any bad +2's from him, and the -2's that I saw looked fine [23:52:41] my problem is just that he doesn't seem to know very much about mediawiki [23:53:11] But but but... The community! [23:53:11] and I think +2 rights should have something to do with some kind of skill or experience [23:53:41] and not just "someone who merges a few things and comments on lots of stuff"? [23:54:06] I could see it as either, though I thought we were leaning towards the later [23:55:03] The former institutionalizes the "established members/old hands" a bit more, which might be fine [23:55:11] * AaronSchulz doesn't really have strong opinions on this