[00:00:03] <Krinkle>	 Skizzerz: Within Travis you can pull down pretty much any code from anywhere and install it. Host environments are either Ubuntu VMs (GCE),  macOS VMs (MacStadium), or Linux Docker containers (AWS). I'm not sure if Mssql runs on Linux, it seems Microsoft announced in 2016 that it can. Alternatively, AppVeyor is an alternative to Travis CI that provides free CI for Windows. 
[00:03:10] <Krinkle>	 I can't find the article from Microsoft's blog, but here is an example showing Microsoft's aptitude-compatible repository being used to install mssql-server ; https://dba.stackexchange.com/a/198173
[00:04:56] <Skizzerz>	 Microsoft provides a linux docker container with mssql already installed as a free download
[00:05:53] <Krinkle>	 Yeah, but might be easier to install plainly within Travis, although pulling down a docker image also works. Docker is pre-installed in Travis' enviornment.
[00:06:25] <davidwbarratt>	 since Pingbacks are horribly inaccurate, should we just remove them?
[00:06:40] <MaxSem>	 they're helluva useful even as it is
[00:06:58] <davidwbarratt>	 but if you can't use the data to form a decision, what's the point?
[00:06:58] <Krinkle>	 Indeed. 
[00:07:06] <Skizzerz>	 I'm not familiar with what's easy or not int travis; do we have a test environment to play around in without breaking travis builds for commits?
[00:07:16] <Krinkle>	 You can use the data to inform other decisions, just not the dbtype usage one.
[00:07:38] <Krinkle>	 Skizzerz: fork wikimedia/mediawiki on github.com, enable Travis via profile, and start editing .travis.yml :)
[00:07:48] <Skizzerz>	 worksforme :)
[00:09:09] <Krinkle>	 Skizzerz: Be sure to set `sudo: required`, needed in order to run docker or apt-get commands (which means it'll run the build in a VM on Travis' GCE infra instead of a Docker container)
[00:53:02] <Krenair>	 pingbacks can be used to show something is being used in some cases
[00:53:10] <Krenair>	 even if they can't be used to show that something is not being used
[13:41:56] <DanielK_WMDE>	 tgr: do you have to to review two patches?
[13:42:12] <DanielK_WMDE>	 they have been stuck for several weeks now...
[13:42:16] <DanielK_WMDE>	 https://gerrit.wikimedia.org/r/c/mediawiki/core/+/443985
[13:42:19] <DanielK_WMDE>	 https://gerrit.wikimedia.org/r/c/mediawiki/core/+/434142
[13:47:13] <tgr>	 will look at them
[13:51:27] <tgr>	 DanielK_WMDE: why is T198342 not needed for write both, read new? it seems like that method would trigger deprecation warnings in read-new mode
[13:51:28] <stashbot>	 T198342: Remove all usages of the 'text' flag in calls to Revision::getQueryInfo() and RevisionStore::getQueryInfo(). - https://phabricator.wikimedia.org/T198342
[13:52:17] <DanielK_WMDE>	 tgr: it does. but it'S not strictly a blocker.
[13:53:48] <tgr>	 it will make API integration tests fail, that seems a pretty big blocker to me
[13:54:12] <tgr>	 probably a bunch of other tests too
[13:56:29] <DanielK_WMDE>	 tgr: yes, it blocks write-new becomeing the default. but it doesn't block write-new on the live site. 
[13:56:48] <DanielK_WMDE>	 err, read-new.
[13:57:08] <tgr>	 that makes sense. Is RelEng OK with it?
[13:57:08] <DanielK_WMDE>	 the question is: are we ok with putting read-new live without having as the default in CI?
[13:57:21] <DanielK_WMDE>	 I don't know, tbh.
[13:57:35] <DanielK_WMDE>	 in what tiome zone is greg-g?
[13:58:40] <tgr>	 PDT
[15:58:15] <greg-g>	 first in CI then in prod is the usual response
[15:58:35] <greg-g>	 s/CI/CI+Beta/
[16:16:45] <DanielK_WMDE>	 greg-g: it's already on beta, but on on CI yet. 
[16:17:30] <greg-g>	 I don't fully grok why or why not in this case (or what the gotchas are), sadly
[16:20:13] <DanielK_WMDE>	 greg-g: basically, we trigger a deprecation warning for code that still reads revisions the old way when reading the new schema is enabled (write-both/read-new mode).
[16:20:54] <DanielK_WMDE>	 we need write-both/read-new live for at least commonswiki by the end of august. 
[16:21:28] <DanielK_WMDE>	 but fixing *all* code that directly accesses the text table by then may not be possible.
[16:21:48] <DanielK_WMDE>	 but only after we do that can we go to write-both/read-new in CI. Otherwise, the deprecation warning will make tests fail
[16:22:20] <DanielK_WMDE>	 So, the easiest solution is: don't trigger a deprecation warning, just ignore this situation silently.
[16:23:05] <DanielK_WMDE>	 or get all the fixes in really really quickly
[16:23:09] <DanielK_WMDE>	 or push back the deadline
[16:23:35] <DanielK_WMDE>	 or enable write-both/read new on beta and test and commonswiki, but not for CI, and live with the warnings in the log for a while
[16:23:51] <DanielK_WMDE>	 greg-g: does that explain the situation to you?
[16:41:41] <DanielK_WMDE>	 coreyfloyd: --^^^
[16:42:08] <coreyfloyd>	 DanielK_WMDE: thanks!
[16:48:44] <Reedy>	 If anyone cares enough.. We've got a few reports of article counters not working properly
[17:02:28] <Reedy>	 Specifically, adding links not being enough to make it registered
[17:02:43] <Reedy>	 initSiteStats.php fixes it
[17:05:15] <Reedy>	 https://phabricator.wikimedia.org/T200823
[17:05:17] <Reedy>	 MCR related?
[17:11:37] <greg-g>	 DanielK_WMDE: what's the diff between uses in production and uses in CI? order of magnitude-wise? I'm just iffy on turning something on in production that isn't being tested in CI (even for things going to production)
[19:31:48] <legoktm>	 can someone +2 https://gerrit.wikimedia.org/r/c/mediawiki/core/+/449525 please?
[19:32:29] <legoktm>	 todays jenkins backlog is solely because that test keeps failing >.<
[22:51:14] <Krinkle>	 anomie: ping regarding https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/435822/
[23:59:10] <TimStarling>	 anomie is probably not here
[23:59:22] <TimStarling>	 web upgrade is totally broken for sqlite