| [21:08:27] | <symbioquine[m]> | https://www.drupal.org/project/drush/issues/1761910#comment-7599407 <-- The main critical comments' arguments seem flawed. That suggests that forks actively discourage collaboration on larger feature changes and that pull requests are mutable only by a sole author. |
| [21:12:54] | <symbioquine[m]> | Instead forks allow for arbitrary collaboration structures. One could invite collaborators to build up a larger change in a branch of the fork or accept pull requests to that branch until a larger change is ready for being pulled back into the main repository. |
| [21:15:47] | <symbioquine[m]> | Also anyone is always welcome (license permitting) to clone an existing unmerged pull request, add or modify it, and send a new pull request to supersede it. This is hypercollaborative. |
| [05:34:18] | * dazinism has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:20] | * pcambra[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:20] | * pllagn[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:21] | * skalakm[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:21] | * skipper_is[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:22] | * holz[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:28] | * jgaehring[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:29] | * JulianF has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:29] | * farmtech[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:29] | * maroci[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:29] | * jolau[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:33] | * wombat83[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:35] | * mstenta[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:35] | * calbasi_matrix has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:36] | * zedrickr11[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:36] | * kunigunde[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:36] | * munjoma[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:36] | * symbioquine[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:34:48] | * paul121[m] has quit (Quit: Bridge terminating on SIGTERM) |
| [05:44:29] | * farmtech[m] has joined #farmos |
| [05:44:51] | * jolau[m] has joined #farmos |
| [06:13:47] | * dazinism has joined #farmos |
| [06:19:34] | * mstenta[m] has joined #farmos |
| [06:19:35] | <mstenta[m]> | symbioquine: Yea I disagree with that argument as well. And so did most of the Drupal community. It's now possible to open "issue branches" and then "merge requests" (equivalent to pull requests) from Drupal.org issues. |
| [06:19:51] | <mstenta[m]> | https://www.drupal.org/docs/develop/git/using-git-to-contribute-to-drupa... |
| [06:20:52] | <mstenta[m]> | Also: I am 100% in favor of allowing GitHub pull requests, even if we encourage people to post originating issues elsewhere. I wouldn't want to turn off the PR feature. |
| [06:28:58] | * kunigunde[m] has joined #farmos |
| [06:28:58] | * pcambra[m] has joined #farmos |
| [06:28:58] | * JulianF has joined #farmos |
| [06:28:58] | * pllagn[m] has joined #farmos |
| [06:28:58] | * calbasi_matrix has joined #farmos |
| [06:29:04] | * wombat83[m] has joined #farmos |
| [06:29:04] | * zedrickr11[m] has joined #farmos |
| [06:29:04] | * holz[m] has joined #farmos |
| [06:29:04] | * skipper_is[m] has joined #farmos |
| [06:29:04] | * paul121[m] has joined #farmos |
| [06:29:05] | * symbioquine[m] has joined #farmos |
| [06:29:05] | * skalakm[m] has joined #farmos |
| [06:29:05] | * munjoma[m] has joined #farmos |
| [06:29:12] | * jgaehring[m] has joined #farmos |
| [06:29:12] | * maroci[m] has joined #farmos |
| [10:16:14] | <mstenta[m]> | symbioquine and paul121 : just thinking more about all this... |
| [10:16:58] | <mstenta[m]> | (actually i'll post this to the github issue) |
| [12:41:56] | <symbioquine[m]> | @mst |
| [13:13:11] | <mstenta[m]> | Thanks for the feedback symbioquine ! I made all the changs. :-) |
| [13:13:17] | <mstenta[m]> | * Thanks for the feedback symbioquine ! I made all the changes. :-) |
| [16:47:18] | <mstenta[m]> | Honestly symbioquine the lack of markdown is one of my biggest complaints with drupal.org too :-) |
| [16:47:46] | <mstenta[m]> | (He says as he changes backticks to `<code>` for the millionth time) |
| [16:49:02] | <mstenta[m]> | There is an open request to add Markdown support... (couldn't find it at quick glance, but I'm subscribed to it, and it occasionally makes some progress, so I think it's still alive) |
| [16:59:06] | <symbioquine[m]> | Just curious, why does the dev composer.json file need to be in its own repository - instead of, say, a subdirectory or under `docker/dev/`? |
| [17:03:02] | <mstenta[m]> | Good question... I've actually thought more recently about merging it in. The main challenge (iirc) is that Packagist.org requires it to be in its own repo |
| [17:03:34] | <mstenta[m]> | The way Drupal.org gets around that is with an automated subtree split that breaks up core into multiple child repos and links those in on Packagist |
| [17:04:16] | <mstenta[m]> | https://packagist.org/packages/farmos/project is equivalent to https://packagist.org/packages/drupal/core-recommended |
| [17:04:33] | <mstenta[m]> | Which is technically a separate "package" from farmOS itself (the distribution) |
| [17:05:17] | <mstenta[m]> | So we could consider merging it in and creating a subtree-split automation (perhaps via GitHub Actions) |
| [17:06:26] | <mstenta[m]> | That might be nice, because we could also automatically `git tag` it as well perhaps (eg see: https://github.com/farmOS/farmOS/blob/ac8ca2b57a9230e6d9c87f910626a94221...) |
| [17:07:16] | <mstenta[m]> | The idea of a "project" as separate from the "distribution package" itself allows each person who is hosting farmOS (or Drupal more generally) to manage their own `composer.json` for *their deployment* |
| [17:07:34] | <mstenta[m]> | Which simply pulls in farmOS as a dependency |
| [17:08:49] | <mstenta[m]> | If you're self-hosting via the `farmos/farmos:2.x` Docker image, and not bind-mounting the whole codebase, you don't have control over this, and the project is auto-built for you using the default `composer.json` |
| [17:09:07] | <mstenta[m]> | But if you do bind-mount the codebase, then you can take control over it, commit it to it's own repo, etc |
| [17:09:27] | <mstenta[m]> | This can be useful if you want to create a custom deployment that automatically includes other modules |
| [17:09:40] | <mstenta[m]> | You add those dependencies to the *project* `composer.json`, not farmOS's |
| [17:10:13] | <mstenta[m]> | You probably already understand all this - just talking out loud as a way for me to refresh myself, and document for others... :-) |
| [17:28:08] | <symbioquine[m]> | No, that's helpful. I have very patchy - and probably flawed - understanding of the overall PHP packaging ecosystem :) |
| [17:28:37] | <mstenta[m]> | Haha I've had to get up to speed myself a lot recently :-) |
| [17:29:13] | <symbioquine[m]> | Would it work to have a 2.x-dev branch of the main repo with the main difference being the composer.json file? |
| [17:30:14] | <symbioquine[m]> | Hmmm, actually idk if that would solve the problem I was after... |
| [17:34:56] | <mstenta[m]> | What problem are you looking to solve? Just general cleanup of the repos by merging them? Or something else? |
| [17:36:01] | <mstenta[m]> | (I would love to merge them myself haha) |
| [17:36:16] | <symbioquine[m]> | Well, it's a little frustrating for testing changes that involve upgrading packages to need to push to two separate repos and override the `PROJECT_REPO` variable during testing - which means I need to push a version without that once I get the change ready to send a pull request. |
| [17:37:14] | <mstenta[m]> | Huh not sure I understand |
| [17:37:15] | <symbioquine[m]> | e.g. |
| [17:37:15] | <symbioquine[m]> | * https://github.com/symbioquine/farmOS-composer-project/commit/973013df12... |
| [17:37:15] | <symbioquine[m]> | * https://github.com/symbioquine/farmOS/commit/db54d581de7777aafb48ca8c776... |
| [17:37:56] | <mstenta[m]> | oh i see yea... |
| [17:38:16] | <mstenta[m]> | sort of a specific case, hopefully not something that comes up often |
| [17:38:28] | <mstenta[m]> | (right? or maybe i'm overlooking a common case) |
| [17:39:04] | <symbioquine[m]> | Well, friction around updating versions of things makes it less likely to happen often. |
| [17:39:36] | <symbioquine[m]> | Also, since it's in a separate repo, the tests don't get triggered when new changes are pushed to `farmOS/composer-project` |
| [17:44:30] | <mstenta[m]> | Oh maybe I'm misunderstanding - those tests you were doing were specifically for running tests in parallel? Or is the "updating versions of things" a more general problem - not sure I follow |
| [17:46:00] | <mstenta[m]> | (ah sorry dinner time here... brb) |
| [17:46:11] | <symbioquine[m]> | yeah for this case I was experimenting with running tests in parallel - which requires new dependencies for the dev docker image (with the strategy I was testing there) |
| [17:46:43] | <symbioquine[m]> | No worries :) |
| [17:47:25] | <mstenta[m]> | Cool cool yea... that makes sense I think... I guess my thought is that the times when changing the project `composer.json` and running tests *should* be limited |
| [17:47:35] | <mstenta[m]> | More often you'll be changing deps in the farmOS `composer.json` |
| [17:47:42] | <mstenta[m]> | (I think?) |
| [17:48:18] | <symbioquine[m]> | hmmm... interesting. I'm not sure... |
| [18:11:30] | <mstenta[m]> | The farmOS `composer.json` is basically for "farmOS dependencies", but the "project" `composer.json` is for "deployment dependencies"... sort of... |
| [18:13:39] | <mstenta[m]> | It makes sense to think of "the testing environment" as more on the "deployment" side of things |
| [18:15:10] | <mstenta[m]> | Hence why the `drupal/core-dev` dependency is in https://github.com/farmOS/composer-project instead of https://github.com/farmOS/farmOS |
| [18:15:26] | <mstenta[m]> | https://github.com/farmOS/composer-project is really just a "recommended project template" for a farmOS deploymenyt |
| [18:15:43] | <mstenta[m]> | You don't need to use it if you don't want to. But we do in the Docker images. |
| [18:16:07] | <symbioquine[m]> | huh, ok I guess I'm lost again |
| [18:16:33] | <mstenta[m]> | https://www.drupal.org/docs/develop/using-composer/starting-a-site-using... |
| [18:17:25] | <symbioquine[m]> | But, on a positive note; |
| [18:17:28] | <symbioquine[m]> | ACTION uploaded an image: image.png (11KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/YGAVZCXebYGTCmKc... > |
| [18:17:33] | <symbioquine[m]> | https://github.com/symbioquine/farmOS/runs/1444894213?check_suite_focus=... |
| [18:17:36] | <mstenta[m]> | Maybe I'm not describing my thoughts very well haha |
| [18:17:47] | <symbioquine[m]> | Now, if only I can fix that exit code... :) |
| [18:18:07] | <mstenta[m]> | Wait what am I looking at? |
| [18:18:28] | <symbioquine[m]> | The tests completed in 1 minute and 12 seconds there. |
| [18:19:18] | <mstenta[m]> | 😳 |
| [18:19:19] | <mstenta[m]> | WOW! |
| [18:19:33] | <mstenta[m]> | Oh that's with them running in parallel?? |
| [18:19:51] | <symbioquine[m]> | I think paratest is just returning exit code 1 because of the schema version reference for phpunit.xsd |
| [18:20:01] | <symbioquine[m]> | <mstenta[m] "Oh that's with them running in p"> Yep |
| [18:20:05] | <mstenta[m]> | Amazing!! |
| [18:20:25] | <symbioquine[m]> | They're not heavily processor bottlenecked yet so we don't need that parallel jobs strategy I was proposing. |
| [18:20:41] | <mstenta[m]> | Oh interesting - so how does this work? |
| [18:20:47] | <symbioquine[m]> | Just some changes to allow using paratest; https://github.com/paratestphp/paratest |
| [18:21:33] | <mstenta[m]> | I haven't heard of paratest |
| [18:21:44] | <mstenta[m]> | It's a drop-in replacement for phpunit? |
| [18:22:03] | <symbioquine[m]> | It's a sort of wrapper that launches multiple instances of phpunit in parallel. |
| [18:22:20] | <mstenta[m]> | Oh wow |
| [18:22:20] | <symbioquine[m]> | But yeah, the invocation is largely a drop-in replacement for phpunit. |
| [18:22:24] | <mstenta[m]> | Neat! |
| [18:22:28] | <symbioquine[m]> | yeah |
| [18:23:27] | <symbioquine[m]> | Change needs a bit more work and I might need to consult with you on how reasonable those dependency upgrades are... but I'm hoping to be able to get a PR out in the next day or two :) |
| [18:23:39] | <mstenta[m]> | Ok |
| [18:23:56] | <mstenta[m]> | Might not be able to look at it right away - but looking forward to it! |
| [18:24:50] | <symbioquine[m]> | No worries. I'll post to https://www.drupal.org/project/farm/issues/3183682 once I have a PR needing feedback. |
| [18:25:00] | <mstenta[m]> | Cool! |
| [18:25:10] | <mstenta[m]> | What dependency upgrades are necessary? |
| [18:25:14] | <mstenta[m]> | I saw Drupal 9.2 in there? |
| [18:25:19] | <symbioquine[m]> | https://github.com/symbioquine/farmOS-composer-project/commit/973013df12... |
| [18:26:25] | <symbioquine[m]> | Might be a work-around, but paratest seems to mandate some very up-to-date versions of things like phar-io/manifest. |
| [18:26:33] | <mstenta[m]> | Ahhh |
| [18:27:11] | <mstenta[m]> | Which `drupal/core-dev` probably isn't compatible with in 9.0 - makes sense |
| [18:27:26] | <mstenta[m]> | And what does `prophecy-phpunit` do? |
| [18:27:41] | <symbioquine[m]> | <mstenta[m] "Which `drupal/core-dev` probably"> Yeah, that's my guess. |
| [18:27:42] | <mstenta[m]> | We might need to wait until Drupal 9.2 is released |
| [18:27:48] | <symbioquine[m]> | I'll play around with it a bit more since I've learned a bit more about composer since I made that part of the change... |
| [18:28:14] | <mstenta[m]> | But that shouldn't be too long from now, I don't think... and we can probably live with syncronous tests until then, while having this ready to go! |
| [18:28:59] | <symbioquine[m]> | <mstenta[m] "And what does `prophecy-phpunit`"> https://www.drupal.org/project/drupal/issues/3182653 |
| [18:29:01] | <mstenta[m]> | Oh also I wonder: can we have `drupal/core-dev` at 9.2, but Drupal itself at 9.0? |
| [18:29:38] | <symbioquine[m]> | Your guess is better than mine :) |
| [18:29:52] | <mstenta[m]> | Ah cool - might be worth adding a comment above that line in `composer.json` linking to that issue and saying that it's temporary (hopefully) |
| [18:30:01] | <symbioquine[m]> | yep |
| [18:30:14] | <mstenta[m]> | Similar to: https://github.com/farmOS/farmOS/blob/ac8ca2b57a9230e6d9c87f910626a94221... |
| [18:30:22] | <symbioquine[m]> | yeah |
| [18:30:54] | <mstenta[m]> | Did you Drupal core get updated to 9.2 when you updated `drupal/core-dev`? |
| [18:31:03] | <mstenta[m]> | I imagine it probably did... |
| [18:31:20] | <mstenta[m]> | Assuming that Drupal core keeps those two pretty interlinked... but maybe not |
| [18:31:28] | <symbioquine[m]> | Hmmm, I think something broke and I had to bump both together, but I should play around with it a bit more... |
| [18:31:34] | <mstenta[m]> | Cool |
| [18:31:48] | <mstenta[m]> | I'd like to keep farmOS on "stable" Drupal 9 releases unless absolutely necessary |
| [18:31:59] | <symbioquine[m]> | Makes sense |
| [18:32:25] | <symbioquine[m]> | Though, I wonder whether that's essential if it's in a pre-release state itself? |
| [18:32:48] | <symbioquine[m]> | Anyway, gotta run. Thanks for the thoughts/feedback! Should be back online later this evening... |
| [18:33:02] | <mstenta[m]> | Yea maybe not... but if there's nothing that needs it, it's easier to just keep it on stable. So we don't have to remember to change it back if we are ready to release. |
| [18:33:13] | <symbioquine[m]> | true |
| [18:33:18] | <mstenta[m]> | Cool - talk to you later! |
