| [12:15:25] | * shaneonabike1 has quit (Quit: Leaving.) |
| [13:06:41] | * joestewart_ has quit (Remote host closed the connection) |
| [13:06:42] | * joestewart has quit (Remote host closed the connection) |
| [17:20:17] | * anarcat has quit (Ping timeout: 248 seconds) |
| [17:37:30] | * ybabel has joined #aegir |
| [18:13:56] | * anarcat has joined #aegir |
| [19:11:27] | * mstenta_ has quit (Ping timeout: 240 seconds) |
| [19:14:25] | * mstenta_ has joined #aegir |
| [23:31:47] | * kristofferw has quit (Read error: Connection reset by peer) |
| [23:32:03] | * kristofferw has joined #aegir |
| [00:21:57] | * kristofferw has quit (Ping timeout: 240 seconds) |
| [02:33:22] | * 07IABGARJ has joined #aegir |
| [02:33:22] | * joestewart has joined #aegir |
| [04:54:48] | * jeremyr has joined #aegir |
| [04:55:04] | * jeremyr has quit (Client Quit) |
| [05:01:22] | * memtkmcc has joined #aegir |
| [05:03:32] | <helmo42[m]> | Hi all, ergonlog1c bgm jonpugh colan cweagans gboudrias memtkmcc .. and any one else ... Scrum time?. |
| [05:04:22] | <memtkmcc> | hi! |
| [05:04:22] | <hefring> | hi |
| [05:06:18] | <ergonlogic[m]> | hi folks |
| [05:08:07] | <ergonlogic[m]> | anything interesting to report? |
| [05:08:28] | <ergonlogic[m]> | I saw the php7.1 issue recently |
| [05:09:38] | <helmo42[m]> | yes, the first syntax thing I encountered. I'm about in install an extra vagrant box with 7,1 to further test it myself. |
| [05:09:39] | <ergonlogic[m]> | doesn't look too serious though, from my quick skim of the issue |
| [05:09:51] | <ergonlogic[m]> | good idea |
| [05:10:13] | <helmo42[m]> | And also have been playing with phpcs via gitlabCI https://gitlab.com/aegir/hosting_https/-/jobs/36029249 |
| [05:10:41] | <memtkmcc> | Yeah, also, latest Aegir version somehow broke ~140 instances upgrade (quite randomly) under BOA, still trying to figure out why the batch node access in a client feature update could be the culprit |
| [05:10:43] | <helmo42[m]> | I really like the phpcbf part that does automatic style fixing ... |
| [05:11:06] | <ergonlogic[m]> | yeah, I've been using it to lint aegirng |
| [05:11:55] | <helmo42[m]> | memtkmcc: on these instances does a normal node access rebuild work? |
| [05:11:59] | <ergonlogic[m]> | I need to get code coverage working again, though |
| [05:13:00] | <ergonlogic[m]> | memtkmcc: ouch |
| [05:13:17] | <memtkmcc> | helmo42: yes, and some of them are empty test instances — no platforms, no sites and no clients added even |
| [05:13:23] | <helmo42[m]> | It's started via /admin/reports/status/rebuild |
| [05:14:18] | <memtkmcc> | it could be still related to our custom settings for clients (in a feature), but the problem is that we are using exactly the same code and settings everywhere, yet, 140 were consistently broken |
| [05:17:52] | <memtkmcc> | only once we commented out that db update, all 140 could be upgraded, literally zero issues then, we will investigate this further on some test instances with previous version, until we found what could be wrong, I have a few theories, like conflicts with two patches which fixed some edge case problems with clients feature, but could break the way we are using clients in Aegir (with extra roles protection et |
| [05:18:34] | <memtkmcc> | anyway, pretty mysterious |
| [05:19:18] | <colan> | helmo42: the PHPCS tests will surely fail as there's a lot of old code in Aegir 3. |
| [05:19:46] | <ergonlogic[m]> | so, for my part, I've been making progress on aegirng. I've mostly been focused on minimizing Entity-related boilerplate, by moving most stuff to base classes in an API module. I wrote a little script to generate new entity modules from an example model/template, which includes tests for CRUD, revisions and i18n. |
| [05:19:47] | <ergonlogic[m]> | With that in place, I was able to generate Task, Operation, Platform and Site entities, then build out and export Features to capture fields, etc. "Inline Entity Form" allows us to build up a Site form (for example) from Operation entities (like "install site"), which are, in turn, made up of multiple Task entities. Which was basically the plan. |
| [05:21:06] | <helmo42[m]> | colan: it sure will ... hopefully the autofixer can help with that... I;ll start with some smaller contribs |
| [05:23:01] | <ergonlogic[m]> | Next steps include marshalling data from the fields in these various entities to pass on to a Task, and figuring out the best place to store the output log |
| [05:23:53] | <colan> | ergonlogic: is IEF better than, say, Paragraphs for that type of thing? |
| [05:24:24] | <memtkmcc> | question: are we going to make these efforts in parallel, like jonpugh proposed? I mean, 3.x, 4.x and 5.x? https://hefring.mig5.net/bot/log/aegir/2017-10-06#T659834 |
| [05:24:36] | <ergonlogic[m]> | I haven't looked at paragraphs in this context, hang on |
| [05:25:19] | * ybabel has quit (Quit: ybabel) |
| [05:30:32] | * hefring has joined #aegir |
| [05:30:56] | <memtkmcc> | Sounds good to me too, it allows us to make progress on more than one path, at various speeds and phases, without enforcing just a single path/idea at this point |
| [05:31:14] | <colan> | ergonlogic: feel free to ping me later about this stuff as I've had to figure it out for the https://www.drupal.org/project/entity_clone work I've been doing. |
| [05:31:37] | <ergonlogic[m]> | colan: entity_reference_revisions looks like it'd be what we need |
| [05:31:38] | <helmo42[m]> | +1 for the idea of branch maintainers jon_pugh mentioned last week. Of course I (and we probably all) feel responsible for all branches of Aegir. summary: Helmo 3.x, jon 4.x and ergonlogic/colan 5.x |
| [05:31:38] | <helmo42[m]> | Should we document that on http://docs.aegirproject.org/en/3.x/develop/repositories/ ? |
| [05:32:25] | <ergonlogic[m]> | helmo42: +1 |
| [05:33:30] | <colan> | helmo42: good idea. |
| [05:36:49] | <ergonlogic[m]> | colan: entity_clone looks like it'll be useful. Any idea on how to mode Controller and revision forms up to abstract/base classes? |
| [05:37:32] | <ergonlogic[m]> | the routing is currently kinda messy, imo |
| [05:38:37] | <ergonlogic[m]> | I've stripped it down to https://gitlab.com/aegir/aegir/tree/9-build-a-basic-task-entity/profile/... |
| [05:39:11] | <colan> | ergonlogic: haven't played with that, sorry. |
| [05:39:47] | <ergonlogic[m]> | I found that a parameter name seems to be hardcoded to the module name, or something |
| [05:42:28] | <ergonlogic[m]> | anyway, that left me scratching my head, and eventually giving up and keeping a Controller in the entity modules, and re-dispatching to the parent method |
| [05:43:18] | <ergonlogic[m]> | hence a TODO I left to untangle routing: https://gitlab.com/aegir/aegir/blob/9-build-a-basic-task-entity/profile/... |
| [05:44:35] | <ergonlogic[m]> | anyway, there's little enough left in the concrete Entity implementations that it shouldn't be too much hassle to refactor them once that's figured out |
| [05:46:47] | <ergonlogic[m]> | I haven't wrapped my head around what context is available when we're calling `Entity::create()` to inject dependencies |
| [05:55:38] | <jonpugh[m]> | Weird, riot asked me to join a call in this channel? |
| [05:56:23] | <colan> | Maybe one of us accidentally hit the call button? |
| [05:57:07] | <jonpugh[m]> | Awesome, worked on mobile :) |
| [06:00:00] | <jonpugh[m]> | Anyway, I still like the idea of branch maintainers, happy to own 7.x-4.x |
| [06:00:21] | <jonpugh[m]> | I should file an issue for assigning them on d.o? |
| [06:00:56] | <jonpugh[m]> | I also updated an issue on Aegir NG on d.o. Thought we should open up discussion there since there's no commenting on gitlab wikis |
| [06:03:54] | <memtkmcc> | jonpugh: helmo42 proposed to document that on http://docs.aegirproject.org/en/3.x/develop/repositories/ |
| [06:04:41] | <memtkmcc> | and it seems that we all like the idea |
| [06:06:04] | <memtkmcc> | oh, should I use jonpugh[m] perhaps? ^^ |
| [06:06:21] | <jonpugh[m]> | Either worked :) |
| [06:06:30] | <memtkmcc> | nice :-) |
| [06:06:35] | <jonpugh[m]> | I guess riot.im is smart enough to know |
| [06:07:07] | <memtkmcc> | I should look into that irc stuff, I guess |
| [06:07:31] | <jonpugh[m]> | Riot.im is a great free IRC/matrix client |
| [06:07:35] | <jonpugh[m]> | No nonsense setup |
| [06:08:48] | <jonpugh[m]> | Reminder: next Thursday I'll be at Cornell Drupal Camp in Ithaca NY ... Sprints Thursday, sessions Friday, presenting on how a-fro uses DevShop for a big Cornell University site. |
| [06:09:27] | <jonpugh[m]> | Cameron confirmed he'll speak on Aegir at bad camp those same dates. |
| [06:09:54] | <memtkmcc> | Great! |
| [06:09:55] | <jonpugh[m]> | I'll see if I can round up any folks to work on provision 4.x |
| [06:10:41] | <ergonlogic[m]> | jonpugh_: +1 |
| [06:11:47] | <ergonlogic[m]> | colan: fyi: https://www.drupal.org/node/2367235. FWIW, it looks to me like Paragraphs is too concerned with styling, etc. and seems much heavier than IEF |
| [06:11:50] | <hefring> | https://www.drupal.org/node/2367235 => Support entity revision references [#2367235] => 105 comments, 1 IRC mention |
| [06:12:00] | <memtkmcc> | jonpugh: just merge in DevShop, should help gain traction ;-) |
| [06:14:01] | <memtkmcc> | people get very confused about all that various git based stuff in Aegir/DevShop and keep asking when we finally include it in BOA |
| [06:17:47] | <jonpugh[m]> | memtkmcc: easier said than done ;) You should help! |
| [06:17:58] | <jonpugh[m]> | Hosting Git handles most of it at this point |
| [06:18:15] | <jonpugh[m]> | There's a branch of hosting Git to add "git hooks"... |
| [06:18:19] | <helmo42[m]> | The pr above is a first draft, it might needs some explanation of the why and how ... |
| [06:19:16] | <jonpugh[m]> | Then we just need to convert devshop_projects to hosting_projects |
| [06:19:33] | <colan> | we should also explain diffs between boa, devshop & aegir somewhere too then. :) |
| [06:23:14] | <memtkmcc> | jonpugh: but people who like the git workflow, like the DevShop interface too, soo.. :-) Anyway, we want to avoid any confusion for people who want easy to follow Git solution, so we are really torn apart, because DevShop looks like a real Git workflow, while hosting_git looks like an add-on to the classic workflow, and for people who are not familiar with internals, it's very confusing — I'm open to help |
| [06:23:14] | <memtkmcc> | d with this stuff :-) |
| [06:23:23] | <colan> | ergonlogic: Following! It's good to see all of these modules moving towards ERR (except for Field Collection, which is effectively dead in D8: https://www.drupal.org/node/2784931) |
| [06:23:23] | <hefring> | https://www.drupal.org/node/2784931 => Proposal: Deprecate Field Collections for Drupal 8, focus on Entity Reference Revisions & Paragraphs [#2784931] => 57 comments, 1 IRC mention |
| [06:28:54] | <jonpugh[m]> | memtkmcc: it's never going to get fully merged until i get more maintainers. I don't want to be the only maintainers forever |
| [06:32:54] | <memtkmcc> | jonpugh: sounds like a classic chicken/egg dilemma; personally, I would dive head first, and let the world join us, we just need to realize that Git-free workflow is a dead end for amateurs who don't want to learn and what is more important, don't care to follow even the most basic good practices in sites / codebases management |
| [06:34:49] | <memtkmcc> | jonpugh: but I'm OK with supporting both Aegir and DevShop, if joining forces and switching the workflow in Aegir to Git based is too much, at least for now |
| [06:35:47] | <memtkmcc> | I just don't see any bright future for the Git-free or Git-optional workflow |
| [06:36:50] | <memtkmcc> | it's already a Jurassic Park of development and sites maintenance |
| [06:38:39] | <helmo42[m]> | well the 'git free' method currently allows users to use composer and any tool of choice to build a platform ... I kinds like the flexibility it gives there. ... But yes Git and or composer should be the new defaults. |
| [06:39:22] | <memtkmcc> | we are getting RFPs almost daily from businesses and institutions, and every single one lists Git based workflow as a requirement for Drupal hosting |
| [06:39:46] | * anarcat has quit (Read error: Connection reset by peer) |
| [06:40:14] | * anarcat has joined #aegir |
| [06:40:25] | <memtkmcc> | then we are going to explain that, well, yes, we have an optional module for that — you know how it sounds to anyone who know what the Git is |
| [06:43:08] | <memtkmcc> | helmo42: I like the flexibility too, and so far many people seem to like it too, but in fact most of them, if they really use Aegir to manage upgrades properly, struggle with proper workflow, and then many others who like that flexibility, in fact like the fact that they can basically ignore all good practices, and Aegir may still somehow work for them, mainly to deploy new sites |
| [06:49:37] | <memtkmcc> | we want to support and use Drush, Git and Composer, and Drush Make is still useful until D7 is EOL, but people keep telling us how confusing and not-bold-enough the hosting_git is, for example |
| [07:05:09] | <colan> | memtkmcc: https://www.drupal.org/node/2876247 should fix some of the ugliness there |
| [07:05:10] | <hefring> | https://www.drupal.org/node/2876247 => [meta] 3.0 release of Aegir Composer [#2876247] => 8 comments, 2 IRC mentions |
| [07:24:22] | <memtkmcc> | colan: I'm following this, too. Looks like it's going into the right direction, but still needs more love before it's good enough for people who are looking for a complete and easy to understand solution. |
| [07:25:12] | * colan nods |
| [07:28:39] | <memtkmcc> | I mean, when someone needs a Phillips screwdriver, and you offer him a Swiss Army knife, technically it's OK, but the UX is not very friendly. |
| [07:44:46] | * anarcat has quit (Read error: Connection reset by peer) |
| [07:45:23] | * anarcat has joined #aegir |
| [07:46:49] | * memtkmcc has quit (Quit: Leaving.) |
| [08:06:37] | <jonpugh[m]> | Arggg ... |
| [08:07:12] | <jonpugh[m]> | hefring: Tell memtkmcc to get on riot.im so you will always be online! ;) |
| [08:07:12] | <hefring> | jonpugh[m]: I'll pass that on when memtkmcc is around. |
| [08:35:33] | <colan> | hefring: Tell memtkmcc You can use that client for all Drupal IRC channels as I've been doing: https://gist.github.com/fstab/ce805d3001600ac147b79d413668770d#how-to-us... |
| [08:35:33] | <hefring> | colan: I'll pass that on when memtkmcc is around. |
| [08:37:20] | <colan> | If you're still using IRC clients, stop it. :) |
| [08:38:40] | <colan> | That's not necessary here, because we have an actual Matrix room. |
| [08:39:11] | <colan> | They disallowed bridges on most of the other channels though. |
| [08:42:51] | <anarcat> | i still am not using matrix, because most clients take 500+MB of ram :p |
| [08:49:24] | <jonpugh[m]> | anarcat: How much does riot.im eat? |
| [08:54:45] | <anarcat> | jonpugh[m]: that uses electron, so the whole chromium runtime |
| [08:55:13] | <anarcat> | i believe 500MB is exaggerated, but for example, the desktop-signal app takes a whopping 300MB after startup |
| [08:55:19] | <anarcat> | i expect riot.im to take at least as much |
| [08:55:20] | <jonpugh[m]> | Yeah, I just gave up and pin a tab :) |
| [08:56:13] | <anarcat> | eh. |
| [08:56:23] | <anarcat> | i think this is insane, quite frankly |
| [08:56:38] | <anarcat> | i mean it's nice that developers don't have to write per-target apps anymore |
| [08:56:42] | <anarcat> | write once, run everywhere, right? |
| [08:56:45] | <anarcat> | dream of every dev |
| [08:56:58] | <anarcat> | except it's a nightmare for provisioning, packagers and, ultimately, users |
| [08:57:03] | <anarcat> | "why is my machine so slow" |
| [08:57:33] | <anarcat> | "all i'm running is a text editor (atom), a chat client (riot) and a web browser (chromium) yet all my memory is eaten up" |
| [08:57:57] | <anarcat> | and to think people laughed at emacs for eating up ram |
| [08:58:31] | <anarcat> | that was back when the acronym was Eight Megs And Constanstly Swapping |
| [08:58:36] | <anarcat> | 8 megs! |
| [08:59:26] | <anarcat> | now of course emacs takes up a lovely 500MB of ram too |
| [08:59:36] | <anarcat> | but to its defense, it's also my email client |
| [08:59:56] | <anarcat> | on startup, it only takes 80MB of ram, not 300 |
| [08:59:57] | <anarcat> | anyways |
| [09:00:03] | * anarcat just ranting, as always, off topic here |
| [09:00:17] | <anarcat> | drill baby drill |
| [09:02:31] | <jonpugh[m]> | Hahah |
| [09:04:37] | <ergonlogic[m]> | anarcat: wasn't it emacs that led to Zawinski's law: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."? |
| [09:08:19] | <ergonlogic[m]> | fwiw, I think AegirNG will be able to manage emails servers, and so would satisfy that law... |
| [09:32:53] | <anarcat> | ergonlogic[m]: it was |
| [09:34:18] | <anarcat> | ergonlogic[m]: also keep in mind that jwz was a major emacs contributor, and one of the leads of the Xemacs fork |
| [09:34:24] | <anarcat> | so he knew what he was talking about |
| [09:34:34] | <anarcat> | ergonlogic[m]: but AegirNG won't *read* email, will it ;) |
| [09:34:51] | <anarcat> | nowadays, i think the law is irrelevant and should be rewritten, TBH |
| [09:35:12] | <anarcat> | every program expands until it runs in a web browser. the programs that can't are replaced by ones who can. |
| [09:35:20] | <anarcat> | this includes web browsers. |
| [09:39:34] | <anarcat> | interesting |
| [09:39:43] | <anarcat> | turns out there are quite a few native matrix clients here: https://wiki.debian.org/Matrix |
| [09:40:12] | <anarcat> | some of those are probably quite likely more performant... |
