[00:03:25] grants look fine [00:03:28] except this one: [00:03:31] Grants for wikilytics@%: GRANT SELECT ON `%wiki%`.* TO 'wikilytics'@'%' [00:04:17] and research and globaldev [00:04:20] all miss wiktionary [00:06:27] i guess no one in globaldev has ever tried looking at wiktionary [00:25:47] TimStarling: it seems like mw5/mw16/mw1 are pulling all the weight [00:25:52] don't way have more boxes? [00:26:04] *we [00:26:17] they are job runners? [00:26:25] mw1-16 [00:26:34] and maybe some more [00:26:43] notpeter: right? [00:30:13] mw2 just has a single itwikisource process [00:30:25] which has been running for 3 days [00:30:36] # mw1-16 are application servers for jobrunners only (precise) [00:30:51] from puppet, so those should be doing stuff, 5 procs each [00:31:03] TimStarling: LST bug? [00:31:13] but isn't there a timeout? [00:31:30] anyone currently deploying anything in this previously unscheduled window? if not, fundraising is pushing a CentralNotice update [00:31:41] there's no timeout, it just checks the maximum time after each job finishes [00:32:01] so this LST bug is fixed? [00:32:12] yes, but old jobs could still be running maybe [00:32:25] the one that made the main page so slow it timed out [00:32:50] * AaronSchulz has a deja vu moment [00:33:31] Something changed in the Matrix? [00:33:37] TimStarling: are you killing some procs? [00:33:44] I'll fix them [00:36:14] !log killing long-running runJobs.php processes affected by LST bug [00:36:22] Logged the message, Master [00:38:05] TimStarling: heh, if a child doesn't finish the parent gets stuck right? [00:38:14] * AaronSchulz remembers talking to roan about something like this [00:38:31] Yes, that's right [00:38:40] The children theoretically run for up to 5 minutes [00:38:54] But that assumes the jobs are short [00:39:08] what if they hang for ages? [00:39:11] If the jobs are long, it's possible for it to check the time, see it's only been running for 4m59s, then embark on an hour-long reparse [00:39:27] fixed [00:39:35] jobs were running for 3 days [00:39:39] not 4m59s [00:40:15] What I meant was, as long as the lifetime of the process is <5m , it will feel safe to start doing another job [00:40:21] That job itself might take 3 days, yes [00:46:59] robla: well that original problem in bug 42614 I can't reproduce, and the wmf think is fixed [00:47:13] *thing [00:47:46] probably delayed affect from lst bug or something [00:51:30] TimStarling: runJobs really needs to truncate params [00:51:44] I'm saying translate notification emails in here ;) [00:53:49] okay, fundraising is done with CentralNotice, the rest of the slot is free [00:54:08] for anyone who likes 5pm deploys [00:54:22] :-) [00:54:47] we don't mind since we work late and are never far away during the fundraiser [00:58:41] preilly: can i PM? [01:01:14] AaronSchulz: did this get better because of something you did, or did we plateau for some other reason? http://ganglia.wikimedia.org/latest/graph.php?r=day&z=xlarge&c=Miscellaneous+pmtpa&h=spence.wikimedia.org&v=506&m=enwiki_JobQueue_length [01:01:50] (magically getting better right at 0:00 UTC screams "cron job", but maybe that's just coincidence) [01:02:09] did you see the backscroll? [01:02:30] tim kicked the runners (at least one was stuck on itwiki for 3 days) [01:02:34] * robla looks now [01:02:37] *itwikisource [01:02:52] only 3 boxes were running anything at all [01:06:03] !b 42614 [01:06:03] https://bugzilla.wikimedia.org/show_bug.cgi?id=42614 [01:07:43] AaronSchulz: yup, ok, I'm convinced. obviously, we should keep an eye on it, but it has all outward signs of being fine now [01:12:34] pgehres and all, E3 would like to sync-dir E3Experiments, may we? [01:12:50] we are done, all yours AFAIK [01:14:03] pgehres thanks indeed. BTW I don't see fundraising deployment windows in the WMF Engineering calendar, are they unscheduled 24x7 [01:14:30] we don't have a pre-defined window [01:14:56] when we need one, we generally find an open slot and add ourselves to http://wikitech.wikimedia.org/view/Software_deployments [01:17:43] ori-l: sure [03:45:48] Hello. [03:45:59] I think page moves are leaving two newlines below the redirect code. [03:47:14] Yeah, seems so. [03:47:35] https://test.wikipedia.org/w/index.php?title=Some_page_title&diff=152897&oldid=152896 [03:48:59] Oh, it's documented. [03:49:01] Go figure. [03:54:31] Susan: what doc? [03:55:19] https://bugzilla.wikimedia.org/show_bug.cgi?id=42616 [03:55:27] Bug 42616 - Post-page move redirects contain two newlines below redirect code [03:56:35] you mean reported not documented? [03:56:43] i thought you meant it's intentional [03:56:58] It's documented in Bugzilla. [03:57:13] But sure, reported also works. [03:57:54] i was think e.g. you found something on mediawiki.org that said it should be that way [03:57:58] Hmmmm. [03:58:12] thinking* [03:58:13] I could create a panic about this bug to get it resolved faster. [05:02:35] !log revision-locked payments1004 to 4c15a56c46bf5, all other payments hosts updated to ec2a05d768355 [05:02:45] Logged the message, Master [05:04:02] K4-713: how does one implement a lock? [05:04:14] Ha. We have a thing. [05:04:46] are you guys joining the salty party? maybe not until february i guess [05:05:15] I haven't even really thought about... +3 weeks from now. :) [05:05:26] and i guess you'd need your own master [05:10:18] Yeah, as far as I know, we're not going that direction. It would probably need a lot of special CR for PCI compliance, for one thing. [05:11:02] We have to be pretty picky about what we install. [05:11:27] 3rd party audits can be painful. [05:11:35] But, Jeff would know more about that. [05:11:48] He's usually the one taking most of that pain. [05:17:42] huh, is somehow changing the formatting of the bugzilla maint notice? i think this may be the 3rd variation i've seen in the last few days [09:51:22] what's the post-edit feedback information page on Meta aharoni mentioned on wikitech? [10:03:25] DanielK_WMDE: you're a good contact for wikidata projects on labs right? [10:17:02] apergos: for wikidata in general yes. for the labs stuff... not so much. Silke_WMDE is mostly working on that [10:17:25] ok [10:17:28] but i know we have problems with one of the instances... and can't log into it to fix it, due to ldap issues. [10:17:52] well there is one or a few that are cronspamming to the point where my mail agen tcan't filter fast enough [10:18:21] wikidata-dev7 and wikidata-dev9 at least [10:18:57] and some mail from wikidata@i-00000225 [10:19:17] so when they do have access, if they could put MAILTO for all the cron jobs that would make me very happy [10:19:41] it's a quirk of the labs setup that cron email goes to all of ops (smeday to be changed but takes some work) [11:24:41] Hi all. Is dzahn ever on IRC, and if so, under what nick? [11:28:44] Jarry1250: mutante [11:29:06] and he's almost permenantly on IRC [11:29:22] just not always there, obviously ;) [11:30:00] Reedy: Ah, that's who mutante is. Makes sense. [11:30:17] In fairness I used to know that. Funny how you forget these things. [11:30:18] Thanks. [13:35:13] nemo_bis: the jobs machines are doing things but the speed at which the job backlog grows increases [13:35:52] makes no sense [13:37:02] * apergos has a look at one of the job runners [13:39:38] Seddon: what's one of the wikis with a growing backlog? [13:39:58] apergos: en_wiki http://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=spence.wikimedia.org&v=506&m=enwiki_JobQueue_length [13:40:19] ok, let me see how that is [13:41:57] apergos: https://bugzilla.wikimedia.org/show_bug.cgi?id=42614 you should be aware of this bug tis related [13:43:09] earliest job in the table is 20121105012106 that's not too great [13:44:16] lemme read the bug report [13:56:09] well it generates no errors when I run nextJob by hand, I checked that first thing [13:56:13] and I see things moving through [13:56:23] if it's a slowness issue that's going to be harder [13:57:58] apergos: how would one notice if the problem was what niklas originally reported? [13:58:46] well I was looking at teh dashboard, I'd have to understand what is and isn't reported there [13:59:03] if it turns out all jobs are reported, we can wait for a full day to complete and look at it [13:59:28] https://gdash.wikimedia.org/dashboards/jobq/ [14:02:23] if it's only enwiki then I'm much less concerned, as long as we are gaining on the other wikis [14:02:38] because at some point we'll be caught up and then start making a real dent in the en wiki backlog too [14:03:40] frwiki is hugely backlogged. hm [14:05:20] if the initial observation by Niklas is correct, things will get exponentially worse on wikis with a big backlog [14:05:35] yep [14:07:34] fr wiki's eariest jobs are dated 20121107193607 [14:07:39] also none too great [14:08:15] !log job queue snapshot for bug 42614: Commons 112k, fr.wiki 4M, pl.wiki 21k, pt.wiki 65k, other tops 5k at most [14:08:25] Logged the message, Master [14:08:29] sloow [14:08:43] 4 million?? [14:08:50] yeah 4m [14:08:54] I said it was big [14:09:27] bloody hell [14:09:46] all the servers are hard at work according to the graphs [14:10:51] which still leaves room for some step being very slow as reported in the bug [14:12:05] it could even be that some particular type of job takes longer [14:12:13] than it used to [14:12:26] I guess we have no metrics for that [14:17:38] there was a time when job runners worked at 60 % CPU to catch up the backlog [14:18:46] e.g. https://commons.wikimedia.org/wiki/File:WMF_apaches_load_October_2010.png [14:25:52] I'm waiting to see if frwiki jobs ever get procssed (for refreshlinks2) [14:47:49] apergos, could the queues simply be purged? if there is a job thats clogging it up [14:48:36] They could [14:48:41] Then people complain [14:49:06] :P [14:49:20] Merlissimo: did you check how was the job queue on fr.wiki before your last template ns bot edits? [14:49:38] I see a few hundreds at the beginning of November but I didn't count them https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cial:Contributions&offset=&limit=500&tagfilter=&contribs=user&target=MerlIwBot&namespace=10 [14:50:10] I have been watching th table [14:50:35] my bot always check job queue before doing non included langlink edits in template namespace [14:51:01] but these edit were on included langlinks [14:51:06] Merlissimo: how can it? do you mean DB replag? [14:51:20] no job queue size using api [14:51:28] uh [14:51:31] [14:51:48] that's en.wiki [14:52:21] but it does not check if changed langlinks are inlcuded from subpage [14:53:17] so how much was the queue before you made your edits? [14:53:25] or are the two unrelated? [14:54:23] i'll check logs [14:55:09] but only for edit that were not done because of job queue are logged iwth job queue size [14:56:35] 50000 is maximum allowed size to edit template having langlinks [14:58:16] this was the last edit langlink on main template https://fr.wikipedia.org/w/index.php?title=Mod%C3%A8le:ICDO&diff=prev&oldid=85575958 , so size must have increased after this edit [15:01:11] highest value in nov was on nov 14th: Template namespace forbidden because of high job queue (539354) on frwiki:Modèle:Boîte Babel, but on nov 15th there is high job queue (56511) on frwiki:Modèle:Palette Angkor [15:03:18] on nov 21 th there is "high job queue (62736) on frwiki:Modèle:Palette Avions Klemm" and then raising [15:06:52] Reedy: is there a template in job queue you can identify as root cause? [15:07:20] No [15:07:23] I've got other stuff to do [15:08:03] ok [15:11:27] well regardless of all the other stuff, the fact is that frwiki's oldest job in the queu is still the same one as when I started looking... if it hasn't been dealt with in a day there's something wrong [15:11:48] * apergos will keep that window open and work on other things now [15:11:49] Nemo_bis: so nothing i can do about. [15:12:13] Merlissimo: I only asked you because you were likely to have some numbers [15:12:18] as you in fact did [15:13:13] apergos: thanks for taking a look at stuff :) [15:13:14] the one-day-peak on nov 14 is a but scary [15:13:39] bit [15:14:17] Merlissimo, the en.wiki job queue has been going up and down since september [15:15:35] this is more than just a regular blip :) [15:51:14] I would have expcted jobs to be first in first out (for a given wiki) [15:51:36] be that as it may, frwiki refreshlinks2 jobs run regularly (checked the logs) [15:52:08] and even some of the same page (different batches) ran a little while ago [15:52:55] so at this point either: something is slow or: something spiked the job queue enough over there that it's unlikely to catch up given our resource [15:52:56] ss [15:59:27] apergos, that seems odd even to someone as uninformed as I.... [15:59:52] well I checked the log entries [15:59:57] they don't lie, what can I do [16:00:06] I could read the code to seee how jobs are selected but I admit [16:00:19] that is way outside my actual work I should be doing... [16:02:08] I understand :) I am appreciative you even took the time to look at this :) [17:13:40] apergos: what fun stuff are you working on atm? [17:14:06] gonna install a 720xd when the mgmt console becomes avaiable [17:14:25] and taking a temporaryy "break" by working on a tool to help people with the new interwiki cdb file [17:14:42] for when they import the latest xml dump from whatever wiki and the interwiki table is empty :-D [17:14:46] what's up? [17:15:57] * AaronSchulz was just curious [17:16:18] I was looking at the job queue for about 5 secs but [17:16:30] it's not an obvious breakage [17:39:24] andre__: [18:14:45] Is https://gerrit.wikimedia.org/r/#/c/34964/ scheduled for merge and deploy in the next hours? [18:15:42] hi se4598 - lemme check [18:17:34] se4598: is there a bug in Bugzilla already? I know you can't check bugzilla right now because it's down for maintenance. You've seen https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes ? [18:19:21] i don't think so [18:21:06] take a look at that meta page [18:22:32] I think all what is nessesary is in the commit message [18:36:45] AaronSchulz: the job queue seems to have decreased a bit on the wikis with less than 100k jobs and to continue increasing on all the others (like Commons, en.wiki, fr.wiki) [18:37:06] sumanah: can you diff patches to commits? [18:37:22] do you mean, can I do it, or is it possible to do? [18:37:35] is it possible? ;) [18:37:50] yes, I believe so. it's in the Git documentation somewhere on mediawiki.org [18:38:08] giftpflanze: #mediawiki people can answer you [18:38:46] se4598: did you check that "requesting wiki configuration" page? [18:40:05] se4598: basically, we track that workflow through requests in Bugzilla. Once Bugzilla is back up I can check whether there's already a request filed for it there -- then I can file it (if it's not there) and push for it to get done. Is there particular urgency to get this done? [18:41:21] se4598, I'm not sure that the AFTv5 maintainers agree with deployments already, let me try to find a statement by them [18:42:17] se4598, quoting Fabrice from https://bugzilla.wikimedia.org/show_bug.cgi?id=31641#c6 : "At this point, I would not recommend deploying AFT5 on other production wikis, except for testing purposes. We are planning a big push on final feature development this month, and it would seem premature to deploy this beta version until it is complete. Better to wait a couple months and have a final version that we can support." [18:42:30] (that report is named "Article feedback extension at ml.wikipedia") [18:42:37] http://de.wikipedia.org/w/index.php?title=Wikipedia_Diskussion:Artikel-Feedback&diff=111254921&oldid=111251931 [18:43:06] Denis Barthel (WMDE) was talking with him yesterday [18:44:24] btw: i can't see the bug because of maintenance [18:44:35] se4598, yes, that's why I pasted the content here :) [18:45:27] so Fabrice Florin is aware of this project [18:47:03] se4598: ah, good. So basically it's likely the same statement as above - that he wouldn't recommend to deploy the current beta version, but that he won't stop you either :P [18:49:09] don't know how old the statement is, but i also know that big changes to AFT planned in january 13 and we still want it now [18:58:37] se4598, my statement from above was from a few days ago [19:01:00] oh, but we do it for max 0.1% of all articles as proposed by WMF and now we are waiting because we shift the start several times to now 2012-12-04 17:00 UTC [19:01:14] mutante: ping [19:01:30] Jarry1250: you know Zahn is in the midst of upgrading BZ right? [19:02:06] sumanah: I do now :) [19:02:10] andre__, the bugzilla maintenance - are you upgrading it to a newer version? [19:02:15] ah [19:02:29] heh sumanah you answered my question too [19:02:30] yes, trying (and partially failing) [19:02:32] (I knew Bugzilla was being upgraded. As for how it gets upgraded, that's all black box to me.) [19:02:36] hey all.. yes we do [19:03:05] we are looking at some minor issues now.. the version did already change.. the skin is not back yet [19:03:16] well I didn't think we could have any other maintenance on Bugzilla that would result in downtime, but was just checking [19:03:17] if anyone wants to lend a hand with the puppetization and the Debian packaging for BZ, Thehelpfulone now would be a great time to speak up [19:03:39] giftpflanze: Thehelpfulone might be able to help you with your Git question :) [19:03:48] pah I have no experience in either of those else I would help! [19:03:52] Thehelpfulone, I have some ideas for downtime without upgrading actually :P [19:04:58] <^demon> The skin breaks on every upgrade :( [19:05:10] <^demon> BZ doesn't like maintaining compatibility there. [19:05:15] so far I don't see big skin breakage [19:05:19] but I cannot really test yet [19:05:30] shut it down, can only access admin UI [19:05:30] <^demon> Maybe we'll get lucky this time :) [19:05:43] trying to sort out expected breakage [19:06:08] <^demon> Interesting--I can't login as admin :\ [19:07:55] ^demon, depends on the URL you try to reach. Try https://bugzilla.wikimedia.org/editparams.cgi [19:08:14] but it's weird, yeah. Like forced logout and stuff. [19:08:39] <^demon> Hmm, that url will work. But admin.cgi won't. [19:08:43] <^demon> Fun times. [19:09:36] ^demon, I know. It's weird (I cannot say "on crack" because I know its developers ;) [19:10:58] hi Raymond_ [19:17:00] betatesters welcome on bugzilla.wikimedia.org [19:17:19] I've removed the block, it's back again but it DOES need some more testing (I'm on it) [19:19:59] andre__: I can't log in; user or pass invalid [19:20:26] Damn. I have found one regression. Need to go back to closed mode one more time [19:20:35] okay [19:24:48] so looks like Bugzilla ate some cookies, but apart from one small regression it seems that we are fine. [19:24:56] rockin' - what is the regression? [19:27:31] Mmm, cookies [19:31:12] andre__, ..? [19:32:05] how does that bot work? Do I just write "!ask Krenair" ? ;) [19:32:11] what's the question? [19:32:17] What is the regression? [19:32:21] ah :) [19:32:43] regression: we did NOT apply http://pastebin.com/pE9r6exB for Bugmail.pm [19:32:59] Unknown Paste ID! [19:34:26] sumanah, andre__: https://bugzilla.wikimedia.org/show_bug.cgi?id=42693 [19:35:38] Hello se4598. [19:35:50] Krenair, eeks, sorry. http://pastebin.com/Ff0h5U0Q [19:36:27] se4598: andre__ is a little busy with Bugzilla migration. I will take care of your request if you wish. [19:36:38] s/migration/upgrade [19:36:56] Dereckson: I've just added a little of the relevant metadata to that bug [19:37:53] se4598: Matthias Mullie is handling it. [19:50:56] hi [19:51:26] Thank you to have joined #wikimedia-tech. I'm now going to invite Shuiab. [19:51:53] 20:21:14 -!- shuaib_ [~chatzilla@115.240.19.152] has quit [Ping timeout: 265 seconds] [19:52:05] He logged out 30 minutes ago, sending him a mail. [19:54:00] meganhernandez: hey, got a moment? [19:55:53] kaldari and ^demon you just gave me a good laugh thank you [19:56:30] uh I no longer understand anything in bugmail [19:56:51] <^demon> sumanah: Access to wikitech is Serious Business ;-) [19:57:07] Nemo_bis: There are clearer with an array. [19:57:18] I like them. [19:57:30] woah: On my dep watchlist: 1146: Table 'dewiki.aft_article_feedback' doesn't exist (10.0.6.65) [19:57:30] array? [19:57:53] Nemo_bis: "By default, bugmails (email notifications about changes to bugs) are now sent in an HTML format that is more readable than the old text format. Those who prefer the old text format can still choose it in their Preferences, however." [19:58:08] Pff, more readable [19:58:17] se4598: AFT is now working on de.wikipedia [19:58:30] oh you saw it [19:58:50] thanks for working on this, Dereckson! [19:58:54] but my watchlist is still broken and also some special pages are missing [19:58:54] it is a bug [19:59:24] No, this is a database deployment still to do. [19:59:31] sumanah: what were you quoting? done now anyway, thanks [19:59:50] marktraceur: indeed, how can it be more readable if I need two page down to read a comment? ^^ [20:00:03] well, see it as you want to [20:00:08] Nemo_bis: http://www.bugzilla.org/releases/4.2.4/release-notes.html#v42_feat [20:00:14] Nemo_bis: Not to mention parsing HTML in the process. [20:00:29] thansk sumanah [20:00:55] mlitn: ping, you're needed in #wikimedia-operations [20:00:59] can someone link the release notes from the notice at the top? [20:01:19] "new software version " is a nice label [20:01:19] sumanah: okay, thanks [20:01:24] mlitn: you just deployed aftv5 to dewiki? [20:07:48] hi sumanah [20:07:51] what's up ? [20:08:14] meganhernandez: - check out https://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013#Straw_Poll [20:15:06] cool, thanks sumanah . that's instead of the berlin hackathon [20:15:07] ? [20:15:07] [20:15:38] meganhernandez: yes. WMNL is doing it instead of WMDE [20:17:44] meganhernandez: so I thought you might want to sort of put that weekend tentatively on the calendar for your team to come visit [20:18:37] will do, that could be really good. thanks for looking out! [20:19:27] sure sure! and meganhernandez also check out https://www.mediawiki.org/wiki/Events#2013 -- Quim Gil in my group is encouraging more and more community tech events [20:19:59] wow [20:20:07] really neat [20:20:32] yeah! [20:20:49] he's in SF in case you want to meet with us while we're *both* here [20:27:44] meganhernandez: ohh you on IRC :-] *waves* [20:27:59] hello hashar [20:28:03] <-- that is Antoine [20:38:44] se4598: Does all work fine on the other extension pages? [20:38:44] hello to antoine [20:40:53] Dereckson: I see no errors [20:44:52] mlitn: Are you familiar with AFT? [20:47:31] se4598: I am [20:50:10] Why i have only empty feedbacks? that must be an bug [20:50:53] oh sorry, now i found some with text, strange [20:53:38] se4598: it was an issue related to cache, is no longer the cse [20:53:40] case* [20:58:28] mlitn: found the first layout-break: de-translation of articlefeedbackv5-form-unresolve is too long, see https://de.wikipedia.org/wiki/Spezial:Artikelr%C3%BCckmeldungen_v5/1-800_Vindication/23 [20:59:06] mlitn: can't see aft-boxes when not logged in? [21:00:38] sigh https://bugzilla.wikimedia.org/39773 is so annoying [21:06:17] saper, would you mind taking a look at https://www.mediawiki.org/wiki/Talk:Git/Workflow#git_review_broken_when_cloning_using_review_20995 ? [21:06:23] It's a potential issue with the review shortcut. [21:06:29] superm401: yes [21:06:39] saper, thanks. [21:13:58] fyi rebooting sockpuppet in 60 seconds [21:14:46] superm401: that's the problem with "review" shortcut [21:15:03] saper, it's a known issue? [21:15:43] superm401: git-review is not understaning this at all - this is a known bug https://bugs.launchpad.net/git-review/+bug/912125 [21:16:12] that's one of the issues I try to fix but the battle is uphill [21:16:32] saper, thanks. I'll fix the Git/workflow docs. [21:20:01] superm401: like, "not to use ssh aliases" :( [21:20:13] saper, yeah, the docs were apparently straight up wrong. [21:20:19] I removed the whole section: https://www.mediawiki.org/w/index.php?title=Git/Workflow&diff=613007&oldid=612940 [21:20:24] Let me know if I misunderstood. [21:20:41] superm401: I added it long time ago for people who don't want to use git-review (we didn't propose that at the time) [21:20:59] Oh, I see. What was used before? [21:21:04] it still works [21:21:09] of course [21:21:31] but with "git fetch gerrit refs/changes/AA/BBBAA/PP" [21:21:52] and "git push gerrit HEAD:refs/changes/BBBAA" or "... HEAD:refs/for/master" [21:22:12] Oh, okay. What about the change id? [21:22:27] How does the other way handle that? [21:24:42] [21:59:19] mlitn: can't see aft-boxes when not logged in? [21:26:56] se4598: denis_o: I think that is because that output is heavily cached - I'll look deeper into it soon, but I'm seizing the moment to do some more tests ;) [21:27:02] but i think atm it is good the way it is ;) [21:27:24] because of some bugs, including translation [21:29:28] superm401: if you have a hook (which you need to have for git-review too), it works [21:29:53] Right, I just knew git-review took care of the hook, so I guess you need to write/copy your own the other way. [21:29:53] superm401: git-review only saves you some typing at the cost of unexpected "user friendliness" that, for example, rebases your changes [21:30:19] yes, "scp :hooks/commit-msg .git/hooks/commit-msg" [21:30:31] that's what "git-review" does if it does not find one [21:31:11] which is buggy as well, because it does not work well with Windows (pscp + putty): https://bugs.launchpad.net/git-review/+bug/1024073 and https://bugs.launchpad.net/git-review/+bug/1024054 [21:31:15] :) [21:32:15] saper: git stuff without a shell that's already half linux is impossible anyway ;-) [21:32:54] valhallasw: yes, but it is easy to make it work with putty+pscp instead of those mingw ports; who needs two ssh agents [21:33:04] true [21:33:30] the 'putty suite' works surprisingly well [21:34:44] I prefer that [21:35:04] I don't even have cmdline ssh installed on windows (which I rarely use and never for MW development) [21:35:21] I've seen even patched pageant to work with SSH key on a smartcard [21:37:11] superm401: not sure if my answer on talkpage is clear? [21:46:08] I'm not going to use Windows here, but I had good results with mingw git in the past. [21:46:13] saper, yeah, it makes sense. [21:46:20] uh there's also a lot of nice stuff in this bugzilla update [21:46:33] I'm going to keep using git-review, but I get why you want the extra flexibility (and not dealing with bugs like this). [21:46:35] this is my favourite so far: Bugs: Local bug IDs are now valid in the See Also field. Adding such an ID will also add a reciprocal link in the other bug. [21:47:26] kaldari- So what's up with this css/ResourceLoader issue robla asked me to help you with? [21:48:11] anomie: I sent an email to wikitech with the details [21:49:06] kaldari- Copying those three css files from wmf5 back to wmf4 and deploying them? [21:49:20] superm401: I also SSH to gerrit directly, so having a shortcut "ssh review gerrit " is very useful [21:49:32] anomie: basically, we should go ahead and push the new css out to the wmf4 wikis today so we can hopefully avoid some of the formatting breakage from wmf5, due to server-side caching issues we've been seeing [21:49:50] Yeah, I'll keep it on my machine for that, but I don't think it's worth keeping in the docs just for that. [21:50:13] anomie: yes, what you said :) [21:51:26] superm401: :) you convinced me now :) [21:51:59] saper, alright, thanks for your help. [21:52:09] anomie: we need to make sure the only changes to those css files are adding the h3 selectors though, so we don't cause any other problems. [21:52:30] superm401: i only started to understand this whole gerrit mess after reading the "command line gerrit" article [21:52:34] kaldari- Looking at that right now, in a minute I'll have you check your email. [21:57:27] kaldari- Ok, check for a reply to that mailing list thread [21:57:37] thnaks [21:58:26] anomie: hmm, OK, I'll review those [21:59:07] anomie: I might just create a new changeset just for this fix to make things simpler. [21:59:30]