[21:34:34] | <symbioquine[m]> | ACTION uploaded an image: (662KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/SzStDgZHlwJ... > |
[21:42:38] | <mstenta[m]> | Whoa |
[21:43:01] | <mstenta[m]> | That's so cool symbioquine!!! |
[21:43:57] | <symbioquine[m]> | Thanks! 😄 |
[01:36:36] | * jonasbits has quit (Ping timeout: 240 seconds) |
[01:38:09] | * jonasbits has joined #farmos |
[08:51:32] | <mstenta[m]> | I like that it includes pathways! |
[10:10:38] | <symbioquine[m]> | Yeah, that seems pretty important |
[10:12:41] | <symbioquine[m]> | I haven't gotten the UX quite right yet though. I don't like how those input boxes end up overlapping at some zoom levels... |
[10:20:04] | <MarcosCarballal[> | Ooh that looks really cool! |
[12:03:39] | <paul121[m]> | Tugboat is suffering from a domain registrar issue right now... because of this the demo site probably wasn't working the past couple days. I just updated things to use their new/temporary tugboatqa.com domain. Things are working again but let me know if ya have any issues! |
[12:04:35] | <paul121[m]> | Because of this issue they will likely support this domain for quite awhile, if not forever |
[12:14:49] | <paul121[m]> | mstenta symbioquine is there a reason we configured the phpunit tests to all stop if any one of the DBs fails? Mariadb has been failing a lot recently. It would be valuable to see the others passing |
[12:16:16] | <paul121[m]> | I think this would also be important if you were trying to debug an issue that was specific to a certain DB... eg: right now you wouldn't know if it worked on Postgres, you would only know that it failed on Mariadb? |
[12:39:43] | <mstenta[m]> | I think I decided to make one fail all because the next step was going be automatic delivery to docker hub |
[12:40:33] | <mstenta[m]> | But maybe that's not necessary. Or rather: maybe it won't run the last job if any of the matrix jobs before it fail |
[12:40:46] | <mstenta[m]> | (last job being the packaging one) |
[12:41:14] | <mstenta[m]> | I agree it's annoying that mariadb fails cause others to abort |
[12:41:32] | <mstenta[m]> | I wish we could figure out the mariadb issue... I started digging into it a few weeks ago but didn't get very far |
[13:49:04] | <mstenta[m]> | paul121 symbioquine I took a pass through the remaining "stable blocker" issues, and bumped a bunch of them to "v1 parity" instead |
[13:49:14] | <mstenta[m]> | The remaining list is pretty short |
[13:49:46] | <mstenta[m]> | Curious if we can come to a decision on this one: https://www.drupal.org/project/farm/issues/3256745 |
[13:50:39] | <mstenta[m]> | Any strong opinions either way? |
[13:54:29] | <paul121[m]> | I don't have a strong opinion. I believe we also delete the simple_oauth default client in `farm_api_install()` - might need to think if that moves as well |
[13:54:58] | <paul121[m]> | Maybe `farm_api` should be optional itself |
[14:23:29] | <mstenta[m]> | I'd be fine leaving this as-is (closing that issue as "won't fix") |
[14:24:29] | <mstenta[m]> | I could see an argument for `farm_api` being optional - but that feels a like a bit of a bigger decision - not gonna worry about that right now :-) |
[17:03:27] | <symbioquine[m]> | I think it is probably a good idea to keep that issue and decouple the "core API module" from the "how API clients authenticate module(s)". Though I would argue that it might make sense to provide a configuration that works "out of the box" for clients like Field Kit or ad-hoc scripting use-cases. |
[17:04:02] | <symbioquine[m]> | We shouldn't create configuration/administrative barriers for users to do things via Field Kit or scripting that they are able to do through the UI by clicking. |
[17:21:13] | <mstenta[m]> | Yea agreed - I'm in favor it it being enabled by default. |
[17:21:19] | <mstenta[m]> | (it == the default `farm` client) |
[17:21:47] | <mstenta[m]> | As for Field Kit, the client for that is provided by the `farm_fieldkit` module, which is not currently enabled by default (although we can reassess that when field Kit v2 is stable) |
[17:22:21] | <symbioquine[m]> | ah, I see |
[17:22:56] | <mstenta[m]> | So... as for the d.o issue... should we just leave it open but remove the "stable blocker" tag? If the next step is to just split it out to a separate module, but still enable it by default, then it would be functionally the same as what we have now, and I think that would be a non-breaking change either way |
[17:23:14] | <symbioquine[m]> | Makes sense |
[17:23:19] | <mstenta[m]> | (My immediate desire is to close/bump all the stable blockers) |
[17:25:03] | <mstenta[m]> | (I plan to ask your thoughts on the others next... 😄) |
[17:25:27] | <symbioquine[m]> | mstenta[m]: I need to double-check, but I guess I should go this direction for my WFS module - i.e. include a dedicated OAuth client configuration that makes QGIS able to connect out of the box once the WFS module is installed. (I seem to remember that there was an issue with the default `farm` client for that purpose.) |
[17:25:56] | <mstenta[m]> | Oh yea I think that would be a good idea (dedicated client) |
[17:26:31] | <mstenta[m]> | Alright, well unless paul121 has any objections I'll remove the "stable blocker" tag from https://www.drupal.org/project/farm/issues/3256745 |
[17:28:20] | <mstenta[m]> | As for the other issues... |
[17:28:33] | <mstenta[m]> | I'd like to take a stab at this one before 2.0.0: https://www.drupal.org/project/farm/issues/3253581 |
[17:28:43] | <mstenta[m]> | (as we discussed on the last call) |
[17:29:28] | <mstenta[m]> | I'm curious if we should keep this in the "stable blocker" list, or if it's minor enough to unblock and fix later: https://www.drupal.org/project/farm/issues/3252092 |
[17:30:12] | <mstenta[m]> | Also curious if we should try to do this before 2.0.0: https://www.drupal.org/project/farm/issues/3244733 |
[17:32:46] | <symbioquine[m]> | mstenta[m]: It seems like a bit of an edge-case bug (hard to imagine how someone would depend on that validation case failing and be surprised/annoyed it it stops failing), but still an important fix... |
[17:33:18] | <mstenta[m]> | It's more of a "potential data loss" bug than just validation |
[17:34:24] | <mstenta[m]> | But I agree - it would probably be pretty rare in practice |
[17:34:39] | <mstenta[m]> | And I think the same issue has existed since v1, so... |
[17:35:44] | <symbioquine[m]> | <mstenta[m]> "I'm curious if we should keep..." <- It has a pretty easy work-around right? i.e. just set/unset the parent/weight via the individual asset edit page. |
[17:36:04] | <mstenta[m]> | > Also curious if we should try to do this before 2.0.0: https://www.drupal.org/project/farm/issues/3244733 |
[17:36:05] | <mstenta[m]> | Personally I think we can bump this one to post 2.0.0... I don't think it would make a difference either way |
[17:36:11] | <mstenta[m]> | Curious what paul121 thinks |
[17:36:45] | <mstenta[m]> | Re: #3252092 - yea it's easy to avoid/fix I think... IIRC the concern is that you might not notice it happen |
[17:37:01] | <mstenta[m]> | Again... maybe pretty minor |
[17:37:43] | <symbioquine[m]> | Yeah, could be annoying to later discover that you'd changed a bunch of parent-child relationships without intending |
[17:37:56] | <mstenta[m]> | Yea |
[17:37:56] | <mstenta[m]> | Unfortunately it also might not be an easy bug to fix |
[17:38:04] | <mstenta[m]> | I think I traced it to the upstream JS lib |
[17:38:38] | <mstenta[m]> | (I should say... maybe not easy to fix in our repo... maybe not bad if we fix it upstream... didn't get that far in my investigation) |
[17:38:39] | <symbioquine[m]> | Regarding "stable blockers" in general, I'd be a lot more nervous about any that might involve data-model or API changes. |
[17:39:06] | <mstenta[m]> | Yea agreed - and there aren't any of those... we resolved all data model/API stuff with beta |
[17:39:24] | <mstenta[m]> | The "stable" idea was always a bit of a misnomer |
[17:39:33] | <mstenta[m]> | Beta is stable :-) |
[17:39:49] | <mstenta[m]> | So this is just an opportunity for last-minute triage mainly :-) |
[17:40:09] | <symbioquine[m]> | Makes sense |
[17:40:54] | <mstenta[m]> | I think I'll go ahead and remove "stable blocker" tag from https://www.drupal.org/project/farm/issues/3244733 and https://www.drupal.org/project/farm/issues/3252092 |
[17:41:13] | <mstenta[m]> | paul121: if you feel strongly please add it back :-) |
[17:44:49] | <mstenta[m]> | Oh right... just found paul121's comment on the two-column layout one... |
[17:44:49] | <mstenta[m]> | > I'd like to consider this a stable blocker :-) |
[17:44:49] | <mstenta[m]> | :-) |
[17:45:14] | <mstenta[m]> | Any interest in tackling that one paul121 ? |
[17:46:26] | <mstenta[m]> | The only other one to figure out is https://www.drupal.org/project/farm/issues/3172315 - which also needs paul121's input :-) |
[17:46:34] | <mstenta[m]> | Sorry paul121 😆 |
[17:47:30] | <mstenta[m]> | If we can bump either/both of those to post 2.0.0 - let's do it! Otherwise, let's make a plan and get them done. |