[22:49:18] * MaxSem glares at Isarra
[22:58:16] <Isarra>	 Sorry.
[22:58:35] <Isarra>	 Wider compatibility is good for us, though!
[23:37:24] <davidwbarratt>	 legoktm should I, in the future, ignore -1's for MSSQL support? https://gerrit.wikimedia.org/r/c/mediawiki/core/+/440871
[23:38:18] <legoktm>	 No?
[23:39:01] <davidwbarratt>	 uhh, so it seems like developers ARE expected to make their schema changes for MSSQL?
[23:39:43] <legoktm>	 Yes?
[23:40:25] <davidwbarratt>	 legoktm then why did you say what I said was incorrect? https://phabricator.wikimedia.org/T113831#4463270
[23:41:51] <legoktm>	 There's an important distinction between writing a schema file and actually setting up the database and testing it. The former is generally required, the latter most definitely isn't
[23:42:20] <davidwbarratt>	 so it's ok to commit code that is completely untested?
[23:42:33] <brion>	 do we have CI tests for mssql? cause i have no idea how i'd test, or even look up documentation on, mssql stuff
[23:42:46] <Reedy>	 It's one thing to commit. It's a different thing to merge without review
[23:43:03] <davidwbarratt>	 brion you can test it with the docker containers they make available https://phabricator.wikimedia.org/T197995
[23:43:10] <brion>	 ooh fun
[23:43:19] <legoktm>	 brion: Skizzerz was going to work on CI (in travis I think) after/during the abstract schema RfC
[23:43:24] * brion files that away for later
[23:43:32] <davidwbarratt>	 the MsSQL one works really well, the Oracle one I coudln't get to work
[23:44:16] <Skizzerz>	 yeah, I have $150/mo in azure credits that I'm doing absolutely nothing with, so I'd be totally fine with spinning up an mssql server to run CI tests against, unless travis has its own built-in (and free as in money) thing for that
[23:44:29] <davidwbarratt>	 Skizzerz ++
[23:45:11] <davidwbarratt>	 legoktm so can we document (in the wiki?) what the expectations are for developers on database systems that we support? would you mind doing that?
[23:45:13] <Skizzerz>	 <davidwbarratt> so it's ok to commit code that is completely untested? <-- cc me and I'll test it for you :)
[23:45:30] <Skizzerz>	 and also give you the exact fixes in case it doesn't work, instead of forcing you to learn yet another sql dialect
[23:45:33] <davidwbarratt>	 Skizzerz I appreciate that, and I figured out how to test it to. :)
[23:45:47] <davidwbarratt>	 Skizzerz but if we expect _someone_ to test it, then I think that should be in the wiki
[23:45:48] <legoktm>	 davidwbarratt: sure
[23:46:07] <davidwbarratt>	 legoktm thanks!
[23:46:46] <davidwbarratt>	 but I think perhaps I misunderstood the expectations, so I appreciate the clarity and documentation on the matter
[23:48:08] <Skizzerz>	 eventually it may be a good idea to split out the non-mysql dbs into "extensions" (in quotes because they'd have to be live without being installed as typical extensions are due to needing installer support), but we really need an abstract schema before we can do that. Otherwise, the split dbs will never get patches for schema updates and therefore will be perpetually out of date and never work
[23:48:35] <davidwbarratt>	 yeah that makes a lot of sense
[23:48:59] <davidwbarratt>	 kidna reminds me of how Drupal does it, every adapter is an extension, they just choose to bundle the ones they want to support/test
[23:49:05] <davidwbarratt>	 *kinda
[23:52:20] <davidwbarratt>	 anyways, I'm excited for the future as always!