[21:50:21] reminder that in about ten minutes we'll be discussing the following RFC here: [21:50:34] RFC: Provide mechanism for configuration sets for development and tests [21:50:35] https://phabricator.wikimedia.org/T267928 [21:59:29] k, beginning the meeting now (will bounce meetbot if needed) [21:59:37] #startmeeting TechCom RFC discussion [21:59:43] hi! [21:59:50] no meetbot? [21:59:51] hm... maybe didn't start yet :) [21:59:55] I'll bounce I'm logged in [22:00:27] * brennen here [22:00:27] #startmeeting TechCom RFC discussion [22:00:31] hi [22:00:54] third time's a charm? [22:00:56] #startmeeting TechCom RFC discussion [22:01:09] you did jstop/jstart? [22:01:16] nope... ok TimStarling I'm all out of ideas, I did jstart and webservice restart [22:01:48] if all else fails, we can just pretend meetbot is here, and later grep the log for #info and friends [22:01:56] sure :) [22:01:58] #topic RFC: Provide mechanism for configuration sets for development and tests [22:02:01] let's go! [22:02:12] hi kostajh, hi brennen [22:03:02] anyone else who wants to join in, do raise your hand, and kostajh, feel free to kick us off with a quick intro [22:03:08] hello! longma's here too [22:04:06] sure, hopefully the description of the task explains what I'm proposing to do. Not sure I have the right answers for how to implement but that's what this meeting could help with [22:04:52] in short, as a developer I am often commenting out or shifting around parts of my LocalSettings.php depending on what type of set of services and features I am trying to work on [22:05:16] it would be nice to have a more well defined way to do that for local development, that could also be reused in CI for browser and api-testing tests [22:06:44] I saw you had some thoughts on implementation in the exploration section, with tgr commenting on some of that, do you have specific questions? [22:08:04] #startmeeting TechCom RFC discussion [22:08:04] Meeting started Wed Nov 25 22:08:04 2020 UTC and is due to finish in 60 minutes. The chair is milimetric. Information about MeetBot at http://wiki.debian.org/MeetBot. [22:08:05] Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [22:08:05] The meeting name has been set to 'techcom_rfc_discussion' [22:08:08] #topic RFC: Provide mechanism for configuration sets for development and tests [22:08:29] #link https://phabricator.wikimedia.org/T267928 [22:08:43] meetbot's problem was: /data/project/meetbot/bin/meetbot: line 4: syntax error in conditional expression: unexpected token `;' [22:08:44] per Tgr's comments, I think I would like to have something more than just setting MW_CONFIG_FILE [22:08:52] which was correct so I just edited the file to fix the syntax error [22:09:30] I know some folks had ideas re: cookies/headers in our recent techcom chat, maybe they could chime in with those? [22:09:31] I would like to keep my LocalSettings.php file, and add $wgActiveConfigSets = [ 'some-extension-some-config-set-id', 'some-other-config-set' ]; [22:10:09] I'd like to understand how much of this is a generally good idea and how much is a limitation of integration-config's ability to properly write configuration files [22:11:21] I think this would be very useful for local development environments and ad-hoc testing, not just CI [22:11:23] so, if you wanted to, your Selenium test or api-testing test could write out specific configuration and/or copy code into LocalSettings.php that would override services, since both the selenium and api-testing frameworks have access to the file system [22:11:41] it's just kind of a pain, and if you are writing the tests, it would be kind of cumbersome to set up all of that [22:12:01] I think we have a lot of static configuration which in general is not easy to deal with when developing or deploying to multiple environments [22:12:16] i don't have strong opinions on the specifics, but i would agree that a well-defined formal mechanism for this kind of thing would be a big help for development environments. [22:12:20] So I wouldn't want to leave it to CI to set up the environment. Not to mention that I can well imagine the same end-to-end mocha test wanting to test against different server side configurations. [22:12:35] I've also seen that setting up mediawiki with mediawiki-docker is within reach for some less technical people, but it gets a lot more difficult if you ask them to start copy/pasting things into LocalSettings.php. if it was a one-liner to configure their environment so they could review / QA something, that would be pretty nice [22:12:51] ^ [22:13:12] #info I'd like to understand how much of this is a generally good idea and how much is a limitation of integration-config's ability to properly write configuration files [22:13:17] #info kostajh> I've also seen that setting up mediawiki with mediawiki-docker is within reach for some less technical people, but it gets a lot more difficult if you ask them to start copy/pasting things into LocalSettings.php. if it was a one-liner to configure their environment so they could review / QA something, that would be pretty nice [22:14:02] I see this as more or less three different things that are related but perhaps should be treated separately. 1) Configuration presets not unlike what mediawiki-vagrant provided for local development. This has mostly been phased out in favour of better defaults and copy/paste READMEs. While unattractive, I find it a big boost from the vagrant days that I just pop into my LS file and comment in/out sections for specific features. I think [22:14:02] any alternative shoudl be measured against that in terms of ability and cost/benefit. 2) Content fixtures for browser tests being hard or slow to do through api.php, which we'd like to do in a more declarative and batched/server-side way and 3) A way to have clean databases / fresh wikis for browser tests and development, not unlike we do for PHPUnit, but in a way that can persist for several web requests. [22:14:12] #info duesen> I think this would be very useful for local development environments and ad-hoc testing, not just CI [22:14:22] MediaWiki-Vagrant has a .d approach, where you can drop PHP files into a settings.d subdir and they will be executed in an alphabetical order right after LocalSettings. That is quite convenient (not super performant, of course). It doesn't allow for dynamically enabling/disabling sets, which could be nice. [22:15:24] Krinkle: I think just being able to force specific config settings for a specific test would be valuable. [22:15:29] I suppose a fourth one 4) Config presets not just recommended but required for specific tests, incl e.g. ServiceWiring mocks or replacements. [22:15:58] I've experimented with a very simple version of adding some code into LocalSettings.php which takes in environment variables and enables or disables things based on those, but I don't know much about running specific tests on MW [22:17:07] +1 for better defaults, but there are some features we just can't test with selenium because we don't have the ability to override services, and we'd quite like to do that [22:17:24] my local test install has already does have selectable configurations, for example I can do --wiki=mw_ciext to select a CI-like configuration for reproducing CI failures [22:18:02] kostajh: the QA use case might be addressed by a settings file maintained as part of the extension repo like QASettings.php that you'd require_once from LS.php, That's perhaps simple (and immutable) enough in the long run. Considering that editing LS at all remains required for adding an extension. So it's copying 2 lines instead of 1, plus in a way that other devs can update afterwards. [22:18:15] TimStarling: how does that work for web requests? what do you think about doing the same using an http header? [22:18:33] mw supports multiple wikis. typically selected by hostname [22:18:41] well, i guess in your case it's a different wiki, so you'd do it by domain or path, damily style [22:18:47] yes, it selects by hostname [22:18:48] Krinkle: but we have multiple setups to QA [22:19:02] #info +1 for better defaults, but there are some features we just can't test with selenium because we don't have the ability to override services, and we'd quite like to do that [22:19:03] if you are testing something that involves federation (foreign media repos for example) you'll need multiple wikis and have to reserve --wiki for that, though. [22:19:05] kostajh: the file would be local to the extension, mix and match [22:19:10] yea, but setting up a wiki family is complex and costly, and writing tests that requrie a specific family setup is very brittle [22:20:11] Krinkle: concretely, we have suggested edits module on Special:Homepage that has two modes. One loads data from a remote search setup via api.php and the other assumes Elastic is available locally. If I want to have QA setups for both and the ability to test with both setups in CI via Selenium, how would I do that? [22:20:18] I think it's also worth looking at the patch-demo service for the QA use case. Having a set of presets maintained there that you can choose/prepre along side might scale better for this in a way that is less restricting to core long-term. [22:21:00] kostajh: I don't know, but I think that use case naturally requires complexity beyond what is feasible to do with a "simply one-time copy-paste" restriction that you'd envision for QA [22:21:43] but if commenting in/out strings in the array is acceptable, presumably commenting in/out includes is as well. [22:22:04] Krinkle: the proposal is that GrowthExperiments could define two configuration sets, and in LocalSEttings.php one could specify which one to use. In Selenium, you'd use a HTTP header to say which one you want for the test. [22:23:00] the least clear part to me in using config sets for browser tests (whether the mechanism would live in core or elsewhere): how would the test select which set to use? can Selenium ensure that everything (including AJAX requests) has a certain header? [22:23:08] Krinkle: for manual testing, yes. for automated testing, not so much. i'd really like to be able to write a bunch of e2e tests for different setups, and run them all. [22:23:46] #info but if commenting in/out strings in the array is acceptable, presumably commenting in/out includes is as well. [22:23:52] I see. I think that woudl go along well with the notion of fresh DBs for selenium. The HTTP header could e.g. instruct core to: ignore any real LS.php, lazy-create a sqlite install, use the specified PHP file relative to $IP as the settings file for this session. That would also remove any interference from your real settings and thus create something portable cross CI and local dev [22:23:55] #info Krinkle: for manual testing, yes. for automated testing, not so much. i'd really like to be able to write a bunch of e2e tests for different setups, and run them all. [22:23:56] tgr_: from looking at wdio, it seems that you can specify custom headers for every request [22:24:04] tgr_: that'S a good point... I'm thinking about it mostly for mucha tests that directly call apis. browser tests would probably need to use a cookie... [22:24:49] There is another thing about the config sets I'd like to poke at. It'S easy enough to imagine how it can be used to add to config, but not all things can be overwritten. YOu can't un-load an extension, and services can only be re-wired to an extent. [22:25:01] Krinkle: right. The header would say load this config set, and core would 1) evaluate ServiceWiring array that adds/overrides existing services, 2) evaluates a PHP file to set settings, 3) inherits from other config sets that the config set wants to use, etc [22:25:30] How do the config sets interact with LocalSettings, and with extension registration? What's the order of initialization? [22:25:52] #info Krinkle: right. The header would say load this config set, and core would 1) evaluate ServiceWiring array that adds/overrides existing services, 2) evaluates a PHP file to set settings, 3) inherits from other config sets that the config set wants to use, etc [22:25:53] duesen: right, it would be possible to break in various ways. But you can already break your site in multiple ways via LocalSettings.php, so maybe it's not such a problem? [22:25:58] kostajh: I'm unsure as to whether it should/needs to support multiple settings files. that kind of perfect deduplication tends not to work well in my experience but thats implemetnation details :) [22:26:04] duesen: I was thinking they'd be evaluated after everything else in LocalSEttings.php [22:26:39] extension registration is the hard one since that's pure procedural PHP today, unless we want to expose the ExtensionRegistry queue [22:26:48] Krinkle: I'm not sure either, but not everything is a service so we need some way to specify "X config variable should have value Y" [22:27:08] kostajh: both service changes and config changes can be done from a LS.php-like file. [22:27:34] you could have multple of those in your selenium/ directory as well. The test would specify which to use indeed. [22:27:38] kostajh: So, it wouldn't be possible to disable an extension. Maybe we don't need that. [22:27:47] other than that, just apply variables right after (instead of?) running LocalSettings and apply service overrides right after reading the wiring files [22:28:03] But how about the wiring files? You'd have the extension default wiring loaded, and then apply additional wiring?... [22:28:12] If we make it portable and instead of any existing LS.php, you get a lot more consistency and naturally don't have to deal with trying to counter any other extensions that might be on the server. [22:28:22] Krinkle: yeah, I had in mind the use case that config set B extends config set A, but I guess that's also possible with a LS php file [22:28:36] this ability to control settings so freely from a remote client seems kind of scary to me, have you all considered the security implications (I noticed there was a mention in the RFC of having this feature off by default in production) [22:28:38] right, as long as it is local to the repo, you can share as you see fit [22:28:53] I think having QA settings share across extensions would be counterproductive. [22:29:01] milimetric: yep, definitely scary [22:29:14] in unit tests, there's a setup function which overrides services and config and does whatever else it needs to do [22:29:15] Krinkle: we'd have to make the settings fully portable... hm... maybe the platform specific bits could come from .env. [22:29:24] actually yea, that might work [22:30:17] yeah, the fresh db use case is also shared and naturally removes the most complicated part of something you might want to share: the database. wanting a fresh one means setting up a new one anyway, so at that point you have a workgin install and don't need any LS file. [22:30:26] this proposal seems a bit more clunky than that, i.e. having a limited number of configuration sets instead of say one set per test [22:30:31] Krinkle: sharing across extensions could be pretty useful. For example Vector had/has a bunch of config relevant to version 2, some of which broke how our Suggested Edits module functioned. My selenium test would want to specify to use vector's version 2 config set and growth's suggested edits static config set, for example [22:30:57] the client would not be able to control settings, just select sets of predefined settings. While I agree it should be feature-flagged, it's not that scary. [22:31:09] I suppose many tests would use the same base config set and not need something extra/different [22:31:20] apergos: yep, that's my thought [22:31:46] if selenium specifies PHP setup code to run then at least there is clarity over the security model [22:31:52] TimStarling: my understanding is that extensions can define their own config sets, and tests can mix and match. a separate config for each test would be a lot i think [22:31:56] e.g. the header or cookie format could specify "it's time for testing", "here is my setting file to use instead", and "this is the start of a session" and result in a cookie response that will pin you to that, e.g. an ID that maps to the sqlite tmp file. Then subsequent reqs use the same tmp db and you keep reading the smae header/cookie for which settings file to use. [22:32:10] #info TimStarling: my understanding is that extensions can define their own config sets, and tests can mix and match. a separate config for each test would be a lot i think [22:32:32] #info e.g. the header or cookie format could specify "it's time for testing", "here is my setting file to use instead", and "this is the start of a session" and result in a cookie response that will pin you to that, e.g. an ID that maps to the sqlite tmp file. Then subsequent reqs use the same tmp db and you keep reading the smae header/cookie for which settings file to use. [22:32:48] Krinkle: I'm not so sure about disregarding existing LS file. Worth thinking through some more [22:33:27] quick note that we're about halfway through, time to think about what we'd like to accomplish (though it seems we're having a nice discussion so far, good job everyone!) [22:33:34] I don't really want sqlite to be linked into that because I would have to start ranting about sqlite's shortcomings [22:33:43] if config sets are just files / groups of files then having test-specific ones is not problematic. [22:34:34] sqlite/clean DBs should just be handle via service overrides, IMO. There is no need for a dedicated mechanism. [22:34:49] I don't think we should run tests against sqlite [22:34:57] agreed with Tgr about that [22:35:38] #info TimStarling> I don't think we should run tests against sqlite [22:35:47] another aspect of this is discoverability. this goes back to Krinkle's point about having service and config overrides in a single PHP file. it would be nice if there was a maintenance script for example that could show me config sets and the services and config variables they override [22:36:05] do you have an alternate suggestion for spinning up a new db? new mariadb/mysqldb from scratch might be quite heavy [22:36:21] have you benchmarked it? [22:36:22] hm, we do a lot of testing against sqlite for some of our services (like AQS) but I guess in this case you're talking specifically about the mediawiki schema and its support for sqlite having shortcomings? Because otherwise it seems pretty fast to me [22:36:46] to me that implies we have a more structured definition for the config sets, with a list of service overrides in one file (like our current ServiceWiring.php) and another file that returns an array of config variables to override, so the keys can be used as metadata for discovery [22:36:47] #info another aspect of this is discoverability. this goes back to Krinkle's point about having service and config overrides in a single PHP file. it would be nice if there was a maintenance script for example that could show me config sets and the services and config variables they override [22:37:25] milimetric: are you using in-memory sqlite, or on-disk? [22:37:34] memory I believe [22:37:35] if you're testing against sqlite, you're not testing against mysql. They're not the same, you could be missing bugs [22:37:35] yeah, we are basically talking about two arrays here, one is like InitializeSettings, the other one is like ServiceWiring [22:37:41] I'm not sure I follow the database reinitialization discussion, but I don't think it follows from this proposal? [22:37:46] tgr_: yeah [22:37:49] apergos: TimStarling: our tests became significantly faster when they switched from sqlite (on tmpfs) to mariadb (with datadir on tmpfs) [22:37:52] I did this in 2013 [22:37:57] and a lot of time is wasted wrestling with sqlite's stupid concurrency model when just using mysql from the start would fix it [22:37:58] this is speaking about phpunit integration tests [22:38:00] milimetric: that would be fast. but for most e2e tests, you need state to persist between requests. so in-memory wouldn't work [22:38:05] so not even about concurrency [22:38:14] aha, gotcha [22:38:33] Krinkle: gtk, and TimStarling I have not done timing tests one way or another, but if it's not germane to the rfc we ca also skip over [22:39:09] mysql is pretty fast if it's running on a tmpfs or under eatmydata [22:39:12] I suppose for mariadb/mysql, a tmp db would have to be "real" and require create db rights, and then we'd remember to tear it down the same way we'd remove the sqlite file. [22:39:35] (see above, Kosta is not sure how this is relevant) [22:39:46] yeah, db creation isn't a significant time sink right now in CI. it's a second or so, and it'd likely be quicker if it's not through install.php but actually a clone of an existing schema [22:39:54] we already have a setup via quibble and integration/config that sets up various DB backend jobs for patches (for the testing component) [22:39:54] by the way, from my experience with api-testing, having an empty database isn't really needed. just have your framework randomize all identifiers (user names, page names), then you have a clean slate for your tests. [22:40:12] But sometimes is very useful to be able to load a database that contains quite a bit of data, quickly [22:40:34] a mysql data directory and an sqlite data file seem conceptually similar to me [22:40:46] the main reason I resisted against mysql for this use case is because while it's easy for CI, it's not to easy for local dev, since that would mean knowing where and what to contact, which varies. and I kinda like not needing LocalSettings.php, but I guess we could use it still. [22:40:51] you can destroy a mysql data directory, recreate it with mysql_install_db [22:41:00] i propose we move on from the db type it would have [22:41:00] TimStarling: sure, i didn't mean that as an argument for sqlite. [22:41:00] come to think of it, SiteConfiguration is already an implementation of config sets, we could have half an eye towards eventually replacing it with something more standard [22:41:19] tgr_: OH! [22:41:28] #info come to think of it, SiteConfiguration is already an implementation of config sets, we could have half an eye towards eventually replacing it with something more standard [22:41:30] #info come to think of it, SiteConfiguration is already an implementation of config sets, we could have half an eye towards eventually replacing it with something more standard [22:41:34] :) [22:41:35] :P [22:42:17] SiteConfiguration is declarative rather than procedural, which reminds me of the point I made in the techcom meeting about that [22:42:28] That'S a very interesting perspective, but also massive skope creep... [22:43:05] it's meant to select configuration for wikis within a farm, which I think was already ruled out [22:43:07] So, going back to the original proposal... [22:43:46] It provides a bunch of tags which can apply to a request and they switch config settings on and off. The tags are deterministic for a given wiki, but that's not really inherent in the design. [22:43:52] Why would we NOT want to go with config sets as proposed by Kosta? Are there any serious problems with the approach as proposed? [22:44:05] anyway, yeah, big scope creep, just somthing to have in mind in the long term. [22:44:24] #info anyway, yeah, big scope creep, just somthing to have in mind in the long term. [22:44:37] #info Why would we NOT want to go with config sets as proposed by Kosta? Are there any serious problems with the approach as proposed? [22:45:23] ^ a good question with 15 minutes left [22:46:46] it's probably fine as long as there is no production impact and it's relatively well isolated/factored [22:47:03] is the abandoned WIP change still a good indication of how it will work in core? [22:47:17] TimStarling: what about your thoughts on having it easy to reason about the config and declarative vs imperative [22:47:47] TimStarling: not really, that was going in a somewhat different direction [22:48:13] if I think about it as config, I want it to be declarative, but if I think about it as test setup, I want it to be procedural [22:48:39] because tests don't really have rules and need to be flexible, right? [22:48:50] #info if I think about it as config, I want it to be declarative, but if I think about it as test setup, I want it to be procedural [22:49:29] for browser tests the browser would somehow indicate to MediaWiki which sets to enable. That would limit how procedural it can be. [22:50:17] tgr_: as long as we're setting config sets via request headers, we could probably also justify overriding individual config variables via request header as well [22:51:06] so, an extension might have a config set used by 10 tests, but then several of those tests modify individual config flags if needed. could get pretty messy though. [22:51:31] I think the common use case would be various combinations of feature flags [22:51:35] I wouldn't go there, but regardless, would require a JSON-ish transfer format, couldn't really control ordering... so I don't think it could be as procedural as PHPUnit [22:51:51] my knee jerk reaction is to not go there (specific config vars in headers) but have predefined sets only [22:51:59] +1 [22:52:05] +1 [22:52:20] #info my knee jerk reaction is to not go there (specific config vars in headers) but have predefined sets only [22:52:21] the primitive of loadable config files / sets seems powerful enough to start with [22:52:29] heh, I already felt it was wrong as I was typing it out :P [22:52:39] that would also address service wiring/mocking, if we make it procedural [22:52:50] if not, then you'd need something different for that [22:53:02] and also something diferent for data fixtures and fresh DBs [22:53:07] if it's important enough to write a test for then it's worth making the specific config set for [22:53:17] ok, ultimately my interest in this is the elegance of the mediawiki core code and I don't want to block people from writing tests in the way they want to write them [22:54:42] so I would like to see a WIP patch for MW core so that I can review it on that basis [22:55:01] I would think it could be done in an elegant way. I think we already have a config set, "default", which is loading the values in extension.json and the ServiceWiringFiles, so we "just" need to provide the ability to create multiple types of those configs [22:55:19] basically we'd have 1) a standard file format for config overrides and service overrides 2) some whitelist mechanism for those files 3) some mechanism for selecting such file, maybe via HTTP header 4) entry points (right after LocalSettings + somewhere during serbice initiation) where the selected files are applied [22:55:25] kostajh: do you have enough direction on tgr's point about headers/cookies and limitations to using those in different network topographies? [22:55:33] that is relativly elegant, I think [22:55:47] #info I would think it could be done in an elegant way. I think we already have a config set, "default", which is loading the values in extension.json and the ServiceWiringFiles, so we "just" need to provide the ability to create multiple types of those configs [22:55:53] #info basically we'd have 1) a standard file format for config overrides and service overrides 2) some whitelist mechanism for those files 3) some mechanism for selecting such file, maybe via HTTP header 4) entry points (right after LocalSettings + somewhere during serbice initiation) where the selected files are applied [22:56:01] milimetric: yeah, plus Krinkle made a point earlier about setting a cookie for dealing with AJAX requests [22:56:19] k, meeting's over in a few minutes, but do feel free to stick around and discuss [22:56:25] maybe keeping 3) flexible would be nice, so the same mechanism can be reused for other things like wiki farms. But that's very optional. [22:58:07] the idea of a "default" config set doesn't really resonate with my desire for low production impact (performance and complexity) but maybe when I see the code I'll understand why we need that [22:58:33] isn't the "default" set just LocalSettings.php? [22:58:53] (that's how I understood what Kosta was saying) [22:59:17] hm i guess for extensions, the default is really what's in extension.json... [22:59:19] sorry, I mean conceptually we already have a default config set which is what extensions put in the "value" field in extension.json [22:59:21] right, the RFC proposed $wgAllowConfigSetsOverrideFromRequest and I imagine the production impact of this will be to check that global, the end [22:59:33] oh wait... [23:00:05] kostajh: perhaps we can recycle the extension.json format for the config sets? extension.json can already do config, hooks, services, etc... [23:00:20] #info kostajh: perhaps we can recycle the extension.json format for the config sets? extension.json can already do config, hooks, services, etc... [23:00:27] duesen: yes, that is what I was proposing (or did I not write that) [23:00:41] #endmeeting [23:00:41] Meeting ended Wed Nov 25 23:00:41 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [23:00:41] Minutes: https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-11-25-22.08.html [23:00:41] Minutes (text): https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-11-25-22.08.txt [23:00:41] Minutes (wiki): https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-11-25-22.08.wiki [23:00:42] Log: https://tools.wmflabs.org/meetbot/wikimedia-office/2020/wikimedia-office.2020-11-25-22.08.log.html [23:00:43] we need a way to do it in core as well, though [23:01:03] kostajh: i might have missed it, there was a lot going on here [23:01:04] (I gotta run, but thank you so much everyone for your thoughts and your work) [23:01:19] milimetric: thank you for chairing! [23:01:48] it's easy to just load a fake extension, but getting intimate with ExtensionProcessor.php may be a bit more complicated [23:02:08] the coding style is pretty direct, rather than abstract, it's not that easy to extend it [23:02:10] hm, I guess reusing the flexible merging logic in extension.json could be valuable [23:02:11] duesen: no, I didn't write it, sorry. But yes I was thinking extension.json is the logical place to add some definitions [23:02:55] kostajh: ah... my thought wasn't to put config sets into extension.json. My thought was to have one extension.json for each config set. [23:02:57] kostajh already did a WIP patch to it so probably knows what I mean [23:03:14] TimStarling: yes, I think what you said is correct [23:04:47] duesen: I was thinking you'd have "ConfigSets" as an array where each item has a key for servicewiringfiles, config overrides (array or point to PHP file), id for discovery, and other config sets to inherit from (array) [23:05:58] * brennen has to run - will be watching this with interest / attempting to get head around it. [23:07:17] same (need sleep) [23:07:47] kostajh: what if we just pretended each config set was an extension, and loaded an extension.json file for it? [23:07:49] I'm off as well. I can try to get a WIP patch for more discussion, maybe next week [23:08:00] yea, i need to log off too [23:08:23] thanks everyone! bye [23:16:21] [2020-25-11T22:06] /data/project/meetbot/bin/meetbot exited with code 2. Respawning... [23:16:27] what kind of date format is that?