[00:01:29] <^demon> Done [00:01:32] Thx [00:01:59] <^demon> yw [00:03:46] ^demon: Hm. looks like it is still working. Not sure what it thinks it's doing, but I'll give it a few minutes [00:04:00] ^demon: btw, this worries me: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+is+hanging Looks like SNAFU to me. [00:04:00] <^demon> Yeah, it usually takes awhile to come up completely :\ [00:04:03] <^demon> Tons of jobs. [00:04:31] If jmap -heap and jstack are part of regular procedure to get it to restart.. [00:06:37] <^demon> I don't have full root here. [00:06:43] <^demon> I can't seem to do it as jenkins [00:07:02] ^demon: Then how did you do it? [00:07:14] Oh, of course. [00:07:22] I should've known that sudo command was whitelisted [00:07:30] I could've done that myself. [00:07:31] <^demon> :) [00:07:36] <^demon> Yup [00:07:57] $ sudo /etc/init.d/jenkins status [00:07:57] 1 instances of jenkins are running at the moment [00:07:58] but the pidfile /var/run/jenkins/jenkins.pid is missing [00:08:03] ^demon: What did the restart command give you/ [00:08:06] Any errors? [00:08:17] <^demon> * Restarting Jenkins Continuous Integration Server jenkins [ OK ] [00:09:44] tailing /var/log/jenkins [00:10:14] ^demon: Did you do something just now? it went from "busy" to 503 unavailable just now. [00:10:28] <^demon> Yeah, tried restarting [00:10:33] Again? [00:10:35] <^demon> Since it was obv. hung [00:10:35] OK [00:10:53] $ tail -n100 /var/log/jenkins/jenkins.log [00:11:21] nothing out of the ordinary [00:11:24] crappy loggign [00:11:27] not enough detail [00:11:33] <^demon> Yeah, that's not it [00:13:54] !log payments cluster updated from 22943dc28 to d3954768e4dd [00:14:34] <^demon> RoanKattouw: Could you give a hand? [00:14:37] <^demon> We're kinda stuck. [00:14:43] ^demon: What's up? [00:14:51] <^demon> https://integration.mediawiki.org/ci/ [00:14:53] <^demon> stuck there. [00:15:13] <^demon> Wanted to try jstack or jmap to see what's eating jenkins, but I'm not root here. [00:15:16] Their manual has an enty on it but no solutions: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+is+hanging [00:15:20] <^demon> (Antoine's not around, late for him) [00:15:41] Checking jenkinsci-users mailing list for past reports [00:15:58] Looking [00:16:01] gallium, right? [00:16:04] Yes [00:16:05] <^demon> Yep [00:16:36] One person solved it by updating jmdns: https://groups.google.com/d/msg/jenkinsci-users/XT7SnkEPzWE/B1WnjTn7fk8J [00:16:39] could be unrelated though [00:16:50] Jenkins is using 12% of the CPU [00:17:01] It's a fairly generic error, sort of a catch all for anything that goes wrong in hte backend without a stacktrace (yet). [00:17:38] RoanKattouw: Yeah, I noticed. Lots of memory too [00:17:46] Running jstack [00:17:54] 6G vmem, and 22% mem [00:17:55] With -F [00:19:05] <^demon> Nobody'd logged anything yet, did that for completion. [00:19:24] jstack -F still running [00:21:19] OK that didn't output anytthing useful [00:21:24] Let's do the other one [00:22:11] OK I don't understand that report either [00:22:14] Just restart it? [00:22:24] <^demon> Tried that twice. [00:22:41] ! [00:22:42] ok, you just typed an exclamation mark with no meaning in the channel, good job. If you want to see a list of all keys, check !botbrain [00:22:47] <^demon> a-ha. [00:22:48] lol [00:22:55] <^demon> It's probably the gc thing that page mentions. [00:22:56] ^demon: Shall I hard-kill the process? [00:23:01] Yeah most likely [00:23:29] <^demon> Hmm [00:23:30] <^demon> Came up [00:23:35] Oh hah [00:23:43] Indeed [00:24:05] Long live Java GC [00:24:09] (literally) [00:24:12] <^demon> http://p.defau.lt/?8sFJt2vuJ9cVuQhkjdTN7g [00:27:38] <^demon> Ok, I'm dipping out to get dinner. [00:38:53] New patchset: Krinkle; "Zuul status page: Consistently sort pipelines" [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58253 [00:39:03] Change merged: Krinkle; [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58253 [00:51:36] New review: Krinkle; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/57849 [00:53:17] Change merged: Krinkle; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/57849 [00:58:22] New patchset: Krinkle; "'check' pipeline: Don't run for VE team" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58258 [00:58:56] Change merged: Krinkle; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58258 [01:24:04] New patchset: Krinkle; "'check' pipeline: Don't run for VE team" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58260 [01:24:14] Change merged: Krinkle; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58260 [01:42:55] saper: You there? [05:37:47] New patchset: Krinkle; "Don't run check pipeline if the user is allowd test pipeline" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58273 [05:42:28] New patchset: Krinkle; "Don't run check pipeline if the user is allowd test pipeline" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58273 [05:46:47] Change merged: Krinkle; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58273 [07:17:48] New review: Hashar; "OH MY GOD. Why dont you keep the nice YAML list ?" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58273 [07:22:28] Krinkle|detached: yes :) [07:44:22] New review: Hashar; "Ok I got it, sorry for screaming :-D That is a ugly hack and might cause some maintenance headhache..." [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58273 [08:54:25] so [08:54:28] the tests are broken [08:54:31] heavily :( [08:57:02] that is going to be along day [09:29:31] New patchset: Hashar; "factorized PHPUnit publisher in a macro" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/58288 [09:30:27] Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/58288 [09:33:30] hashar, the idea of revoking +2 from humans sounds even less feasible today:) [09:33:39] yeah [09:33:45] that is a f**** stupid bug [09:34:01] the Git plugin seems to be build from master from time to time [09:34:02] :( [09:58:48] New patchset: Hashar; "mw core regression job for REL1_21" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/58289 [09:59:51] Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/58289 [10:01:20] New patchset: Hashar; "mw core regression job for REL1_21" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58290 [10:01:36] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58290 [13:06:13] Change merged: jenkins-bot; [mediawiki/tools/code-utils] (master) - https://gerrit.wikimedia.org/r/57827 [13:07:07] hashar, Nemo_bis - I'm not sure https://wikitech.wikimedia.org/w/index.php?title=How_to_deploy_code&diff=65946&oldid=65942 is the best advice. What if the local changes are security patches waiting for a formal release? Reverting those would be a bad idea. [13:07:15] too busy today sorry [13:12:44] Project en.m.wikipedia.beta.wmflabs.org-MobileFrontend-linux-firefox build #1: FAILURE in 39 sec: https://wmf.ci.cloudbees.com/job/en.m.wikipedia.beta.wmflabs.org-MobileFrontend-linux-firefox/1/ [13:20:43] Project en.m.wikipedia.beta.wmflabs.org-MobileFrontend-linux-firefox build #2: NOW UNSTABLE in 3 min 40 sec: https://wmf.ci.cloudbees.com/job/en.m.wikipedia.beta.wmflabs.org-MobileFrontend-linux-firefox/2/ [13:29:22] New patchset: Zfilipin; "Fixed Rake tasks so they reports failures properly" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58298 [13:43:44] New patchset: Zfilipin; "Update to Cucumber 1.2.5 since 1.2.4 was yanked" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58299 [14:08:08] haircut time, will be back later [14:44:15] New patchset: Zfilipin; "Upgrade to the latest stable version of Firefox" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58303 [15:30:43] New review: Cmcmahon; "fix rakefile" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/58298 [15:30:43] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58298 [15:31:19] New review: Cmcmahon; "cucumber 1.2.4 removed, go to 1.2.5" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/58299 [15:31:19] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58299 [15:32:03] New review: Cmcmahon; "update FF version" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/58303 [15:32:04] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58303 [16:13:29] Yippie, build fixed! [16:13:30] Project browsertests-linux-chrome build #270: FIXED in 10 min: https://wmf.ci.cloudbees.com/job/browsertests-linux-chrome/270/ [16:13:30] * zeljko.filipin: Fixed Rake tasks so they reports failures properly [16:13:31] * zeljko.filipin: Update to Cucumber 1.2.5 since 1.2.4 was yanked [16:13:32] * zeljko.filipin: Upgrade to the latest stable version of Firefox [16:24:19] Yippie, build fixed! [16:24:20] Project browsertests-windows-internet_explorer_8 build #265: FIXED in 9 min 40 sec: https://wmf.ci.cloudbees.com/job/browsertests-windows-internet_explorer_8/265/ [16:24:20] * zeljko.filipin: Fixed Rake tasks so they reports failures properly [16:24:21] * zeljko.filipin: Update to Cucumber 1.2.5 since 1.2.4 was yanked [16:24:21] * zeljko.filipin: Upgrade to the latest stable version of Firefox [17:23:54] saper: Hey, there now? I'm running into an obscure bug with bash color codes, and thought perhaps you could help out. [17:27:14] saper: https://integration.wikimedia.org/ci/job/mwext-VisualEditor-doc-test/92/console#footer [17:27:51] saper: https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/master/.docs/generate.sh#L25-27 [17:30:40] Krinkle: Hi. Do we have any existing code that fixes the problem in IE9 where .val() on an empty input with a placeholder returns the placeholder instead of an empty string? [17:30:59] jquery.placeholder in core doesn't seem to be able to do it. [17:31:23] aharoni: If anything, jquery.placeholder() might be the cause of that bug. [17:31:41] I'm having trouble believing that even IE would be stupid enough to have such a bug. [17:32:08] aharoni: I'm moving into a meeting now. Check back in 20 minutes? [17:32:26] OK [17:36:05] Reedy: https://gerrit.wikimedia.org/r/#/c/57532/1/maintenance/runJobs.php [17:45:40] Krinkle: checking out [17:46:43] saper: the "B)" sequence is coming out of nowhere. [17:47:03] "(B"* [17:50:01] saper: I should also add that when I run it locally on my Mac, I do not see the weird "(B" popping up [17:50:10] It appears to only happen on Ubuntu. [17:50:36] But that could be related to other environment settings that I might just have different on my Mac (I don't think its an Ubuntu bug) [17:58:06] Krinkle: tried with "TERM=dumb jsduck" ? [17:58:29] embedding terminal codes is evil, alas things like git are doing it :( [17:59:03] saper: What do you mean? The jsduck bin doesn't color code it [17:59:09] I do, on purpose. [17:59:19] ah I see now [17:59:19] I misread the rege [17:59:20] regex [17:59:23] k :) [17:59:24] thought you are removing it [17:59:32] please please don't [18:00:06] sequences are terminal dependent [18:00:15] Hence I use tput [18:00:26] instead of hardcoding it [18:00:33] and things like tput are not portable in terminfo (System-V and Linux) vs termcap systems (BSDs and MacOS-X) [18:01:05] Look, the color codes work fine in 100s of other jenkins jobs. Lots of stuff is using it. https://integration.wikimedia.org/ci/job/mediawiki-core-phpunit-misc/5224/console#footer [18:01:28] dozens of different applications, phpunit, jshint, etc. all working fine. [18:01:50] the jsduck one also works fine by default. But due to something I'm not going to explain now, we had to disable the built-in color coding of jsduck and do it afterwards. [18:02:12] I'm using the wrong codes apparently because I did it in a way that apparantly does not work well cross-platform. [18:02:18] you know I am from 1970s [18:02:21] Whereas all the other jobs are using codes that work fine everywhere. [18:02:31] So there is a way that at least gets it right on Jenkins. [18:02:45] And that's the only platform this has to work on. [18:03:15] do you have a file with the output? is it ESC ( B ? [18:03:44] I appreciate the input, but not color coding it isn't an option. I just like to figure out what is causing it to fail and fix it, since I know it can work. Lots of other Jenkins builds are doing it. [18:03:52] saper: I'll see if I can get a copy. [18:04:01] (I think it's spelt MAGENTA btw.) [18:05:15] Krinkle: do you have /etc/termcap on your Mac? [18:05:57] saper: No such file or directory. [18:06:53] solaris does not seem to know sgr0 [18:07:22] saper: the problem is in the first word of that statement ;-) [18:07:54] saper: generate.sh is given plain text (of that I'm sure) then it uses a regex to insert color codes retreived from tput. [18:08:22] the text does turn black after $NORMAL [18:08:31] Jenkins runs Ubuntu precise. [18:09:36] I understand that your problem is that "tput sgr0" just generates the code and not the effect intended? [18:09:44] saper: $ NORMAL=$(tput sgr0); YELLOW=$(tput setaf 3); MEGANTA=$(tput setaf 5) [18:09:46] saper: $ echo "Warning /bar/baz:123 Quux bla" | perl -pe "s|^([^ ]+) ([^ ]+) (.*)$|${YELLOW}\1 ${MEGANTA}\2${NORMAL} \3|" [18:09:52] Try that on your machine, what do you get? [18:10:35] saper: What happens is that $NORMAL inserts "(B" on Jenkins, and then it also does the right thing (resetting the color to black or white) [18:10:56] On any other system I tried it just resets the color without the weird "(B" [18:12:03] on my machine "tput sgr0" returns exit code 1 [18:12:39] saper: interesting [18:12:44] getting 0 here [18:12:59] logging into gallium.jenkins now [18:13:06] to run the above manualy [18:13:16] perhaps it is caused by jenkins not by the normal terminal there [18:13:20] do you know what is your $TERM ? [18:13:42] jenkins interpretes some of those codes apparently [18:13:46] Terminal.app on Mac sets it to rxvt. [18:13:51] but that is just me [18:13:54] Not Jenkins. [18:13:55] during a jenkins run [18:14:41] I believe it is dumb [18:15:06] Can $TERM affect what tput does? [18:15:48] that's what tput is for... [18:16:21] in order for this stuff to work you need a proper $TERM setting and a correct terminfo/termcap database [18:16:36] When I run the above code on the Jenkins server from my own terminal through ssh it works normally without the weird character soup [18:16:41] probably "dumb" definition does not know "sgr0" [18:16:56] But it does reset the color. [18:17:02] and exists non-zero [18:17:22] and it works fine in all other applications we use that output color codes [18:17:26] where do they get it from? [18:17:36] man terminfo [18:17:39] Afiak they hardcode the [[00m3,b stuff. [18:17:48] but jenkins apparently has something to interpret it [18:17:55] kind of own "terminal" [18:18:07] which accepts probably vt100, screen or xterm codes [18:18:11] or maybe ANSI :) [18:18:17] xterm and ANSI [18:18:42] They have a plugin that strips the color codes and re-inserts them as CSS during the output phase [18:19:37] The setting is "Color ANSI Console Output" [18:19:38] dumb|80-column dumb tty, am, cols#80, bel=^G, cr=^M, cud1=^J, ind=^J, [18:19:50] ^demon: https://gerrit.wikimedia.org/r/#/c/57532/ [18:19:51] that's dumb definition from bastion.wmflabs [18:20:02] and the ANSI color map Jenkins currently uses (in html generation) xterm. [18:20:12] is xterm* [18:20:19] ANSI console is not xterm afaik, some codes might be similar though [18:20:36] I think Jenkins refers to "ANSI" to mean colors in general. [18:20:45] Because the configuration is ansi_color_map=xterm [18:21:22] wait, is it sgr0 or sgr? [18:21:37] NORMAL=$(tput sgr0); YELLOW=$(tput setaf 3); MEGANTA=$(tput setaf 5) [18:21:57] ah sorry [18:22:42] Krinkle: is it this one? https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin [18:23:33] AnsiColor 0.3.1 > https://wiki.jenkins-ci.org/display/JENKINS/AnsiColor+Plugin [18:23:34] Yes [18:23:58] and it uses http://jansi.fusesource.org/ [18:24:33] Krinkle: I was talking about this: http://stackoverflow.com/questions/6366021/placeholder-in-ie9 . [18:25:43] aharoni: That stackoverflow thread doesn't describe any bug, afaik it is about the fact that placeholders are not supported in IE9 (not at all, not even a little) and want a way to simulate it. [18:25:58] aharoni: You told me you experience a bug where in IE9 .val() returns the placeholder [18:26:02] The first answer says something like it. [18:26:26] and it's not from the search box, but from another input. [18:27:09] I still don't know what the bug is. What do you expect it to do and what does it actually do? [18:27:26] Krinkle: seems to me that JANSI does understand only ESC [ codes, nothing like ESC ( that xterm uses [18:27:40] basically this: https://bugzilla.wikimedia.org/show_bug.cgi?id=47039 [18:29:10] Krinkle: https://github.com/fusesource/jansi/blob/master/jansi/src/main/java/org/fusesource/jansi/AnsiOutputStream.java I think this is the code that "reads" the codes [18:31:10] Krinkle: not sure that "sgr" and "sgr0" are very popular codes [18:31:24] What else would you use to reset it? [18:32:10] saper: https://github.com/fusesource/jansi/blob/master/jansi/src/main/java/org/fusesource/jansi/AnsiOutputStream.java#L395 [18:32:10] 0 = black [18:32:27] though that's tput setaf 0 [18:32:32] not tput sgr0 [18:32:42] but if I use that I will get black text in my black termina [18:32:55] reset is the appropriate code, not black [18:33:14] processDefaultTextColor [18:33:18] there it is [18:33:22] processAttributeRest [18:33:36] m0 [18:33:38] is that it? [18:33:54] I obviously have no idea what I'm doing here. [18:33:58] yes, "TERM=xterm tput setaf 0" should give you ESC [ 3 0 m [18:34:09] which this software can understand [18:34:25] Krinkle: well, that's why those fancy colors are PITA [18:34:48] people who understand termcap/terminfo slowly die out [18:35:07] linux kids just use xterm sequences, windows kids use ANSI.SYS codes [18:35:26] <^demon> And lazy kids live without colors. [18:36:00] batch kids [18:36:24] is there curses implementation for Java? [18:36:53] saper: So how would I use a color reset that doesn't cause it to be black in my own terminal and reset it without a character soup in jenkins? [18:36:57] <^demon> saper: http://sourceforge.net/projects/javacurses/? [18:37:22] I don't understand why putting colors in a batch job output (that needs to be processed sometimes by some tools) is useful [18:37:44] saper: No, quite the opposite [18:37:46] Krinkle: afair ANSI has no defined way to say "reset to what it was before" [18:38:14] <^demon> Also http://www.pitman.co.za/projects/charva/ [18:38:23] saper: There are lots of batch tools behind the scenes that are processed by other tools. The final proccessor is Jenkins after which the only user to ever see it is a user. [18:39:22] that is until we have artificial intelligence that can read arbitrary instructions from a 100 different build tools and automatically fix our builds, in which case color codes are the least of your worries. [18:39:23] <^demon> charva of jni linked with ncurses, heh [18:39:27] <^demon> s/of/is/ [18:39:48] ^demon: charva reminds me various 3270 terminal "overlays" I have to deal with recently [18:39:49] saper: Hm.. OK. [18:40:15] saper: I wonder then how (for example) the phpunit job manages to output a red sequence and then continue with black. [18:40:26] Krinkle: I'm sorry, but I really consider using colors stupid in anything that's non-curses application... [18:40:54] Krinkle: run it via "od" and see :) [18:41:06] It doesn't use the color code for black because when I run it locally it resets to white where it resets to black on jenkins (it resets like it should, not to what it was before but to the default color of the current terminal) [18:42:01] I don't know, I think last time I used phpunit it was b&w [18:42:12] <^demon> Well, I want failures to be orange. [18:42:17] <^demon> And pass can be purple. [18:42:25] you can filter the output via od/hexdump/... similar tool and see the codes generated [18:42:32] dinner [18:46:07] if ($this->colors) { [18:46:07] $this->write("\x1b[0m\x1b[2K"); [18:46:08] } [18:46:28] secret sause that PHPUnit seems to use (only if colors are enabled) [18:47:12] and it can generate HTML directly [18:57:59] Krinkle|detached: so ESC [ 0 m should do it for you :) [19:13:50] krinkle - the actual problem is this: https://bugzilla.wikimedia.org/show_bug.cgi?id=47039 [19:14:28] do you think that the placeholder plugin from the core can affect other s except the search box? [19:15:20] aharoni: The jquery.placeholder plugin is a generic jquery plugin that takes care of any form element with a placeholder attribute [19:16:26] Aha, so it may be the culprit. I thought that it only applies itself to one particular element on which .placeholder() ran. [19:51:58] mwalker: "I appreciate the concept of code review; but let's not do it on our release branch." [19:52:07] mwalker: That statement out of context looks very suspicious [19:52:17] hehe; yes [19:52:19] I believe you meant unit testing, not code review, right? [19:52:35] actually no -- the release branch should only ever be merged from master [19:52:42] so; in theory -- everything is already reviewed [19:53:08] unit testing might be good though for the release branch [19:53:11] And there are no patches or changes to that branch other than importing a snapshot of a different branch? [19:53:15] yep [19:53:20] What branch is that? [19:53:24] Does that branch have unit tests? [19:53:30] yes [19:53:31] (the source, if you will) [19:53:37] And they pass there? [19:53:42] That's... strange. [19:53:47] before we merge to release [19:53:50] Which branch are you syncing from [19:53:57] master [19:54:08] master is on 1.22, not 1.20 [19:54:24] I take it we're talking about fundraising's version of core right now? [19:54:31] https://bugzilla.wikimedia.org/show_bug.cgi?id=45520 [19:54:33] Yes [19:55:07] ah; yes -- we should probably close this and get hashar to re-enable tests [19:55:31] fundraising/1.20 is no longer used? [19:55:36] that's correct [19:55:41] we finished our migration yesterday [19:55:41] I see [19:55:48] what branch are you on now [19:55:55] 1.22wmf1 is the base [19:55:57] master? wmf branch? or another fundraising branch [19:56:00] OK [19:56:07] fundraising/1.22 is the actual name of the branch [19:56:13] So still a separate branch, but one that should be passing tests [19:56:14] OK [19:56:16] I'll check it out [19:56:17] yes [19:56:30] wow, that'll be confusing if you stay on that branch for very long [19:56:48] we will only be applying security patches [19:57:10] until the next time we upgrade [19:57:20] "1.21" is probably a more accurate name for it [19:57:40] the 1.22 cycle has barely started [19:58:06] so....if you stay on this branch for very long, you'll have all sorts of confusion about "what was in 1.22" [19:58:42] you could say the same about calling it 1.21 [19:58:45] its the same as wmf/1.22 except it doesn't have another suffix, instead it just re-uses it every cycle. [19:59:14] Krinkle: I'm betting they don't plan to stay current on 1.22wmf*, though [19:59:18] nope [19:59:47] but its git, so it's fairly easy to figure out what they're at [20:00:07] mwalker: the delta between 1.22wmf1 and 1.21 (as we'll be releasing) is much smaller than the delta between what will be 1.22 and 1.22wmf1 [20:00:14] or is it an orphan branch? [20:00:55] mwalker: Why are none of these changes in gerrit? https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=shortlog;h=refs/heads/fundraising/1.22 [20:01:08] It looks like they're only in git, gerrit has no knowledge of it. [20:01:53] Krinkle: because the point of gerrit is to do CR? and we already have established that CR here is not what we want? [20:02:18] Reedy: can https://bugzilla.wikimedia.org/show_bug.cgi?id=42649 be closed as FIXED now that your patch is merged? [20:02:25] mwalker: No, gerrit is to keep track of changes and verify who does what. [20:02:25] robla: that's a fair point on the naming -- but given that we've already done this does it really make sense to rename it? [20:02:40] mwalker: When you update it it to latest master or wmf branch that is a change [20:02:55] Krinkle: sure... but gerrit tells me much less than git log [20:02:58] or even git web [20:03:05] It *should* be trivial, but its not a single persons' decision to classify it as trivial. That's what review is for. [20:03:07] and I dont have to fight with it over rebasing and references [20:03:19] You can self-merge if you want, but don't push it straight bypassing gerrit. [20:03:32] mwalker: gerrit is on top of git, you can use git-log and all that as you like [20:03:43] as a matter of fact, you will have to use git command line [20:03:47] gerrit is not an alternative. [20:04:00] it manages it and allows one to keep track of what has happened. [20:04:20] Who created that branch and gave user rights to bypass gerrit? That shoudl not have happened, we don't do that anymore since we switched to git. [20:04:38] I created the branch -- the permissions were inherited [20:05:07] mwalker: on renaming, nope, but in the future, the best thing to do is to just use the actual branch name [20:05:12] I'm not sure what you mean by fighting rebases or references, but gerrit is irrelevant of that as far as I know. [20:05:43] Krinkle: that's a fair point, gerrit does what git review tell it to; and git review is what I typically am fighting [20:06:20] You push the change just the same, except that it is submitted to gerrit first so it is logged, then you submit it or have someone else submit it, that's your policy to choose. But if its not in gerrit it means nobody can see what fundraising is at and also it means we can't run tests because there is no place to leave that information. [20:06:22] robla: that's why I named it 1.22 and not 1.22wmf1 because they will diverge [20:06:37] mwalker: "git push gerrit HEAD:refs/for//topic" [20:06:42] mwalker: 1.22 is less accurate than 1.22wmf1 [20:06:47] no need for git-review if you can learn that one line [20:06:55] I've uninstalled git-review a long time ago. [20:07:06] well, I still have it, but I rarely use it. [20:07:07] Krinkle: I do know that one line [20:07:20] mwalker: but even with git-review, it does the same. [20:07:26] mwalker: what are you fighting? [20:07:37] the world [20:07:39] ;) [20:07:57] gerrit doesn't "do that git-review tells it to" [20:08:06] robla: perhaps a matter of taste; this tells me that it came from the 1.22 series even if it is effectively 1.21 [20:08:12] AaronSchulz: clearly [20:08:40] you push the change to gerrit instead of to the branch (e.g. git push to refs/for/ instead ) then on gerrit you click "Submit" and then it is pushed to the real branch. git-log should end up exactly the same. [20:09:01] Krinkle: at this point I'm tired of having this conversation; if you have a problem with how fundraising manages its code please talk to terry chay and katie horn [20:09:40] I think I won't. I'm just saying, if you do it this way, other tools cannot interact with fundraising (not wont, but cant) [20:09:46] if that is ok with you then I have nothing to say. [20:10:21] it's how we've been doing it in the past and it seems to be working -- certainly if we decide we need to use Zuul there will need to be changes [20:18:54] Yippie, build fixed! [20:18:55] Project browsertests-linux-firefox build #254: FIXED in 17 min: https://wmf.ci.cloudbees.com/job/browsertests-linux-firefox/254/ [20:18:55] * zeljko.filipin: Fixed Rake tasks so they reports failures properly [20:18:56] * zeljko.filipin: Update to Cucumber 1.2.5 since 1.2.4 was yanked [20:18:56] * zeljko.filipin: Upgrade to the latest stable version of Firefox [20:19:08] New patchset: Krinkle; "Disable Checkstyle reporter of JSHint" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/58330 [20:19:31] New patchset: Krinkle; "JSHint: No longer override reporter url" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58331 [20:19:59] Change merged: Krinkle; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58331 [20:20:04] Krinkle: What do you think of https://bugzilla.wikimedia.org/show_bug.cgi?id=47039#c3 ? [20:21:28] aharoni: Yes, that's what I said I thought it would be. [20:21:38] the plugin needs to remove the value on submission. [20:21:54] if it is still the untouched placeholder value [20:22:00] My current problem is not form submission, but using .val() [20:22:06] Same thing. [20:22:13] Retreival of the value, for submission or not. [20:22:15] Is replacing it with a whole other plugin too bold? [20:22:22] aharoni: btw, where are you calling .val() from? [20:22:28] what kind of code are you in? [20:22:53] It's an input box that filters translated messages. [20:23:58] in Translate, resources/js/ext.translate.messagetable.js [20:24:21] aharoni: The plugin you linked is unrelated to jquery.placeholder, it is a different plugin that does the same but in a different way. [20:24:29] I know. [20:24:39] It will have to be thoroughly reviewed and (if it doesn't have them alreayd) tests written. [20:24:48] also might have dependencies etc. [20:25:13] so it won't be very quick? [20:25:18] No [20:25:27] Oh well. [20:25:37] I mean, I won't have time for it this week. [20:25:47] But the sooner you submit, the better. [20:26:45] robla: thinking on the naming a bit further; I think the core issue is that it'll be much harder to patch fundraising/1.22 in the future because it's not really on any supported branch so it makes it harder for chris steib to backport patches -- so it sorta makes sense that we should actually base ourselves off of the official 1.21 release. Does that make more sense if we were to do it that way? [20:26:46] Project browsertests-windows-internet_explorer_6 build #240: FAILURE in 15 min: https://wmf.ci.cloudbees.com/job/browsertests-windows-internet_explorer_6/240/ [20:26:46] * zeljko.filipin: Fixed Rake tasks so they reports failures properly [20:26:47] * zeljko.filipin: Update to Cucumber 1.2.5 since 1.2.4 was yanked [20:26:47] * zeljko.filipin: Upgrade to the latest stable version of Firefox [20:27:34] mwalker: yeah, I'd suggest using the REL1_21 branch if you're willing/able to do a rebranch. csteipp: you concur? [20:30:36] robla / mwalker: Yep, that sounds reasonable. Until Mark makes the tarball next month though, I'm not sure if you want to track the wmf branch, or if you just want to keep up with the REL1_21 branch on a semi weekly basis. [20:32:52] REL1_21 should be the rough equivalent of 1.21wmf12, right? [20:35:23] Krinkle: ok, thanks [20:37:55] Yippie, build fixed! [20:37:55] Project browsertests-windows-internet_explorer_7 build #242: FIXED in 19 min: https://wmf.ci.cloudbees.com/job/browsertests-windows-internet_explorer_7/242/ [20:37:56] * zeljko.filipin: Fixed Rake tasks so they reports failures properly [20:37:56] * zeljko.filipin: Update to Cucumber 1.2.5 since 1.2.4 was yanked [20:37:57] * zeljko.filipin: Upgrade to the latest stable version of Firefox [20:41:04] hashar: ping [20:42:07] robla / csteipp: I'm thinking that I should just track the wmf releases until 1_21 is finalized [20:43:36] robla: yeah, it should be (roughly equiv to .21wmf12) [20:43:45]