[00:08:00] 10Deployment-Systems, 3Scap3: Write setup.py for scap - https://phabricator.wikimedia.org/T118504#1802659 (10dduvall) [00:37:59] Yippee, build fixed! [00:38:00] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #671: 09FIXED in 1 min 33 sec: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/671/ [00:46:24] 10Deployment-Systems, 3Scap3: Debian Packaging for scap - https://phabricator.wikimedia.org/T118015#1802808 (10dduvall) [01:27:21] PROBLEM - Free space - all mounts on deployment-bastion is CRITICAL: CRITICAL: deployment-prep.deployment-bastion.diskspace._var.byte_percentfree (<44.44%) [01:39:03] Project browsertests-Wikidata-SmokeTests-linux-firefox-sauce build #439: 04FAILURE in 22 min: https://integration.wikimedia.org/ci/job/browsertests-Wikidata-SmokeTests-linux-firefox-sauce/439/ [03:26:29] (03CR) 10Krinkle: [C: 032] Test the desktop site at WPT.org [integration/config] - 10https://gerrit.wikimedia.org/r/250672 (owner: 10Phedenskog) [03:26:33] (03PS3) 10Krinkle: Test the desktop site at WPT.org [integration/config] - 10https://gerrit.wikimedia.org/r/250672 (owner: 10Phedenskog) [03:26:46] (03CR) 10Krinkle: [C: 032] "Deployed." [integration/config] - 10https://gerrit.wikimedia.org/r/250672 (owner: 10Phedenskog) [03:27:25] Yippee, build fixed! [03:27:25] Project browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #880: 09FIXED in 45 min: https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-firefox-sauce/880/ [03:28:15] (03Merged) 10jenkins-bot: Test the desktop site at WPT.org [integration/config] - 10https://gerrit.wikimedia.org/r/250672 (owner: 10Phedenskog) [05:29:22] Yippee, build fixed! [05:29:23] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_7-internet_explorer-11-sauce build #601: 09FIXED in 27 min: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-windows_7-internet_explorer-11-sauce/601/ [06:37:23] RECOVERY - Free space - all mounts on deployment-bastion is OK: OK: All targets OK [08:34:01] Yippee, build fixed! [08:34:02] Project browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-os_x_10.9-safari-sauce build #781: 09FIXED in 24 min: https://integration.wikimedia.org/ci/job/browsertests-MultimediaViewer-en.wikipedia.beta.wmflabs.org-os_x_10.9-safari-sauce/781/ [09:17:09] (03CR) 1020after4: [C: 031] "That bug is fixed in https://phabricator.wikimedia.org/D44" [integration/config] - 10https://gerrit.wikimedia.org/r/251442 (https://phabricator.wikimedia.org/T117770) (owner: 10Thcipriani) [09:18:49] Yippee, build fixed! [09:18:49] Project browsertests-GettingStarted-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce-T99655 build #5: 09FIXED in 55 sec: https://integration.wikimedia.org/ci/job/browsertests-GettingStarted-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce-T99655/5/ [09:22:17] (03PS4) 1020after4: Use $JOB_NAME-$BUILD_NUMBER in place of $ZUUL_UUID [integration/config] - 10https://gerrit.wikimedia.org/r/251442 (https://phabricator.wikimedia.org/T117770) (owner: 10Thcipriani) [09:24:13] 6Release-Engineering-Team, 10Browser-Tests-Infrastructure, 7Ruby, 7Tracking: Update repositories that use mediawiki_selenium Ruby gem to version 1.x - https://phabricator.wikimedia.org/T94083#1803183 (10hashar) [09:24:13] 7Browser-Tests, 10MediaWiki-extensions-GettingStarted, 5Patch-For-Review, 7Ruby: Upgrade GettingStarted browser tests to use mediawiki_selenium 1.x - https://phabricator.wikimedia.org/T99655#1803181 (10hashar) 5Open>3Resolved Job pass https://integration.wikimedia.org/ci/job/browsertests-GettingStarted... [09:31:12] (03CR) 10Hashar: [C: 04-1] "All good to me. We will need to migrate the repo to trigger rake-jessie, the .gem will no more be archived by Jenkins but it is not a big " [selenium] - 10https://gerrit.wikimedia.org/r/252693 (https://phabricator.wikimedia.org/T117993) (owner: 10Zfilipin) [09:38:39] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #672: 04FAILURE in 1 min 38 sec: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-chrome-sauce/672/ [09:41:34] (03CR) 10Hashar: [C: 04-1] "All fine beside a few comments. Lets do mediawiki/core in a different change :-)" (034 comments) [integration/config] - 10https://gerrit.wikimedia.org/r/252690 (https://phabricator.wikimedia.org/T114860) (owner: 10Zfilipin) [09:57:25] PROBLEM - Host deployment-cache-parsoid04 is DOWN: CRITICAL - Host Unreachable (10.68.19.197) [10:21:39] (03PS1) 10Hashar: Unwhitelist John F. Lewis [integration/config] - 10https://gerrit.wikimedia.org/r/252907 [10:21:48] (03CR) 10Hashar: [C: 032] Unwhitelist John F. Lewis [integration/config] - 10https://gerrit.wikimedia.org/r/252907 (owner: 10Hashar) [10:22:52] (03Merged) 10jenkins-bot: Unwhitelist John F. Lewis [integration/config] - 10https://gerrit.wikimedia.org/r/252907 (owner: 10Hashar) [10:25:09] (03CR) 10Hashar: "Deployed." [integration/config] - 10https://gerrit.wikimedia.org/r/252907 (owner: 10Hashar) [10:42:03] 6Release-Engineering-Team: Mira failed to sync - https://phabricator.wikimedia.org/T118555#1803265 (10jcrespo) 3NEW [11:08:03] 5Continuous-Integration-Scaling, 6operations, 5Patch-For-Review: install/deploy scandium as zuul merger (ci) server - https://phabricator.wikimedia.org/T95046#1803288 (10hashar) [11:08:05] 10Continuous-Integration-Config, 10Continuous-Integration-Infrastructure, 10Gerrit, 5Patch-For-Review, 7Technical-Debt: Disable Gerrit replication to production slaves - https://phabricator.wikimedia.org/T86661#1803286 (10hashar) 5Open>3Resolved Thanks for the merge/deploy of the puppet patch. As a f... [11:16:53] Zwin 19 [12:49:16] zeljkof: https://gerrit.wikimedia.org/r/#/c/252686/ rakefile change for puppet is rebased [13:01:39] Yippee, build fixed! [13:01:40] Project browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #847: 09FIXED in 29 min: https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/847/ [13:05:55] !log force pushed to integration/zuul patch-queue/debian/precise-wikimedia 7d4b2d3...e667fdd [13:06:01] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [13:07:10] !log force rebased integration/zuul patch-queue/debian/precise-wikimedia e667fdd...ac7616a [13:07:16] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [13:18:12] (03PS1) 10Hashar: Refresh patch for zuul-cloner --cache-no-hardlinks [integration/zuul] (debian/precise-wikimedia) - 10https://gerrit.wikimedia.org/r/252927 [13:19:21] (03PS2) 10Hashar: Refresh patch for zuul-cloner --cache-no-hardlinks [integration/zuul] (debian/precise-wikimedia) - 10https://gerrit.wikimedia.org/r/252927 (https://phabricator.wikimedia.org/T97106) [13:20:41] dpkg-source: info: the patch has fuzz which is not allowed, or is malformed [13:20:41] !!!!!!! [13:24:46] (03PS3) 10Hashar: Refresh patch for zuul-cloner --cache-no-hardlinks [integration/zuul] (debian/precise-wikimedia) - 10https://gerrit.wikimedia.org/r/252927 (https://phabricator.wikimedia.org/T97106) [13:26:33] (03PS4) 10Hashar: Refresh patch for zuul-cloner --cache-no-hardlinks [integration/zuul] (debian/precise-wikimedia) - 10https://gerrit.wikimedia.org/r/252927 (https://phabricator.wikimedia.org/T97106) [13:30:40] 5Continuous-Integration-Scaling, 6operations: Upload new Zuul packages on apt.wikimedia.org for Precise / Trusty / Jessie - https://phabricator.wikimedia.org/T118340#1803425 (10hashar) [13:31:30] (03CR) 10Hashar: [C: 032 V: 032] "Build at https://people.wikimedia.org/~hashar/debs/zuul_2.1.0-60-g1cc37f7-wmf2precise1/" [integration/zuul] (debian/precise-wikimedia) - 10https://gerrit.wikimedia.org/r/252927 (https://phabricator.wikimedia.org/T97106) (owner: 10Hashar) [13:37:41] (03PS1) 10Hashar: Merge branch 'debian/precise-wikimedia' into debian/trusty-wikimedia [integration/zuul] (debian/trusty-wikimedia) - 10https://gerrit.wikimedia.org/r/252933 (https://phabricator.wikimedia.org/T97106) [13:40:46] (03CR) 10Hashar: [C: 032 V: 032] "https://people.wikimedia.org/~hashar/debs/zuul_2.1.0-60-g1cc37f7-wmf2trusty1/" [integration/zuul] (debian/trusty-wikimedia) - 10https://gerrit.wikimedia.org/r/252933 (https://phabricator.wikimedia.org/T97106) (owner: 10Hashar) [13:46:19] (03PS1) 10Hashar: Merge branch 'debian/precise-wikimedia' into debian/jessie-wikimedia [integration/zuul] (debian/jessie-wikimedia) - 10https://gerrit.wikimedia.org/r/252934 (https://phabricator.wikimedia.org/T97106) [14:02:50] (03PS1) 10Thiemo Mättig (WMDE): Never show firstrun pages in Firefox [selenium] - 10https://gerrit.wikimedia.org/r/252936 [14:03:44] 10Deployment-Systems, 6Release-Engineering-Team: Mira failed to sync - https://phabricator.wikimedia.org/T118555#1803510 (10greg) [14:04:47] 5Continuous-Integration-Scaling, 6operations: Upload new Zuul packages on apt.wikimedia.org for Precise / Trusty / Jessie - https://phabricator.wikimedia.org/T118340#1803515 (10hashar) I had to bump the patch `0005-Cloner-Implement-cache-no-hardlinks-argument.patch` which was outdated. That is for T97106. I h... [14:04:58] 10Continuous-Integration-Infrastructure, 5Patch-For-Review, 7Zuul: Zuul-cloner should use hard links when fetching from cache-dir - https://phabricator.wikimedia.org/T97106#1233116 (10hashar) [14:04:59] 5Continuous-Integration-Scaling, 6operations: Upload new Zuul packages on apt.wikimedia.org for Precise / Trusty / Jessie - https://phabricator.wikimedia.org/T118340#1803518 (10hashar) [14:05:24] 10Continuous-Integration-Infrastructure, 5Patch-For-Review, 7Zuul: Zuul-cloner should use hard links when fetching from cache-dir - https://phabricator.wikimedia.org/T97106#1233116 (10hashar) We need to have zuul_2.1.0-60-g1cc37f7-wmf21 deployed ( T118340) [14:10:10] !log Upgrading Zuul on all CI slaves to zuul_2.1.0-60-g1cc37f7-wmf21 (refreshed the zuul-cloner --no-hard-links patch) https://phabricator.wikimedia.org/T118340 [14:10:16] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [14:15:31] (03CR) 10jenkins-bot: [V: 04-1] Never show firstrun pages in Firefox [selenium] - 10https://gerrit.wikimedia.org/r/252936 (owner: 10Thiemo Mättig (WMDE)) [14:27:18] hashar: thanks! :) [14:28:03] Yippee, build fixed! [14:28:04] Project browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce build #689: 09FIXED in 2 min 3 sec: https://integration.wikimedia.org/ci/job/browsertests-Echo-en.wikipedia.beta.wmflabs.org-linux-firefox-sauce/689/ [14:29:50] :) [14:36:15] Yippee, build fixed! [14:36:16] Project browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce build #322: 09FIXED in 8 min 14 sec: https://integration.wikimedia.org/ci/job/browsertests-MobileFrontend-SmokeTests-linux-chrome-sauce/322/ [14:40:51] (03PS2) 10Hashar: Phase out mwext-VisualEditor-qunit [integration/config] - 10https://gerrit.wikimedia.org/r/252130 [14:42:27] (03CR) 10Hashar: [C: 032] "I guess it is about time to drop the old job." [integration/config] - 10https://gerrit.wikimedia.org/r/252130 (owner: 10Hashar) [14:43:05] (03CR) 10Zfilipin: [C: 04-1] "This breaks several unit tests." [selenium] - 10https://gerrit.wikimedia.org/r/252936 (owner: 10Thiemo Mättig (WMDE)) [14:43:35] (03Merged) 10jenkins-bot: Phase out mwext-VisualEditor-qunit [integration/config] - 10https://gerrit.wikimedia.org/r/252130 (owner: 10Hashar) [14:44:10] !log deleted https://integration.wikimedia.org/ci/job/mwext-VisualEditor-qunit/ (subset of mediawiki-extensions-qunit https://gerrit.wikimedia.org/r/252130 ) [14:44:16] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [15:02:50] 7Browser-Tests, 10Wikidata, 5Patch-For-Review, 3Wikidata-Sprint-2015-11-03: [Task] Adjust browsertests for references - https://phabricator.wikimedia.org/T92249#1803691 (10Jonas) 5Open>3Resolved [16:15:43] 5Continuous-Integration-Scaling, 7Nodepool, 7Upstream: Nodepool delay instance deletions by one minute - https://phabricator.wikimedia.org/T113359#1662848 (10hashar) Patch proposed upstream to make the value configurable https://review.openstack.org/#/c/245220/ On our setup, I am just going to change the ha... [16:37:18] RECOVERY - Host deployment-parsoidcache02 is UP: PING OK - Packet loss = 0%, RTA = 0.95 ms [17:01:36] (03PS2) 10Dduvall: Never show firstrun pages in Firefox [selenium] - 10https://gerrit.wikimedia.org/r/252936 (owner: 10Thiemo Mättig (WMDE)) [17:06:35] 5Continuous-Integration-Scaling, 6operations, 5Patch-For-Review: install/deploy scandium as zuul merger (ci) server - https://phabricator.wikimedia.org/T95046#1803924 (10hashar) I think most of the work has been done now. I have poked by email @andrew and @chasemp to figure out with whom / when I can handle... [17:07:01] (03CR) 10Dduvall: [C: 032] "Thanks, Thiemo! I went ahead and added a unit test." [selenium] - 10https://gerrit.wikimedia.org/r/252936 (owner: 10Thiemo Mättig (WMDE)) [17:08:13] 5Continuous-Integration-Scaling: Upgrade Nodepool to 0.1.1-wmf4 - https://phabricator.wikimedia.org/T118573#1803928 (10hashar) 3NEW [17:08:28] (03Merged) 10jenkins-bot: Never show firstrun pages in Firefox [selenium] - 10https://gerrit.wikimedia.org/r/252936 (owner: 10Thiemo Mättig (WMDE)) [17:08:32] 5Continuous-Integration-Scaling: Upgrade Nodepool to 0.1.1-wmf4 - https://phabricator.wikimedia.org/T118573#1803939 (10hashar) [17:08:33] 5Continuous-Integration-Scaling, 7Nodepool, 5Patch-For-Review, 7WorkType-Maintenance: nodepool can't update images - https://phabricator.wikimedia.org/T111377#1602604 (10hashar) [17:08:40] 5Continuous-Integration-Scaling: Upgrade Nodepool to 0.1.1-wmf4 - https://phabricator.wikimedia.org/T118573#1803928 (10hashar) [17:08:41] 5Continuous-Integration-Scaling, 7Nodepool, 5Patch-For-Review, 7Upstream: Nodepool delay instance deletions by one minute - https://phabricator.wikimedia.org/T113359#1662848 (10hashar) [17:09:35] 5Continuous-Integration-Scaling, 7Nodepool, 5Patch-For-Review, 7Upstream: Nodepool delay instance deletions by one minute - https://phabricator.wikimedia.org/T113359#1662848 (10hashar) [17:09:36] 5Continuous-Integration-Scaling, 7Nodepool, 5Patch-For-Review, 7WorkType-Maintenance: nodepool can't update images - https://phabricator.wikimedia.org/T111377#1602604 (10hashar) [17:13:01] <_joe_> hi, what is this 2FA and TOTP, and how do I add those to my phabricator??!? [17:13:29] Hi _joe_ :) [17:13:53] <_joe_> :D [17:14:50] I'm trying to figure out how much you're trolling me :p [17:14:58] <_joe_> a lot :P [17:15:22] I'm like "I know he knows what 2FA and TOTP are...does he really need help setting it up though?" [17:16:06] thcipriani: Best test plan ever. [17:16:09] "run deploy with deploy-log in another window and be less frustrated" [17:16:31] <_joe_> ostriches: my main problem is my google authenticator has already 12 apps in it [17:16:36] ostriches: it's funny, I totally forgot about the --force flag when I was testing something else yesterday, and I wrote it! [17:16:44] <_joe_> so I get my eyes crossed every time I look at it [17:16:58] <_joe_> will be 13 with phab :) [17:17:03] 2fa all the things! [17:17:40] _joe_: I've been meaning to ask you, do you have some time to talk about pybal things with deployment folks? [17:18:05] next Friday around this time? [17:18:42] <_joe_> thcipriani: not next friday, I have the evening already packed with meetings [17:18:53] <_joe_> but earlier in the week, I'm happy to [17:19:12] <_joe_> whenever you think is best [17:19:25] _joe_: kk, we also sometimes have a meeting on Wednesday mornings. I'll try to get you on that invite. [17:19:44] (Pacific mornings) [17:19:46] <_joe_> is that the meeting filippo is already involved in? [17:19:54] That mtg is mondays [17:20:09] <_joe_> should I join that meeting regularly for some time maybe? [17:20:17] <_joe_> just to reduce the noise for you guys [17:20:29] <_joe_> whatever you think is best :) [17:21:13] we'll get you in one of our many meetings :) [17:22:15] <_joe_> lucky you! [17:22:30] thcipriani: How long shall the meetings continue? ;-) [17:22:42] sigh [17:22:49] <_joe_> well I have one ops-related meeting a week, but several more with other teams, so I'm even [17:23:12] <_joe_> it's WMF way to tell me I'm involved in too many things I guess [17:23:32] You're involved in too many things when you have simultaneous meetings :p [17:23:38] <_joe_> "stop harassing the devs, or we'll add you one more meeting" [17:24:23] <_joe_> ostriches: we are agnostic, so we don't have scrum sacraments to honour [17:24:42] <_joe_> that kinda cuts down 10 hours of meetings a week [17:26:04] on the bright-side deployment tooling meetings have organically become shorter as there're less feature-implementations to discuss. [17:27:04] on the downside, my old boss used to say that programmers have roughly 2 4-hour useful chunks during the day and 1 meeting kills half of that. [17:27:32] Heh, interestingly we spent about half of yesterday's Differential meeting talking about deploy tooling. [17:28:07] <_joe_> thcipriani: my work gets disrupted enough by entropy to need meetings, too [17:29:27] the tooling, workflow and code review all have a lot of overlap. [17:29:35] yeah, meetings are definitely needed in a lot of instances. unscheduled discussion involving more than a few people across departments surrounding a particular topic doesn't happen organically when folks are remote. [17:37:21] thcipriani: Speaking of, the big outcome of yesterday's meeting resulted in us deciding that scap should manage security patches. [17:37:34] (at the very least, ensure all required patches are applied prior to deploying) [17:38:36] And another task I was supposed to file but I lost my buffer :\ [17:39:22] ostriches: I saw that bug. Seems reasonable. Shouldn't be too hard to implement. [17:40:15] Oh yeah, the general "we need to figure out wtf is going on with -staging directories going forward. Shared workspace / shared deploy space is problematic. Yay permissions" [17:40:32] umasks and ownership and mtimes oh my [17:44:22] yeah, that's a frustrating problem. mtimes. [17:50:56] 10Deployment-Systems, 6Release-Engineering-Team, 3Scap3: Figure out shared workspace situation on deploy master - https://phabricator.wikimedia.org/T118579#1804066 (10demon) 3NEW [17:51:35] Finally summarized my general concerns from yesterday in a single place ^ [17:51:54] 10Deployment-Systems, 6Release-Engineering-Team, 3Scap3: Figure out shared workspace situation on deploy master - https://phabricator.wikimedia.org/T118579#1804086 (10demon) [17:57:42] PROBLEM - Host deployment-parsoidcache02 is DOWN: CRITICAL - Host Unreachable (10.68.16.145) [18:16:46] 10Deployment-Systems, 3Scap3: Document Scap3 post-stage checks - https://phabricator.wikimedia.org/T116636#1804221 (10mmodell) [18:24:36] 10Differential, 5Gerrit-Migration: Ensure default branches for arcanist and libphutil from gerrit and diffusion clones are compatible with phabricator.wikimedia.org - https://phabricator.wikimedia.org/T118049#1804261 (10demon) I wonder if we had people clone arcanist and libphutil from us instead of upstream w... [18:25:34] 10Differential, 5Gerrit-Migration: Ensure default branches for arcanist and libphutil from gerrit and diffusion clones are compatible with phabricator.wikimedia.org - https://phabricator.wikimedia.org/T118049#1804263 (10demon) Oh, that's what @mmodell said on the child task. This is more about *ensuring* these... [18:30:16] 5Gerrit-Migration, 15User-greg: Landing a patch with arc currently will sometimes strip author information - https://phabricator.wikimedia.org/T612#1804276 (10demon) >>! In T612#1251388, @mmodell wrote: > I don't think this actually happens, nobody has provided any steps to reproduce, and upstream hasn't ran i... [19:04:06] 10Differential, 5Gerrit-Migration: Ensure default branches for arcanist and libphutil from gerrit and diffusion clones are compatible with phabricator.wikimedia.org - https://phabricator.wikimedia.org/T118049#1804381 (10bd808) The problem I ran into was that the default branch is "master" but in our clones the... [19:40:26] thcipriani: marxarelli: twentyafterfour: hello, I am reviewing the ZUUL_UUID related patch [19:40:34] hopefully get all jobs refreshed tonight [19:40:40] er this afternoon for you guys [19:41:22] hashar: kk, thanks for the review. I should be around to babysit that patch. [19:41:36] * hashar sends his kids to thcipriani [19:42:07] any clue why diffusion uses URL such as https://phabricator.wikimedia.org/diffusion/MSCA/scap [19:42:09] I can barely get myself dressed and fed most days. [19:42:15] seems MSCA and /scap are redundant [19:42:57] ¯\_(ツ)_/¯ that's a twentyafterfour question :) [19:43:27] funnily I can clone using https://phabricator.wikimedia.org/diffusion/MSCA/ :} [19:45:18] I can change that patch if you think that's cleaner/nicer/less-redundant [19:46:15] na just wondering [19:47:04] and we have duplicate code :-( [19:47:13] the builders doc-publish and cover-publish are the same [19:51:39] except one takes a docsrc and a docdest and the other takes a src and a dest [19:52:16] well, and that one publishes to org/wikimedia/doc vs org/wikimedia/integration [19:52:18] yeah that is all messy [19:53:23] aohrezrher [19:54:23] in the rsync command from labs to prod, the paths have /. added to them [19:54:38] any idea what it is for ? :} [19:54:49] I remember bryan took a while to figure out the exact commands [19:54:51] yeah, that's me being terrible at rsync trailing slashes. [19:55:14] we tested it once, and it created a new directory inside the intended directory [19:55:36] yeah the trailing slashes are rather annoying [19:56:01] then I went with the nuclear option: add '/.' to both commands {{done}}. [20:05:02] (03PS5) 10Hashar: Use $JOB_NAME-$BUILD_NUMBER in place of $ZUUL_UUID [integration/config] - 10https://gerrit.wikimedia.org/r/251442 (https://phabricator.wikimedia.org/T117770) (owner: 10Thcipriani) [20:06:05] (03CR) 10Hashar: "Adjusted a comment for PUBLISHER_PATH, that is the path on integration-publisher to fetch from gallium." [integration/config] - 10https://gerrit.wikimedia.org/r/251442 (https://phabricator.wikimedia.org/T117770) (owner: 10Thcipriani) [20:06:23] thcipriani: maybe that will work :-} [20:06:53] updating mw-tools-releng-tox-doc-publish [20:07:04] hashar: fair enough :) [20:07:45] twentyafterfour: https://phabricator.wikimedia.org/rGSVbee48cd906c4569a9ff9cd2e4f17d64455f50663 triggered audit, obviously. Can you review? [20:07:47] so that is mediawiki/tools/releng , last change is https://gerrit.wikimedia.org/r/#/c/200240/ [20:08:57] That could be a phab project :) [20:08:59] pushing it again in the postmerge pipeline with: zuul enqueue --trigger gerrit --pipeline postmerge --project mediawiki/tools/releng --change 200240,1 [20:10:04] boohhh https://integration.wikimedia.org/ci/job/publish-on-gallium/14376/console [20:11:01] publish-on-gallium still using zuul-uuid I take it? [20:12:11] 10Deployment-Systems, 3Scap3: Debian Packaging for scap - https://phabricator.wikimedia.org/T118015#1804587 (10demon) [20:12:13] 10Deployment-Systems, 3Scap3: Write setup.py for scap - https://phabricator.wikimedia.org/T118504#1804585 (10demon) 5Open>3Resolved [20:12:37] hashar: we created a second publish job for mw-tools-scap so that we wouldn't break publish-on-gallium stuff in the interim, while waiting for patch review. [20:12:57] https://integration.wikimedia.org/ci/job/publish-scap-on-gallium/ [20:13:52] ohhh [20:14:14] i should use a nuke as well [20:14:17] just deploy everything [20:14:20] and hope it works fine :-} [20:14:25] maybe it will just work !!! © [20:14:43] meanwhile, all that crap in jenkins jobs can probably be rewritten [20:17:13] it _should_ just work, publish-scap-on-gallium _is_ the proposed change to publish-on-gallium. Last job "succeeded" but for publish-on-gallium looking at the uuid. [20:20:36] I need a bot that would /msg me whenever I overthink stuff [20:21:59] !log integration mass updating publish related jobs ( https://gerrit.wikimedia.org/r/#/c/251442/ ) [20:22:04] qa-morebots: ping [20:22:04] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [20:22:05] I am a logbot running on tools-exec-1213. [20:22:05] Messages are logged to https://tools.wmflabs.org/sal/releng. [20:22:05] To log a message, type !log . [20:22:13] qa-morebots: 5 seconds service time is barely acceptable! [20:22:13] I am a logbot running on tools-exec-1213. [20:22:13] Messages are logged to https://tools.wmflabs.org/sal/releng. [20:22:14] To log a message, type !log . [20:22:18] poor bot [20:22:34] heh [20:23:53] bah [20:23:57] taking a backup [20:24:08] some repos publishes the wmf/ branches as documentation ;-} [20:26:04] that is just Flow [20:27:14] well that's good :) [20:27:38] 10Continuous-Integration-Config: CI generate docs for Flow and MobileFrontend wmf branches - https://phabricator.wikimedia.org/T118599#1804608 (10hashar) 3NEW [20:27:49] and MobileFrontend [20:27:52] will be for later [20:28:23] !log on gallium backing up /srv/org/wikimedia/integration/{doc,cover} to /home/hashar/{doc,cover}.tar.gz [20:28:29] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [20:38:48] still backing up [20:39:05] I'm watching ps aux | grep -i tar on gallium :) [20:44:21] 10Differential, 5Gerrit-Migration: Ensure default branches for arcanist and libphutil from gerrit and diffusion clones are compatible with phabricator.wikimedia.org - https://phabricator.wikimedia.org/T118049#1804627 (10mmodell) @bd808: I fixed phabricator's copy of these repos, so rPHAB, rARC and rPHUTIL shou... [20:50:21] though I already pushed the job [20:50:36] so the backup is in a race with the next publish/cover job hehe [20:50:55] 10Differential, 5Gerrit-Migration: Ensure default branches for arcanist and libphutil from gerrit and diffusion clones are compatible with phabricator.wikimedia.org - https://phabricator.wikimedia.org/T118049#1804645 (10demon) >>! In T118049#1804627, @mmodell wrote: > @bd808: I fixed phabricator's copy of thes... [20:51:06] as I say often, I am happy to not be handling money at a bank or people life in a hospital [20:52:08] hashar: the reason diffusion appends scap.git to the MSCA url is so that when you clone it, git will create a directory called scap, not MSCA [20:52:19] oh [20:52:25] it's just a 'user friendly project name' option in the repo [21:02:42] ahh [21:02:48] haven't though about that twentyafterfour , makes sense [21:03:26] hashar: is it alright if I deploy a zuul change? or are you doing things on gallium? [21:04:04] taking backup of doc / cover [21:04:14] legoktm: be bold, just do it :-} [21:04:31] (03PS2) 10Legoktm: Add composer-test to UserMerge extension [integration/config] - 10https://gerrit.wikimedia.org/r/252287 [21:04:36] if something screw up I am confident we can recover something somehow :-} [21:04:49] moaar repos [21:05:02] (03CR) 10Legoktm: [C: 032] Add composer-test to UserMerge extension [integration/config] - 10https://gerrit.wikimedia.org/r/252287 (owner: 10Legoktm) [21:06:03] (03Merged) 10jenkins-bot: Add composer-test to UserMerge extension [integration/config] - 10https://gerrit.wikimedia.org/r/252287 (owner: 10Legoktm) [21:06:17] !log deploying https://gerrit.wikimedia.org/r/252287 [21:06:23] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [21:06:33] Exception: Gerrit error executing gerrit review --project mediawiki/extensions/MediaWikiChat --message "Gate pipeline build succeeded. [21:07:17] legoktm: usually because jenkins-bot is not granted permission to submit a patch on the repo [21:07:27] though mediawiki/extensions/MediaWikiChat should inherit rights from mediawiki [21:07:36] which has jenkins-bot [21:08:10] weirddd [21:08:53] https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/MediaWikiChat,access [21:08:55] it does inherit [21:11:09] thcipriani: backup completed ! [21:11:14] !log zuul enqueue --trigger gerrit --pipeline postmerge --project mediawiki/tools/releng --change 200240,1 [21:11:17] hashar: \o/ [21:11:20] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL, Master [21:11:36] https://integration.wikimedia.org/ci/job/mw-tools-releng-tox-doc-publish/51/console [21:11:39] comeone sphinx [21:11:41] SUCCESS [21:11:48] https://gerrit.wikimedia.org/r/#/c/253033/ probably because force merged? [21:11:49] nice! [21:11:54] publish https://integration.wikimedia.org/ci/job/publish-on-gallium/14385/console [21:12:00] hopefully it hasn't nuked everything [21:12:27] legoktm: https://doc.wikimedia.org/IPSet/master/ ??? [21:12:43] what about that? [21:12:43] legoktm: is that part of stuff getting extracted from mediawiki to standalone libraries? [21:12:47] yes [21:12:59] \O/ [21:15:09] the libraries list at https://doc.wikimedia.org/ keeps getting longer and longer [21:16:10] yeah [21:16:18] we would need a better marketing plan though [21:16:20] that page sucks [21:16:50] (03PS6) 10Hashar: Use $JOB_NAME-$BUILD_NUMBER in place of $ZUUL_UUID [integration/config] - 10https://gerrit.wikimedia.org/r/251442 (https://phabricator.wikimedia.org/T117770) (owner: 10Thcipriani) [21:17:17] (03CR) 10Hashar: [C: 032] "Aced by the #together team. Well done everyone :-}" [integration/config] - 10https://gerrit.wikimedia.org/r/251442 (https://phabricator.wikimedia.org/T117770) (owner: 10Thcipriani) [21:17:20] thcipriani: landing it [21:17:36] twentyafterfour: thcipriani kudos on the scary zuul-uuid docpublishing stuff [21:18:17] hashar: yay! thanks! [21:18:30] we would need to update the wiki doc though https://www.mediawiki.org/wiki/Continuous_integration/Documentation_generation [21:18:45] might get to it on monday [21:18:51] (03Merged) 10jenkins-bot: Use $JOB_NAME-$BUILD_NUMBER in place of $ZUUL_UUID [integration/config] - 10https://gerrit.wikimedia.org/r/251442 (https://phabricator.wikimedia.org/T117770) (owner: 10Thcipriani) [21:19:18] I have sent myself a reminder [21:21:03] Yippee, build fixed! [21:21:03] Project browsertests-QuickSurveys-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #69: 09FIXED in 5 min 2 sec: https://integration.wikimedia.org/ci/job/browsertests-QuickSurveys-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/69/ [21:22:16] RECOVERY - Host deployment-parsoidcache02 is UP: PING OK - Packet loss = 0%, RTA = 0.72 ms [21:22:37] 10Beta-Cluster-Infrastructure, 10Deployment-Systems, 5Patch-For-Review, 7WorkType-Maintenance: beta-scap-eqiad mira / deployment-bastion permissions problem - https://phabricator.wikimedia.org/T117016#1804679 (10bd808) This problem is back after deploying the 1.27.0-wmf.6 branch. @mmodell and I talked abou... [21:30:53] marxarelli: I think if we want to avoid the php dependency on scap packaging we'll definitely want to rewrite refreshCdbJsonWhatevs in python. [21:31:18] It actually assumes you have dba_* functions compiled with cdb support. [21:31:32] and port php -l to python? [21:31:41] ;) [21:31:43] Bleh. [21:32:10] legoktm: booya: https://pypi.python.org/pypi/php-lint [21:32:21] wel [21:32:30] the nodejs cabal is already busy porting mediawiki to npm [21:32:54] oh my. [21:33:19] I saw that npm stuff. It doesn't touch how we do tar releases so I kinda ignored it [21:35:36] and Gabriel has the pet project to ship docker containers for easy deployment of the full stack [21:35:50] I don't have any opinions,just missing a clear directions as to what we want to do [21:35:59] clear direction [21:36:57] I can't find docs, source or a package in pip though. Just that page. [21:37:38] a lot of users don't want to maintain a server environment [21:38:02] php-in-python - Running PHP interpreter within Python. [21:38:03] so anything that minimizes their responsibilities is good in their eyes [21:38:03] Hehe [21:38:35] packages might be too low-level still [21:39:00] but, they'd make for a great building block for other formats [21:39:19] be it docker or Amazon AMIs [21:39:50] As long as we can automate the building of them for a release, I don't have a huge objection to uploading them to releases.wm.o alongside the tars of just MW [21:39:52] 10Deployment-Systems, 6Release-Engineering-Team: Mira failed to sync - https://phabricator.wikimedia.org/T118555#1804699 (10bd808) [21:39:54] 10Beta-Cluster-Infrastructure, 10Deployment-Systems, 5Patch-For-Review, 7WorkType-Maintenance: beta-scap-eqiad mira / deployment-bastion permissions problem - https://phabricator.wikimedia.org/T117016#1804700 (10bd808) [21:40:01] (also, I need to finish automating that to begin with) [21:40:04] 10Deployment-Systems, 6Release-Engineering-Team: Mira failed to sync - https://phabricator.wikimedia.org/T118555#1804702 (10hashar) [21:40:06] 10Beta-Cluster-Infrastructure, 10Deployment-Systems, 5Patch-For-Review, 7WorkType-Maintenance: beta-scap-eqiad mira / deployment-bastion permissions problem - https://phabricator.wikimedia.org/T117016#1804703 (10hashar) [21:40:48] 10Deployment-Systems, 6Release-Engineering-Team: Mira failed to sync - https://phabricator.wikimedia.org/T118555#1803265 (10hashar) From bryan davis on IRC: > sync-masters is the rsync fetch from tin to mira and it is flakey at the moment. We had it working but it took root help to twiddle permissions and that... [21:43:04] ostriches, I keep meaning to push https://phabricator.wikimedia.org/T87774 along, but sadly the week only has seven days [21:44:08] Yeah, I haven't had the cycles to improve on 3rd party release process. [21:44:10] I want to tho. [21:44:11] it's very much about releasing, so I think if you as releng proposed a strategy people would buy it [21:44:57] I am wondering if we could get MediaWiki installer to install the related backend for the user :D [21:45:21] backend? [21:45:22] but that sounds like asking to reinvent the wheel of .deb / .rpm packaging [21:45:24] I mean [21:45:26] install.php [21:45:36] then you get asked whether you want to enable Parsoid / Citoid / Mathoid etc [21:45:52] that download the material out of the internet, set it up and generate the related LocalSettings.php [21:45:58] doing 'just' docker might be quicker [21:46:02] I think .deb/.rpm packages are stupid for web applications. [21:46:08] I'd prefer just about anything to that. [21:46:26] but then we would want tarballs to be generated and signed [21:46:38] We have tarballs and they're signed? [21:46:49] and having the services setup to run as daemon is going to ask for crzyiness [21:46:52] as much as I'd like to see a proper deb for MW core as well, it's a lot quicker to create a dockerfile with a couple of shell commands to set up a wiki [21:47:10] ostriches: well you want the installer to be able to validate what it is downloading from internet [21:47:40] That's a nice idea for the installer to support [21:48:33] gwicke: I need to rethink how releases are built a tad. With some wrangling, we could have it automated and sufficiently abstracted enough that adding a new distro method should "just" be a matter of doing the distro-specific stuff. [21:48:53] a good thing would be for people to be able to reuse whatever provisioner we come with [21:49:06] so they can use whatever containers they want or create their own containers [21:49:08] yeah, that's a plus for docker [21:49:20] no need to also support rpm, for example [21:49:26] The old school me is going to continue to make tarballs for MW core even if nobody downloads them :P [21:49:28] with one of the option being a docker image [21:49:51] ostriches: We only sign MW tarballs. Not ExtensionDistributor's. [21:49:59] ops is getting into docker as well [21:50:00] ostriches: (This doesn't mean we should start…) [21:50:08] Extensions, lol. [21:50:08] so folks could reuse the utility to generate a VMWare image or a Solaris container or whatever [21:50:15] yuvi & _joe_ especially [21:50:16] or even just install on their host [21:51:07] James_F: More honestly though, I've toyed the idea of a shared gpg key for releasing so A) we don't rely on SPOFs to sign releases, and B) We could do fun cluster-side automation of releases. [21:51:11] gwicke: they have Ganeti in Dallas. And for labs Kubernetes which would let volunteers send docker images that runs on the labs infra [21:51:16] Such an idea would allow us to sign ExtDist stuff too... [21:51:17] well actually another infra [21:51:19] ostriches: Could be interesting. [21:51:22] https://github.com/jordansissel/fpm [21:51:30] ostriches: Also, we could do multiple releases, rather than just one. [21:51:54] * ostriches goes to write [[Special:MakeRelease]] [21:51:56] ostriches: "Full-stack" (WMF-prod clone), "Basic" (nothing), "Light" (current), "Farm"… [21:52:02] * James_F grins. [21:52:18] But this is me proposing work (which is easy), rather than committing to do it (which is not). [21:52:21] So ignore me. ;-) [21:52:26] a volunteer already had a hacky mediawiki docker image [21:52:41] https://hub.docker.com/r/synctree/mediawiki/ [21:52:46] James_F: We've been spending the last 15mins or so cookie licking so please join in :) [21:52:54] * James_F laughs. [21:53:06] Ubuntu even has an orchestration system that supports mediawiki [21:53:23] Personally I want a WordPress-style Special:AdministerWiki page where I can install/uninstall extensions/skins and updates to them and MW itself over the Web. [21:53:30] But that's… hard. [21:53:39] It's so easy [21:53:45] Having MW self-update is trivial. [21:53:50] We could've done it during new-installer. [21:53:51] Hard to do in a way we'd want to support security-wise. [21:53:54] https://github.com/synctree/docker-mediawiki [21:53:57] James_F: Yep! [21:54:01] :-) [21:54:23] https://www.packer.io/intro [21:54:34] "Packer is an open source tool for creating identical machine images for multiple platforms from a single source configuration" [21:54:40] Tim very quickly was like "Erm no, we're not encouraging people to have their files writable by the user running apache" [21:54:43] ah [21:54:43] https://jujucharms.com [21:55:06] so you click 5 varnishes 10 memcached 2000 mediawiki 100 DB [21:55:15] and in theory you have the whole infra in a few clicks [21:55:16] ostriches: you can work around that by putting the blobs into the db [21:55:17] I'd dearly love us to bundle VE in the MW tarball. [21:55:34] But that means a lot of thinking about who the tarball is for. [21:55:36] gwicke: The PHP code? [21:55:41] not that it makes it a lot safer, but it sounds better ;) [21:55:53] James_F: the stopper is the PArsoid daemon imho [21:55:59] That sounds like a self-bootstrapping nightmare :p [21:56:04] PhParsoid might make it tenable (if slow) for non-Node environments. [21:56:09] but yeah, we can create another mediawiki distribution which is beefed up and comes with ve / parsoid [21:56:21] and maybe mediawiki/services/jobrunner [21:56:34] and eventlogging, and kafka ;) [21:56:40] And Elasticsearch! [21:56:45] And graphite [21:56:51] mit alles! [21:56:54] Icinga, for added fun :) [21:57:06] and puppet / hiera [21:57:07] managed on wiki [21:57:12] Mailman? [21:57:14] * ostriches ducks [21:57:17] sure [21:57:19] to replace Flows [21:57:21] and Talk: [21:57:28] pages [21:57:43] sorry looks my brain suddenly confused [Enter] and [Space bar] [21:57:44] There's a lot of work to do before we could sanely bundle even VE with MW. [21:57:49] seriously, we should look more closely at the existing docker images [21:57:52] so anyway in the end [21:58:05] I don't think people involved in the wmf somehow have any time for it [21:58:05] https://phabricator.wikimedia.org/T84936 is my rough tracker. [21:58:26] unless suddenly the community manages to add that to the strategy plan and suddenly it becomes an organization goal [21:58:40] cause lets be honest: we don't need such thing to operate the wikimedia infra [21:58:58] gwicke: I don't disagree but I'll refer you back to the hours/day/week problem :( [21:59:06] James_F: impressive list [21:59:14] James_F: I think VE should be bundled as soon as we can figure out a way to do that sanely [21:59:20] hashar: Most all of them are language support. [21:59:33] nothing is ever going to be perfect, but yet it's already useful to people [21:59:38] let's start by reimplementing mw-vagrant as a kubernetes cluster within virtualbox :) [21:59:51] I don't think we should bundle VE with MW if VE has radically-lower language support. [22:00:05] have we even released a VE version yet ? [22:00:11] hashar: No. [22:00:12] Currently missing languages including CJK and Indics. We're working on it. [22:00:13] And because marxarelli hates his users we'll use bash instead of puppet for provisioning [22:00:21] James_F: bundled doesn't mean 'enabled by default' [22:00:23] with a long living branch that is supported for a few months [22:00:24] marxarelli: with docker containers of course right? [22:00:30] or 'impossible to disable' [22:00:41] gwicke: We shouldn't make it bundled unless it's on by default, but sure. [22:00:41] ostriches: hey, my setup.sh is far quicker than puppet could ever be :) [22:01:03] James_F, gwicke: No extensions are enabled by default. [22:01:24] bd808: to start, but lxd/lxc or rkt/nspawn when it's supported [22:01:38] ostriches: Really? [22:01:43] and docker is abandoneare ;) [22:01:44] Nope [22:01:44] ostriches: as a matter of policy, applying to all future release mechanisms? [22:01:47] ostriches: Not even Poem? [22:01:48] abandonware [22:01:52] ;) [22:01:54] Not by policy [22:02:00] Just how it works right now [22:02:11] *nod* [22:02:20] ostriches: Oh, interesting. [22:02:23] MW doesn't know it's been bundled with anything [22:03:33] * gwicke tries `docker run synctree/mediawiki` [22:03:55] James_F: It could, though. We could have a list of $bundledAndLikelyToEnableExtensions or something in core. [22:04:00] And if they exist, enable by default. [22:04:14] But you could still uncheck on install, obvs. [22:04:46] * James_F nods [22:05:36] VE bundling means (a) installing a Parsoid and RESTbase service automatically, (b) writing a PHP clone of them, or (c) telling the user they're stuffed. [22:06:20] Honestly I'd rather spend my copious free time working on VE-WordPress as that will open it up to totally new developers. ;-) [22:08:08] In theory, it's as easy as something as https://phabricator.wikimedia.org/P2308 [22:11:09] why not bundle a ton of extensions and just give them a setup page to enable/disable whichever they want? then give them a cli tool to download and install new ones? [22:16:26] * gwicke got a mw running in docker, with a different docker container running mysql [22:16:51] we already have a dockerfile for restbase [22:18:24] PROBLEM - Free space - all mounts on deployment-bastion is CRITICAL: CRITICAL: deployment-prep.deployment-bastion.diskspace._var.byte_percentfree (<12.50%) [22:18:36] * gwicke should try to set up mysql+mw+parsoid+rb on the weekend [22:23:26] 10MediaWiki-Releasing: Ready-to-use Docker package for MediaWiki - https://phabricator.wikimedia.org/T92826#1804775 (10GWicke) There is a reasonable docker image at https://hub.docker.com/r/synctree/mediawiki/. It is using a linked MySQL instance, so doesn't try to bundle several services in a single system. The... [22:26:13] 10Beta-Cluster-Infrastructure, 10Deployment-Systems, 5Patch-For-Review, 7WorkType-Maintenance: beta-scap-eqiad mira / deployment-bastion permissions problem - https://phabricator.wikimedia.org/T117016#1804778 (10mmodell) [22:27:53] 10Deployment-Systems, 3Scap3: Debian Packaging for scap - https://phabricator.wikimedia.org/T118015#1804786 (10mmodell) [22:29:10] 10Continuous-Integration-Config, 10Fundraising Tech Backlog, 10Fundraising-Backlog, 10Wikimedia-Fundraising-CiviCRM: Enable CI jobs on the new CiviCRM repos - https://phabricator.wikimedia.org/T118604#1804791 (10awight) 3NEW [22:31:29] gwicke: And VE. ;-) [22:32:03] James_F: yeah, but that's just in the MW container [22:32:31] adding.. [22:32:53] gwicke: Citoid wouldn't be. [22:32:58] gwicke: Zotero + Citoid. [22:33:10] Plus extension and configuration. [22:33:22] Not that I'd recommend it for third parties, really. [22:33:23] is that a hard dependency? [22:33:26] No. [22:33:44] citoid is fine - we could just include it in the parsoid / rb image [22:33:52] but zotero is ugly at best [22:34:01] Yeah, don't do that. [22:34:10] Mathoid might be more interesting. [22:37:33] mentioned both in https://phabricator.wikimedia.org/T92826#1804775 [22:37:42] that was the easy part ;) [22:38:21] btw, I did register the wikimedia org on docker hub a while ago; let me know if you'd like to be added as well [23:10:08] Yippee, build fixed! [23:10:09] Project browsertests-Gather-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce build #324: 09FIXED in 13 min: https://integration.wikimedia.org/ci/job/browsertests-Gather-en.m.wikipedia.beta.wmflabs.org-linux-chrome-sauce/324/ [23:15:02] "why not bundle a ton of extensions and just give them a setup page to enable/disable whichever they want?" <- We already do bundle some and provide away in the installer for people to enable them. [23:15:12] We don't bundle a "ton" because most extensions are junk :p [23:15:56] eh, whose idea was that? >.> [23:16:48] twentyafterfour said bundle a ton [23:21:19] lets not please :P [23:21:28] we *should* merge the good extensions into core though [23:22:18] I was just offering that as an alternative to some download & install from the web interface thing that was suggested above [23:22:43] but I agree with legoktm, merge the good stuff [23:22:49] https://phabricator.wikimedia.org/T28751 [23:23:30] and the flipside https://phabricator.wikimedia.org/T31145 [23:24:25] hah. Do 'core' integrated extensions still use the same extension hooks and other bootstrapping mechanism? [23:25:18] that is to say, is there more involved than just moving them from separate repos to the core repo? [23:32:53] typically it's just copying code and adjusting how it's integrated [23:32:54] not much code effort, just social effort [23:32:54] and core's code quality expectations are much higher than extensions [23:34:32] I see. Yeah, after reading a couple of subtasks for moving extensions into core, they are essentially just blocked by 'this code sucks' [23:34:39] The only reason Poem isn't in core is because is a terrible name :p [23:34:54] lol. naming things is hard [23:36:04] ostriches: instead of a redirect script, I think I can just modify the URL routing in diffusion to support the old project hierarchy. [23:36:15] Oooh [23:36:27] Phabricator now uses sane url routing with regex patterns that map to controller classes [23:36:43] I can just route /r/whatever to diffusion [23:36:53] and inject the callsign from the static map [23:37:28] That's even easier than redirecting, which would need a set of input/output URLs. [23:37:57] yeah [23:39:39] and then git.wm.o wouldn't need to examine the mapping in order to redirect: just map /(.*) => phabricator.wikimedia.org/r/$1 [23:40:47] less fragile and it would be nice to continue using the existing urls in phabricator without hitting a redirect every time you enter one [23:41:05] er the existing project paths at least [23:54:52] PROBLEM - Puppet failure on pmcache is CRITICAL: CRITICAL: 100.00% of data above the critical threshold [0.0]