[00:12:48] Reedy: thanks for the feedback on https://gerrit.wikimedia.org/r/#/c/35399/ [00:37:22] AaronSchulz: can you take a look at: https://gerrit.wikimedia.org/r/#/c/35399/4 [10:06:59] !g Ica11be186bd62eb154e1ebc400acb515c10fb65f [10:07:00] https://gerrit.wikimedia.org/r/#q,Ica11be186bd62eb154e1ebc400acb515c10fb65f,n,z [10:40:06] New patchset: Hashar; "'check' no more verify+1 on success" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35604 [10:42:13] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35604 [10:48:56] New patchset: Hashar; "lint check only V+0 on success" [integration/doc] (master) - https://gerrit.wikimedia.org/r/35605 [10:49:04] New review: Hashar; "doc update : https://gerrit.wikimedia.org/r/35605" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35604 [10:49:25] New review: Hashar; "update workflow flowchart according to https://gerrit.wikimedia.org/r/#/c/35604/" [integration/doc] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/35605 [10:49:26] Change merged: Hashar; [integration/doc] (master) - https://gerrit.wikimedia.org/r/35605 [13:37:13] New patchset: Hashar; "universal linter was not checking expected source" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/35614 [13:37:57] New review: Hashar; "This fix the universal linter which was not linting the correct path." [integration/jenkins] (master); V: 1 C: 2; - https://gerrit.wikimedia.org/r/35614 [13:37:57] Change merged: Hashar; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/35614 [13:41:54] Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/35370 [13:42:09] Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/35371 [13:42:44] New review: Hashar; "Although deployed, this is still a work in progress." [integration/jenkins-job-builder-config] (master); V: 0 C: -2; - https://gerrit.wikimedia.org/r/35372 [13:45:54] hm [14:16:06] hashar, ^demon - Did you see gerrit change 35540? I finally figured out how to get that merge into gerrit. Details at [[mw:Gerrit/merge submodule]]; the trick was fooling Gerrit into importing those revisions instead of trying to interpret them as new changesets. [14:17:07] !g 35540 [14:17:07] https://gerrit.wikimedia.org/r/#q,35540,n,z [14:17:11] anomie: hello [14:17:39] anomie: I haven't looked at it sorry :( been to busy finishing the new Gerrit/Jenkins workflow [14:19:26] hashar- No problem. Just pointing it out. [14:19:44] BTW, new workflow looks neat. [14:20:52] anomie: please say so on the thread :-] [14:21:01] I am not sure when I am going to enable it [14:21:12] I wanted to test it out on something else than mediawiki/core [14:21:25] but that need a bit of work to generate the related jobs for other repositories [14:22:01] anomie: so re: the merge commit. [14:22:13] anomie: I thought it got merged already by allowing you to forge commiter identities [14:22:57] hashar- Remember, we tried it and then it was trying to interpret every old revision as a new changeset, and (fortunately) complaining because the old revisions had no Change-Id [14:23:32] oh [14:24:23] So once I got a chance to look into it again, it seemed we'd need someone to import those revisions (unattached to anything else) bypassing the whole review process, so the merge could go through. Then I remembered the personal sandbox thing, and thought I might be able to abuse that to get the revisions imported. Which worked. [14:24:47] I think that's probably not too far from what you were suggesting originally about creating an orphan branch ;_ [14:24:50] ;) [14:24:54] if we merge https://gerrit.wikimedia.org/r/#/c/35540/ that would do it I guess [14:25:08] it seems to include the revisions from operations/mediawiki-multiversion [14:27:38] Hmm. I wonder if I can clean up that Gerrit display some by inserting a pre-merge revision that moves the multiversion files back into the multiversion subdir... Do you think it's worth it? [14:32:39] <^demon> I don't know how you can really merge the history, the more I think about it. [14:32:53] <^demon> You'd need to completely rewrite history to remove the submodule reference as well--which is evil. [14:32:58] <^demon> Really, let's just copy the files. [14:33:03] <^demon> This is ridiculous. [14:34:03] lol [14:34:44] ^demon- Not really. The history reflects the removal of the submodule and the connection of the history from the other module. [14:38:34] <^demon> After pulling that in, history looks funny :) [14:38:36] <^demon> git show 3d42fe3adf776a6a5ac04cadf47b589fc307b7d0 [14:38:37] <^demon> :) [14:39:22] <^demon> And before it, git show 274d2fd730ff834901be0a4557929a9b39634555 [14:39:25] <^demon> Oh well. [14:40:14] if we can keep the history, I am all for it. The merge commit of 35540 seems to do that pretty well [14:41:09] <^demon> Merged. [14:41:49] \O/ [14:42:07] no we can phase out / hide the old git repo [14:44:29] no / now [15:13:49] New patchset: Hashar; "Mw Extensions in Zuul" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35625 [15:14:02] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35625 [15:31:35] New patchset: Hashar; "experimental work on MediaWiki extensions" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/35372 [15:34:02] New patchset: Hashar; "MW ext LabeledSectionTransclusion" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35629 [15:34:15] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35629 [15:38:50] !g 932d548 [15:38:50] https://gerrit.wikimedia.org/r/#q,932d548,n,z [15:39:17] Reedy: with https://gerrit.wikimedia.org/r/#/c/35294/ on ext LabeledSectionTransclusion you have put the class in a file named LabeledSectionTransclusion.php [15:39:38] Reedy: I would like to use LabeledSectionTransclusion.php as an entry point for the extension and move the class again to LabeledSectionTransclusion.class.php which is done in some other extensions. [15:39:46] Reedy: does it make any sense ? :) [15:43:36] Sure [15:43:42] sending change [15:43:44] Feel free [15:43:51] I was just moving it per a TODO in the file ;) [15:43:56] Note, changing entry points is somewhat bad... [15:44:08] so make lst.php include/require the other for back compat [15:44:29] And if you move hte i18n file, it'll need a translatewiki config update (iIRC) [15:44:32] the entry point simply require lst.php and lsth.php [15:44:41] so my jenkins job can blindly require() that file [15:44:53] Reedy: https://gerrit.wikimedia.org/r/35631 [15:45:25] I'm not sure about loading lsth.pjp [15:45:30] lsth.php [15:46:36] Tpt: there :-) [15:47:22] Reedy: the reason to include both is so we can test the two parser suite [15:47:44] I don't have yet a system to gives Jenkins a settings file to the extension job [15:47:56] it is lamely looking for a file named the same as the ext :( [15:47:58] not ideal :( [15:48:38] hashar: I've closed my change. [15:48:47] noticed that, it was mostly like mine :-] [15:48:57] expect we usually have the class in a file named .class.php [15:49:00] not a big deal [15:51:59] hashar: I've just reopened the change and upload a patch set to wit .class [15:52:11] oh [15:52:12] well [15:52:14] I did that with https://gerrit.wikimedia.org/r/#/c/35631/ [15:52:20] let me look at your tpt [15:53:52] Tpt: reviewing [15:55:01] success! https://integration.mediawiki.org/ci/job/mwext-LabeledSectionTransclusion-lint/4/ [15:55:22] I can't +2 the change :( [15:57:44] hashar: I've made the +2. [15:57:47] nice [15:57:52] let s check the test [15:58:05] https://integration.mediawiki.org/ci/job/mwext-LabeledSectionTransclusion-lint/5/ [15:58:06] hmm [15:58:31] https://integration.mediawiki.org/ci/job/mwext-LabeledSectionTransclusion-testextensions/1/console [15:58:44] exception 'PHPUnit_Framework_Exception' with message 'Neither "extensions/LabeledSectionTransclusion.php" nor "extensions/LabeledSectionTransclusion.php" could be opened. [15:58:49] that is not really working as expected hehe [15:59:24] https://gerrit.wikimedia.org/r/#/c/35295/ [15:59:28] You broke my revision! :( [16:00:00] :/ [16:00:01] sorry [16:00:27] heh [16:00:35] it should be easily enough amended [16:00:36] Reedy: git show 9ea1256df101d15c6e59621e91cb580dee394dcb:LabeledSectionTransclusion.php > LabeledSectionTransclusion.class.php [16:00:38] that should do it [16:00:41] just copy the file over [16:00:50] Tpt: so the tests are running under zuul [16:01:04] Tpt: but I need to tweak the extension a bit more so it get a dummy test suite [16:01:36] hashar:Thanks! [16:02:42] I have opened a bug as a reminder https://bugzilla.wikimedia.org/show_bug.cgi?id=42505 [16:02:46] will hack that tonight I think [16:03:32] hashar: Ok. Thanks a lot! [16:04:53] New patchset: Hashar; "unsilent LabeledSectionTransclusion check" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35633 [16:05:02] Tpt: I am making jenkins to report whenever a PHP file is faulty [16:05:08] that would be a first step [16:05:14] the rest require a bit more work :( [16:05:23] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/35633 [16:06:41] Tpt: congratulations on being the very first commit to receive a Zuul notification :-] https://gerrit.wikimedia.org/r/#/c/35388/ [16:06:52] that change merges to latest master + lint :-] [16:06:55] \O/ [16:07:00] though tests are not run yet [16:07:24] I am out [16:07:29] going to get my daughter back home [17:33:05] RoanKattouw: thanks for taking a look at: https://gerrit.wikimedia.org/r/#/c/35399/ [17:33:45] preilly: Leaving some more comments [17:34:09] RoanKattouw: Okay great thanks! [17:35:34] lwelling: ping [17:35:57] preilly [17:36:26] lwelling: I hope that you don't mind that I added a patch set to https://gerrit.wikimedia.org/r/#/c/35399/4 yesterday [17:36:39] lwelling: I was attempting to kickstart the process a little bit [17:36:48] lwelling: I also added a ton of reviewers as well [17:36:53] I've left comments on utils.js [17:37:08] I don't mind, but I need to ask you about part of it preilly [17:37:13] I'm not gonna pick apart every last one of the 1500 lines, I have other work to do :) but hopefully that gets you started [17:37:38] lwelling: okay cool what part? [17:37:43] you added back GuidedTour.i18n.php [17:38:07] lwelling: yes [17:38:11] Which is not used. I'm guessing it is a subtle hint that it should be [17:38:31] but a couple of reviewers commented on the second half of the file [17:41:17] lwelling: you will need it for any string that the extension outputs [17:41:37] lwelling: Internationalization and localization is a bit part of everything that we do [17:46:19] preilly, I get that part, but there are some reviewer comments on the 'qqq' language. I can go looking on my own for a better skeleton file, assuming you are not attached to that part [17:46:45] lwelling: you can ignore the qqq comment [17:47:12] lwelling: that was ori-l with a microscopic nitpick [17:47:33] * preilly — likes AaronSchulz use of, "microscopic nitpick". [17:50:51] ori-l: Are you in the office? [18:48:57] preilly: no, WFH. what's up? [18:49:09] ori-l: nothing much [18:49:30] ori-l: I was going to just ask you to provide lwelling with some examples of how we do things with extensions [18:49:42] ori-l: to speed up his learning curve in mediawiki [18:50:18] ori-l: lwelling is a solid PHP developer and MediaWiki can have some uniqueness to it [18:50:28] NO UNIQUENESS [18:50:31] assimilate! [18:50:46] i'm j/k [18:51:08] examples of best practices, or examples of things that are unusual and neat? [18:54:08] tbh I'm mostly good with assimilation. Consistency is a good thing. Of course there's a fine line between consistent and propogating a historical quirk forever because nobody ever got around to breaking the chain [18:56:23] don't look at me, i'd replace PHP altogether if i could [18:56:28] lwelling, ori-l: I'd like assimilation and consistency with an eye on NOT propogating our historical quirk [18:57:09] s [19:08:29] preilly: btw, http://www.hashicorp.com/blog/announcing-hashicorp.html [19:18:21] ori-l: yeah, that's good news for the Vagrant users out there [19:42:51] how quick are such changes deployed onto Wikimedia cluster? https://gerrit.wikimedia.org/r/#/c/35675/ [19:43:35] wizardist, it has to be approved into core before that can happen [19:43:45] Krenair: I know [19:44:08] <^demon> After it's merged, it'll go out sometime in the next 2 weeks, when the next release branch is cut. [19:44:10] The schedule is at https://www.mediawiki.org/wiki/MediaWiki_1.21/Roadmap [19:44:14] ok, that's good [19:44:15] <^demon> Unless it's specifically backported to the release branches. [19:44:37] because some half a year ago I was said namespace changes are deployed in about 2 years later :) [20:04:05] New patchset: Jeroen De Dauw; "re-enable EP extension now including cldr" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/35686 [20:08:45] hashar: https://gerrit.wikimedia.org/r/#/c/34720/1..2/bin/wmfgrunt [20:08:49] hashar: $PWD ? [20:09:12] Oh.. [20:09:31] nvm [20:09:51] Krinkle: hello :) [20:10:32] hashar: btw, don't forget to set a topic next time :) [20:10:41] and do we want to keep /bin/grunt ? [20:10:51] a topic ? [20:10:55] !g 34720 [20:10:55] https://gerrit.wikimedia.org/r/#q,34720,n,z [20:11:07] Yes [20:11:09] ah a topic branch, well hmm [20:11:15] most of the time I forget about it :-] [20:11:31] New patchset: Hashar; "WMF wrapper around grunt" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/34720 [20:11:40] Krinkle: you can reapprove [20:11:46] Change merged: Krinkle; [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/34720 [20:12:02] Krinkle: well /bin/grunt is not doing any harm we might keep it around :-] [20:12:06] symlinks are cheap [20:12:08] Well, whether you do it locally is your business. But do submit a topic [20:12:18] will try [20:12:26] e.g. git push gerrit HEAD:refs/for/master/topic-name [20:12:34] that's what I do when I don't have a topic branch [20:12:44] I often do that when merging to rel branches in mediawiki core [20:12:56] <^demon> In master, you can edit topics from the gerrit UI :) [20:13:07] <^demon> (And commit summaries) [20:13:10] git co REL1_20; git cherry-pick ..; git push gerrit HEAD:refs/for/REL1_20/ [20:13:13] <^demon> No need to re-push. [20:13:22] <^demon> Life is great in master. [20:13:25] \O/ [20:13:37] ^demon: until build scripts start to use commit message and don't get new patch event [20:13:37] lets be brave and start using gerrit@master ! [20:13:51] e.g. jenkins [20:14:01] <^demon> hashar: We're going to :) [20:15:19] <^demon> Krinkle: It would get patchset-created on editing the commit summary -- you have to make a new patchset on that. [20:15:29] <^demon> Editing the existing patchset would change the sha1 :) [20:15:43] * RoanKattouw notes git review -t topicname also works [20:15:45] ok [20:15:57] * ^demon notes that git review is a flaming pile of donkey poo. [20:16:04] * Krinkle agrees [20:16:29] at least, whenever I use it (other than for pulling down changes by change id) I get into a conflict with it. [20:16:49] yes, yes it is (which is another reason I don't use it) [20:16:52] <^demon> I don't use it for pulling change id's either. I'm prefer cherry picking :) [20:17:27] cherry-picking on what? that would rebase the commit [20:18:05] <^demon> Depends on what I'm going. If I don't want to rebase I'll just reset back to the change's head. [20:18:18] <^demon> *doing [20:18:22] <^demon> I really can't type today. [20:18:33] <^demon> This NPE is annoying the crap out of me. [20:18:40] right, git checkout -b review-stuff [20:19:48] <^demon> In master, you can edit topics from the gerrit UI :) [20:19:50] hm? [20:19:56] <^demon> In gerrit's master. [20:20:03] <^demon> You can edit the topic from the UI. [20:20:11] topic = commit summary? [20:20:16] / commit message? [20:20:21] no [20:20:25] <^demon> No. The topic. [20:20:26] topic is topic [20:20:31] <^demon> You can *also* edit the commit message. [20:20:33] <^demon> But they're two things. [20:20:42] topic is usually the local branch name of your change set [20:20:45] <^demon> If I could fix http://p.defau.lt/?dITooqUYes3xJlzfrIlgaA, we'd be one step closer to using master. [20:21:00] Oh, of course. [20:21:05] java stacktraces remind me of java. [20:21:10] that's usually not a good thing. [20:21:51] ^demon, so, who can? Owner of the change + repo owners? [20:22:00] <^demon> Yes. [20:22:04] Anyone able to upload patch sets? [20:22:06] ok [20:22:12] <^demon> Actually, I'd need to check. [20:22:20] <^demon> "Anyone able to upload a patch" would make more sense. [20:22:28] <^demon> Since you could easily edit the topic that way ;-) [20:22:42] <^demon> That's what I did for Restore awhile back. [20:25:49] <^demon> Krinkle: Long stacktraces are long :p [20:27:34] ^demon, uploading a patchset to an abandoned change restores it? [20:29:07] <^demon> Krenair: No, change is marked as "closed" -- but nothing keeps you from just submitting it as a new change. [20:29:24] <^demon> So it made more sense to tie the "Restore" button to "the ability to make a new patch" since that's what's really important. [20:29:29] <^demon> As opposed to being the change/repo owner. [20:29:42] I see, that makes more sense [22:33:00] New patchset: Hashar; "wmfgrunt now support spaces in paths" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/35809 [22:33:55] New review: Hashar; "Saper comments have been made post merge, his changes are in https://gerrit.wikimedia.org/r/35809" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/34720 [22:35:02] New review: Hashar; "Good to me, merge whenever needed :-]" [integration/jenkins] (master); V: 0 C: 2; - https://gerrit.wikimedia.org/r/35809 [22:51:08] AaronSchulz, are you the right person to talk about job queue? [22:53:35] maybe, depends what [22:53:46] MaxSem: if you discover that anyone else is, please do add them to https://www.mediawiki.org/wiki/Developers/Maintainers :-) [22:54:14] * apergos lurks [22:56:08] AaronSchulz, I was wondering how stable it is these days, how often do enties get lost due to errors/whatever [22:57:16] MaxSem: that reminds me I should set claimTTL [22:57:43] claimed but unfinished jobs just set there and get pruned after time without that set [22:58:05] with claimTTL they get retried up to a few times and then sit and get pruned [22:58:19] ooh, that would be nice [22:59:00] * MaxSem recalls job queue completely out of order on testwiki some time ago [23:01:34] of course not all jobs should have the same value, for example transcoding or something [23:01:58] do we allow jobs that long? [23:05:32] WebVideoTranscodeJob [23:05:44] could take an hour ;) [23:16:11] AaronSchulz, is there a concept of one-off jobs, e.g. not "update links for this title", but "send all queued emails" - that is, it makes sense to have only one job of this type in queue? [23:18:05] not sure I follow [23:22:02] if (!$dbw->selectField( 'job', 'job_id', array( 'job_cmd' => 'MyCoolJob' ) ) ) new MyCoolJob()->insert(); [23:23:59] well there is Job::ignoreDuplicates and JobQueue::deduplicateRootJob [23:24:12] those are done at pop time rather than push though [23:25:05] cool, thanks [23:25:27] you will want your own synchronization handling though [23:26:07] like that selectField() above would race, as can the stuff in the JobQueue now [23:26:25] normally a few races don't matter for deduplication, it just means more work, but you might need something stricter