[00:15:12] I just totally screwed up all my changes in gerrit, can anyone help? [00:18:46] I noticed, kaldari [00:18:55] I'm afraid I can't help though [00:19:00] :( [00:19:29] But for the record, can you elaborate? [00:19:38] maybe something comes to mind [00:19:47] I guess I shouldn't have merged my old branch before creating my new branch [00:20:17] did you push it? [00:20:24] or just local [00:20:36] just local [00:20:44] did you commit it? [00:20:54] yeah [00:21:16] I guess I should have pushed the old changes before creating the new branch or something [00:21:28] frankly, I have no idea [00:21:41] you can do `git reset --hard (hash)` which will revert your current branch to that point in time, leaving no trace of what happened after [00:21:54] not sure if that is what you want [00:22:02] how do I fix everything on gerrit though? [00:22:23] Either new patch or abandon the changeset and start clean from current master [00:22:43] no, I need to get rid of the patches, not create new ones [00:22:52] the old ones were reviewed [00:23:20] you can't delete a patch set, but afaik the patch sets don't add up [00:23:34] only 1 is accepted eventually [00:23:35] so I have to get them all re-reviewed? [00:23:43] arg [00:23:52] no, only 1 patch set is reviewed [00:24:15] if there are problems, you amend the pachset locally and push it (which adds it as patch 2) [00:24:23] they should all have the same parent [00:24:28] (I think) [00:24:38] take a look at https://gerrit.wikimedia.org/r/#change,3890 for example [00:24:46] ok [00:24:51] patch set 5 was reviewed so I was all good [00:25:02] then I accidently resubmitted it under a new branch [00:25:10] so now it says the change is unreviewed [00:25:32] Indeed [00:25:42] You basically abandoned your change [00:25:48] and added a new one [00:26:14] so how do I get back to the reviewed one? [00:26:14] however if someone would've accepted Patch 5, then it was closed [00:26:22] hasher reviewed patch 5 but didn't merge it [00:26:43] so it was still open and you were able to add a new patchset [00:26:59] older patch sets can still be reviewed [00:27:06] they all have a review button [00:27:26] so you review patches, but merge changes, right? [00:28:07] every patch is a commit, a gerrit-change is one or more proposals for commits with comments [00:28:26] one of the commits gets moved into the history of the master [00:28:34] (or none, if the change is rejected) [00:30:09] it seems wrong that abandoning is at the change level, but reviewing is at the commit level. Shouldn't it be the other way around? :P [00:30:18] oh well [00:30:24] never mind what I said [00:30:29] review is also at a change level [00:30:38] only the last patch set can be rated/reviewed/merged [00:30:45] oh [00:30:49] the old patch set are for viewing purpose only [00:31:03] (and to use as base when ammending/comitting a variant) [00:31:19] so if you want path 5 re-up it [00:31:42] ok [00:31:50] i imagine that's easier said than done :) [00:32:22] Gerrit shows a Review button under each Patch set section, but except for the last one, clicking them only gives a comment area, not a merge/rate box [00:32:56] I don't know the commands [00:33:12] the `getting it local` commands are provided though [00:33:23] not sure which of "checkout pullcherry-pickpatch" [00:33:36] not sure which of "checkout | pull | cherry-pick | patch" you need [00:34:39] I'll see if I can figure it out from the docs... [00:34:50] wish me luck :) [01:11:43] New patchset: Diederik; "Disable GeoIP_cleanup() to keep compatability with GeoIP 1.4.6" [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/4068 [01:12:25] New review: Diederik; "Ok." [analytics/udp-filters] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4068 [01:12:27] Change merged: Diederik; [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/4068 [12:10:46] New patchset: Hashar; "tests builds now part of the main build" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4075 [12:11:17] New review: Hashar; "(no comment)" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4075 [12:11:21] Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4075 [12:37:02] New patchset: Hashar; "disable MediaWiki jobs based on subversion" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4076 [13:29:28] RoanKattouw: Hi [13:29:53] Hi [13:30:03] RoanKattouw: From the jsgrammer branch merge commit I wandered off into something and hoping you can clarify [13:30:09] ResourceLoaderModule::getFlipi [13:30:10] ResourceLoaderModule::getFlip [13:30:23] returns bool based on contentLang dir !== context lang dir [13:30:26] Yes [13:30:37] which is then used to decide wether to initialize cssjanus [13:30:42] I believe this is overridden in ResourceLoaderFileModule [13:30:44] with if content language of the wiki is ltr ? [13:30:56] aha [13:30:56] rtl, yes [13:31:03] right [13:31:24] ah, okay. only used when the origin is site [13:31:26] The reasoning here is that all other Module subclasses serve user-authored styles in one way or another [13:31:32] Exactly [13:31:49] Previously, all of those subclasses implemented that method the same way, so I decided that duplication didn't make sense [13:32:05] Now the default behavior assumes the origin is site or user, and origin=file is special-cased [13:32:11] Not sure if it makes sense in the base class for ResourceLoaderModule though, it assumes modules by default are created in the content language [13:33:08] Wait, what are you saying exactly? [13:33:26] That RLModule assumes that modules are written in the content language? And you think that's a good thing or no? [13:33:33] No, it's not a good thing [13:33:57] It's not causing an issue, but I think it's easy to fail in extensions when they create their own class [13:34:15] right now it's overwritten in core in all places it has to be overwritten [13:34:41] The alternative is to assume things are always LTR [13:35:08] I'd propose to move the gitFlip of ResourceLoaderFileModule to ResourceLoaderModule [13:35:13] I guess that's reasonable too [13:35:20] and overwrite it with a check against contLang if the module is site specific [13:35:24] Yeah, we can put it back the way it was about a year ago [13:35:30] oh? [13:35:41] Move getFlip from RLFM to RLM, and override it in all other subclasses [13:36:28] Why was it changed a year ago? [13:36:33] There are no direct subclasses of RLM in extensions, only of RLWM, I checked that a few months ago [13:36:36] To reduce duplication [13:36:52] ResourceLoaderUserCSSPrefsModule extends ResourceLoaderModule [13:36:58] right [13:37:53] wait, so it assumes ltr-wikis write stylesheets in an ltr manner? [13:38:11] even though the skin itself for ltr-wikis is flipped from rtl? [13:38:41] that makes gadgets less mobile, or am I looking at it reversed? [13:39:03] It assumes site content from an LTR wiki is written for LTR, and site content from an RTL wiki is written for RTL [13:39:15] yeah that makes sense [13:39:21] But this is not an issue for sharing Gadgets in RL2 [13:39:30] yeah I know [13:39:38] It's an issue for /copying/ Gadget CSS yes [13:40:12] copying, or forking [13:40:52] technically the same, except that copying will be discouraged from RL2 onwards [13:41:31] Im trying to figure out if as it is right now we're good in these 4 simple scenarios [13:41:41] gadget written with ltr on mind on an ltr-wiki and rtl-wiki [13:41:48] gadget written with rtl on mind on an rtl-wiki and ltr-wiki [13:42:06] /x on mind/ stored on an x-wiki/ [13:43:34] because user language does not affect skin direction, right? [13:44:00] Yes it does [13:44:29] it used to for a little while and then it (user lang skin direction) was backed out by you or Tim [13:44:35] Oh, wait, right [13:44:39] There were changes [13:45:09] which makes sense in a way, since the content inside the skin will be in the content language [13:45:29] so having skin in that direction is justified in a way, but at the same time not, since the int msgs themselves will be in the user lang [13:45:35] what was the reason it was backed out again? [13:45:56] Breakage related to mixed directionality [13:46:36] ah, right [13:46:51] maybe we can try again though, I think that might be fixed with robin's improvements in that area [13:46:55] mw-content-ltr etc. [13:47:15] on #content [13:47:50] Yeah the problem was mostly that Robin et al thought they had their bases covered, but they didn't [13:48:43] we we opted to have the ui messages partly broken due to inline rtl messages in an ltr container (and visa versa), instead of having page content broken [13:48:43] so we* [13:48:53] makes sense [13:48:57] Both are fixable I think [13:49:03] yep [13:49:05] Wait, yeah, you're right [13:50:23] so right now I think an LTR-user loading a RTL-based gadget from an RTL-wiki to an LTR-wiki, might fail if the gadget assumes that the skin direction matches the direction the css was flipped to (which is a reasonable assumption) [13:50:31] (right now, as in, Gadgets 2.0) [13:50:37] New patchset: Hashar; "Add up API testing" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4080 [13:50:55] I..... think so [13:51:02] because that LTR-user on the RTL wiki would not have the skin in LTR [13:51:04] New review: Hashar; "(no comment)" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4080 [13:51:17] I'll put it in the test plan [13:51:21] just in case for later [13:51:24] Yeah [13:51:28] New review: Hashar; "(no comment)" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4076 [13:51:30] Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4080 [13:51:31] Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4076 [13:51:34] We need to also closely compare these things to what would happen locally [13:51:55] If things are broken in the same way when the gadget is loaded locally by someone with a different UI lang, then it's not a regression [13:56:16] !b 19245 | RoanKattouw [13:56:16] RoanKattouw: https://bugzilla.wikimedia.org/show_bug.cgi?id=19245 [13:56:28] RoanKattouw: It says Gadgets 2.0 will fix that [13:56:30] why? [13:56:33] I can't recall [13:57:22] Krinkle: Because you can now have an internal ID/name that is different from the display name (in 2.0) [13:57:29] right [13:57:54] Hm.. [13:58:02] Gadgets already had ID/description seperation [13:58:12] Yes, but not ID/displayname separation [13:58:13] we introduced split of description in title+description [13:58:42] the ID is used in prefs table [13:58:45] *|files, loads MediaWiki:Gadget- as description message and Gadget- as prefname [13:59:02] (Gadgets 1.0) [13:59:43] Yes [13:59:53] But it will show on the prefs page as $id: $desc [14:00:01] As opposed to $title: $desc [14:00:09] In gadgets 1.0 it shows up as $descMsg [14:00:25] Id isn't used anywhere in the GUI other than mediawiki-namespace page [14:00:31] Hah, really? [14:00:47] but even then, the up_prop name is the Gadget-ID [14:00:50] Hmm, yes, you're right [14:01:00] In that case they can already fix their issue [14:01:09] Rename the gadget to have a less ridiculous ID [14:01:13] Right [14:01:17] Oh... [14:01:20] Now I see [14:01:32] we can (or should) enforce an ID length in the Gadget manager :) [14:01:41] Yes that was my next thought too [14:01:44] so it is fixed in that way [14:01:52] Well, will be [14:02:02] * RoanKattouw adds to TODO list [14:02:08] yeah [14:02:58] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Gadgets.git;a=blob;f=modules/ext.gadgets.gadgetmanager.js;h=a32c7586b0d9a0cd39a08442794e65f1b1866515;hb=RL2#l346 [14:03:10] I'll add a mexlength there tomorrow (need to finish something else now) [14:03:41] and of course in the backend as well [14:03:50] Yes, that's on my list [14:04:09] you could do that together with the additional validation of the page_title in general (to be a valid module name) [14:04:17] Yeah [14:04:19] would be in the same area I gugess [14:04:28] alright, thanks :) I'll get back to the testing ground now [14:04:32] Sure [14:04:49] Doing this in the frontend can wait until I've done it in the backend [14:04:53] I'll do that on Wednesday [14:05:07] ok [14:50:32] <^demon> hashar: I've added JenkinsBot, labsadminbots and l10n-bot all to Non-Interactive Users in gerrit. [14:50:51] <^demon> We've got too many bot groups :p [14:51:31] what about existing permissions ? [14:51:37] a [14:51:38] r [14:51:47] I think they were set per groups [14:51:55] <^demon> I didn't move the users. [14:51:59] <^demon> I just made the groups inherit. [14:52:36] <^demon> Non-Interactive Users contains (JenkinsBot, l10n-bot, labsadminbots) [14:53:57] is there anything special I need to do to setup git-review in a sub-repo of extensions? [14:54:24] I get OSError: [Errno 20] Not a directory: '/home/gabriel/src/mw/extensions/VisualEditor/.git/hooks' [14:54:29] ewwww [14:54:32] ^demon: ---^^ ? [14:54:46] <^demon> Sounds like something borked your .git/hooks. [14:55:01] cat ../../.git [14:55:03] gitdir: /home/gabriel/src/mw/extensions/.git/modules/VisualEditor [14:55:27] this is a subrepo in a full extensions checkout [14:56:26] populated using update-submodules.sh [14:56:38] <^demon> Ouch, no don't use that script. [14:56:43] <^demon> I need to delete that before someone else tries it [14:56:55] I used that too [14:57:03] To set up the l10nupdate checkou [14:57:05] t [14:57:11] I had to hack it to use https:// checkouts instead [14:57:23] But still run it as me, because it uses ls-projects which requires SSH auth [14:57:35] I changed the host name to use my ssh host alias [14:58:11] so apparently git-review expects .git for modules to be a directory [14:58:23] New patchset: Diederik; "Add support for variable log line length using the -n switch." [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/4086 [14:59:39] New review: Diederik; "Ok." [analytics/udp-filters] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4086 [14:59:41] Change merged: Diederik; [analytics/udp-filters] (master) - https://gerrit.wikimedia.org/r/4086 [15:00:11] ^demon: which is the recommended method to check out all extensions from git? [15:00:23] <^demon> There isn't yet. [15:00:35] <^demon> You can use one of the tricks people cooked up and posted to the list about. [15:01:02] so we'll have to individually check out extensions for now? [15:05:24] <^demon> For now, yes. I'm working on getting that meta repo going. [15:07:14] ok [15:09:20] New patchset: Hashar; "misc tests for MediaWiki" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4091 [15:09:38] New review: Hashar; "(no comment)" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4091 [15:09:40] Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4091 [16:02:00] hello [16:24:36] New patchset: Hashar; "repair MediaWiki jobs dependencies" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4101 [16:24:54] New review: Hashar; "(no comment)" [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/4101 [16:24:56] Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/4101 [17:16:28] hello all! [17:16:31] 20% checkin. [17:17:17] * sumanah looks at how our Monday people are all in Europe [17:18:21] I guess I should skip it then [17:19:29] :o [17:19:32] I'm here [17:19:57] hoi RoanKattouw_away: I forgot to schedule an event for the final AFT4 log fixes, ping me when you have time to go through them? [17:21:22] hi Reedy: I haven't heard from Howie/Fabrice on the Moodbar data clean up yet, I should get hold of them today [17:26:13] Nikerabbit: how's your day going? [17:26:46] sumanah: just got home in time from Berlin to eat and do i18n deployment [17:26:51] :-) [17:27:02] ^demon: can I get some time frames for fixes for the gerrit issues? [17:27:34] Nikerabbit: there are some changesets that have been waiting for a little while, like https://gerrit.wikimedia.org/r/3367 and https://gerrit.wikimedia.org/r/3754 ... can you review? [17:29:09] sumanah: I've been spending at least two hours a day to keep up with gerrit emails... it's just not possible anymore [17:29:12] <^demon> Nikerabbit: l10n-bot autoapproval is submitted to gerrit, hashar +1'd, waiting for Ryan to get back tomorrow to approve. [17:29:33] tomorrow? I thought today [17:29:50] <^demon> Oh today? [17:30:03] if it happens tomorrow I'm fine with that [17:30:25] if it takes one week more, then I'm going to do something [17:30:26] Nikerabbit: so you're not really here (in terms of 20% time) - got it [17:30:28] hey sumanah, [17:30:35] hi DarTar - I am just about to step into a meeting [17:30:51] sumanah: what you mean "here" ? [17:31:10] Nikerabbit: sorry, bad choice of words [17:31:37] Nikerabbit: I mean, I shouldn't talk with you about 20% time -- I said "our Monday people are all in Europe" and you said "I'm here" [17:31:37] np - I am trying to find a ref on the schedule for the WikiData part of the Berlin Hackathon, do you have a pointer handy? [17:31:47] DarTar: sure, will pm [17:31:51] thx [17:32:09] sumanah: sure you can, I'm just saying that it will take a while... tomorrow or mroe [17:32:30] Nikerabbit: ok [17:32:39] * sumanah goes to meeting [17:32:47] I've starred those changes [17:35:43] DarTar: Let's bundle them with the AFT5 deploy on Wednesday [17:36:12] DarTar: Speaking of which, I may be late to the AFT5 call today, could you tell Fabrice? The Wednesday deploy is good to go from my end, all revs are reviewed and merged [17:36:28] in a meeting - bbl [18:09:16] RoanKattouw_away: np - I'll tell Fabrice, do you think we can work on the final AFT4 log fixes (cookie suppression + additional data for all events) on Wed or is there any risk they may get postponed? I need to close the timeline for the analysis and I need to know when this data will be available [18:27:15] DarTar: It's not much code, I'll submit those fixes now [18:27:16] ish [18:27:16] After I write them [18:27:28] cool [18:27:56] the nasty one is the cookie, which apparently needs more testing [18:48:27] hexmode: lolz thanks for the update on 35616 [18:48:42] np :) [18:53:48] RoanKattouw: is this an ops, shell, or dev issue? https://bugzilla.wikimedia.org/34995 [18:57:40] * hexmode figures Reedy will be able to figure it out and gives it to him. [18:58:34] It's shell [18:58:59] Assign it to Aaron [18:59:57] Reedy: aaron un-assigned himself, but ok [19:00:10] hah [19:18:22] C is so lovelly language when it comes to working with strings [19:18:30] *such a lovely [21:45:22] Krinkle-away: ping [21:59:09] preilly: Yes ? [21:59:45] Krinkle: is there a way to remove a mobile from RL [21:59:55] ? [22:00:00] Krinkle: e.g, I want to remove the Vector css on mobile requests [22:00:20] No, and I'm not sure there should be [22:00:31] what is the problem you're trying to solve? [22:01:01] we want to use RL for MF [22:01:33] but, we don't want to load the vector css [22:02:11] preilly: Can you be more specific? [22:02:17] which of the three vector cases ? [22:02:31] MediaWiki:Vector.css, User:/vector.css skins/vector/*, ... [22:02:45] basically we don't want to load any of them [22:02:47] Isn't MobileFrontend a skin? [22:02:52] why would it load vector at all [22:02:53] Krinkle: no [22:03:00] Krinkle: it's not [22:03:26] Well, not knowing anything about MobileFrontend internals, I think it is overdue for it to be a skin [22:03:31] it's not even close to the vector skin [22:03:59] That will also solve some of the problems ahead with gadgets [22:04:02] yeah, I understand [22:04:08] users enable gadgets based on the skin configuration setting [22:04:09] etc. [22:04:14] I've got a version that is a skin [22:04:19] just not committed yet [22:04:49] the 3 vector css'es I mentioned are just the beginning, there is more. there is vector.js as well (3 times) and other modules and jquery-ui that has conditional submodules based on the skin [22:04:51] and gadgets [22:05:09] so definitely go for that, that'll solve a lot of problems you may not be aware of yet (and ofcoutse the problem you mentioned here) [22:06:25] Isn't MobileFrontend a skin? <-- This made me smile. [22:07:19] <^demon> Imagine a world in which MediaWiki shipped proper mobile support out of the box. That's our goal--one mobile gateway at a time :) [22:08:19] Imagine a world without Gerrit. (o; [22:08:48] <^demon> Nooooo. [22:08:52] <^demon> I love gerrit :) [22:08:56] Just out of curiosity, how tied to Gerrit is Wikimedia? [22:08:58] I mean, [22:09:12] once everything is gitted, can the UI be changed simply enough? [22:09:32] If Wikimedia decided to go with phanwhatever. [22:09:39] <^demon> In theory, yeah. But there are very specific requirements a gerrit replacement must satisfy. [22:10:05] <^demon> I'm not married to the idea of using gerrit if someone can point to or develop (and not abandon) a viable alternative. [22:10:06] Like being in PHP? [22:10:39] I was thinking of writing an essay on mediawiki.org titled "PHP preferred". [22:10:43] <^demon> Not necessarily. "Not being Ruby" is the only language constraint I know of. [22:10:48] Heh. [22:11:08] I guess it'd go on Meta-Wiki, not mediawiki.org. [22:11:44] Hi. What characters are allowed in uploaded file names? I've been searching but can't find anything on that topic. [22:15:38] https://meta.wikimedia.org/wiki/PHP_preferred [22:15:41] Joan: I know it's an extension, but extensions can provide skins (or should be able to) [22:16:02] Krinkle: The whole thing should be a skin, in my opinion. ;-) [22:16:05] That's why I smiled. [22:16:13] okidoki :) [22:16:31] Whether it's packaged as an extension or not is mostly irrelevant to me. [22:17:57] <^demon> Who was it who was saying everything should be an extension? [22:18:00] <^demon> Couple of months ago? [22:18:09] ^demon: what's the objection to Ruby? just curious. [22:18:12] Dunno. [22:18:23] Trevor has supported moving more shit to extensions. [22:18:30] <^demon> chrismcmahon: Bad memories. [22:18:32] But other than that, I haven't heard anyone really advocating for that. [22:18:50] ^demon: I'm new here, memories of anything in particular? [22:18:56] <^demon> chrismcmahon: The mobile gateway used to be in ruby. [22:19:15] ^demon: ah. I heard a rumor. [22:19:16] <^demon> And maintenance of that was a PITA from an ops and developer standpoint (really, there was only one developer) [23:14:22] Can somebody explain to me what enwiki-20120307-imagelinks.sql.gz contains? It's available on http://dumps.wikimedia.org/enwiki/20120307/ and its title is just "Wiki media/files usage records". Does it contain all the uploaded files actually used on the English Wikipedia, both residing locally and on Commons? [23:37:15] nois0x: no [23:37:35] It's a list of what images all the pages on enwiki link to/use [23:38:26] Reedy: that's what I meant. I meant if they contain the file names, not the actual files. [23:39:30] Reedy: do they also contain image file names referred to/used by User: pages or other special pages? [23:40:49] I'd guess so