This is a transcript. For the full video, see The inside story on Drupal.org's coming support for merge requests and issue forks - Tag1 TeamTalk #022.
Preston So: [00:00:00] Hello, and welcome to a very special edition of our show Tag1 TeamTalks. This is talk number three in our mini series with our guests, the Engineering Team of the Drupal Association. My name is Preston So. I'm editor in chief at Tag1 Consulting. I'll be the host of today's episode and moderating it as well.
I'm joined today by three of my dear friends and colleagues in the Drupal ecosystem. First Tim Lehnen, who is the chief technology officer of the Drupal Association. We're also joined today by Neil Drumm, in New York City, who is the senior technologist at the Drupal Association, not too far from where I am as well in New York City.
And we're also joined by Michael Meyers, managing director of Tag1 who joins us from the Berkshires, Massachusetts. And Tim joins us from Portland, Oregon today. So let's just jump right in. I think one of the things that people are really interested in right now as a result of this amazing migration that we've talked about several times now on the Tag1 TeamTalk Show.
Is this migration over to GitLab and the amazing capability that that introduces to the workflows that contributors want to engage with on a daily basis. And one of those of course is the whole merge request paradigm in GitLab. Now, Neil, I understand that you've been doing a lot of recent work on kind of enabling and supporting forks and merge requests in GitLab as, as well as this new project that we spoke about previously, GitLab CI.
So very briefly. I wanted to ask just for those of us who might not know about what forks and merge requests mean, especially those of us who aren't as familiar with GitLab. Why is it that the Community is so excited? Why is it that contributors to Drupal are so excited about ports and requests in the Drupal Community?
What's the history behind this as well. And why is this such a big step for us?
Neil Drumm: [00:01:52] Yeah, so Drupal has had a patch based workflow. So, to contribute to the code, Drupal code base, you would have to make your edits and then, make a patch and upload that. And it's just not a workflow that a lot of people are familiar with.
If they've started development in the since GitLab has existed, or GitHub has existed, so we're looking at modernizing that and really leveraging Git so that people can push their changes to each other. And the maintainers of the project can pull those, merge those into the projects themselves.
Tim Lehnen: [00:02:42] I would, I would add to that. One of the reasons that it's sort of particularly exciting for people like me, who aren't the hardcore of the hardcore engineers or developers is, Yeah, this actually ultimately enables a complete, like end to end contribution in Drupal. All that can be done in the browser.
Like you can start your fork of changes , use the web IDE to, to make your suggested changes, comment on that with the maintainer, all, all getting pushed back to the issue, open your merge request. Have it merged without having to use a command line interface without having to run your local development environment necessarily.
Or any of those things. So I think it'll make it accessible to a lot of folks who want to make smaller changes or make their first change in the Drupal ecosystem, and hopefully make it easier for them to join our community.
Preston So: [00:03:35] I love that. And you know, one thing that I do want to mention is that, you know, I think that the Drupal Association, obviously, with the support of Tag1 has been really working to improve that developer and contributor experience in ways that are really unrecognizable.
From how those previous paradigms were working. And I think that's a huge testament to just how much technical heft is behind this kind of migration. and so we've just talked about merge requests and forks and how they allow for contributors to, as you said Tim, make these small changes and make maintainers' lives easier.
But I also know that there, these issue forks and merge requests are also going to be part and parcel to the existing drupal.org issue queue. Now, I know that one of the things that's always been interesting as a source of both joy and despair has been how to integrate that drupal.org issue queue with some other platform.
So I'm curious, why are we, kind of bringing all of that, those paradigms that GitLab provides into the drupal.org issue queue, as opposed to just migrating over, to GitLab issues. Wouldn't that be easier?
Tim Lehnen: [00:04:49] Good question. I think there are certainly ways in which it would be easier, but there's also some pros and cons to that approach that haven't been totally resolved.
So for example, If we were using GitLab issues, anybody who's used GitHub or GitLab would be totally familiar to them. Right. It's very simple. It's very easy to use. Not hard to do at all, but on the downside, the, the metadata that you can use to organize your, your issues, you know, in Drupal, in our issue queue, you have a component dropdown for what aspects of your project you're, you're working on.
You have a version dropdown to, organize what, what you're filing the issue against. There's sort of limited taxonomies that we currently use to organize things in the Drupal space that you can sort of substitute for in the GitLab space using their custom labels functionality., but I'm not quite sure that it would work at our scale just yet.
And you know, in my own experience, I've never yet seen a GitLab project, or even a GitHub project, I don't think, that had more than like 20,000 open issues on a single project. And Drupal core has that, there's almost 30,000 open and in Drupal core right now, and almost a hundred thousand for Drupal core, just in the total history.
So there's a lot of this metadata and information. That's useful for understanding ,sorting and prioritizing open issues that I'm not quite sure we could replicate yet. And furthermore, the whole contribution credit system, that's part of what we do. just isn't available in the context of, of the, of GitLab issues.
So I think by taking this first step, we can. maximize both what we do well and what happens well, using the GitLab tooling, as well as create a bridge for maybe exploring more of that in the future.
Preston So: [00:06:37] That's very interesting, you know, I think that the, the, you know, the challenges around drupal.org and the fact that, you know, as you mentioned Tim, there are so many open issues, so many artifacts, so many things that we have to consider it makes this something that, you know, we can't just, you know, lift and shift over to a new kind of paradigm for this.
but you know, one of the things that I think would be really useful is to dig into some of the fundamental concepts here. and I think that, you know, for those of us, especially like myself who, you know, I've only used GitLab in passing. Only in certain situations I've never actually used a merge request workflow all the way through, let's start with some simple term definitions, I think.
So, you know, maybe Neil, this is something for you, what is an issue fork, and how exactly does this differ from making a fork on a platform like GitHub, which a lot of folks are familiar with.
Neil Drumm: [00:07:31] Yeah. So. In the Drupal Community, especially contributing to Drupal Core, but a lot of the bigger country projects as well.
There's a lot of collaboration going on. On average, Drupal Core has five, about five people contributing to you, which issue, and we wanted to make sure that we still have that collaborative aspect. Yeah, with a patch workflow, anyone can download the patch, apply it to their local code base, modify it and upload a different version of that.
So what we're doing is, having issue forks one fork of the repository per project or per issue. where anyone can get access to that and push, to any, any branch in that fork. So, if you know, it's a straightforward issue, people can keep pushing to the same branch, or if there's some divergent, ways to potentially implement the fix for that issue can have multiple branches.
And that's really - that's the key thing that's different for, for Drupal. With a fork on GitHub, it's really in your name space and you're the one maintaining it. And you were, you were expected to push that issue through to completion. If, if you still have motivation to do that, when it gets solved.
One of the things I love about this new paradigm. you know, obviously one of the biggest issues I think that is tough for contributors is, you have to create a new patch, a new X, Y, and Z every single time. And you know, all of us have alias commands now to do those sorts of things, in our respective terminals.
but this really kind of turns the whole model on its head and really kind of. makes Drupal, very similar in a lot of ways to a lot of other open source projects that allow you to do exactly that sort of thing, where you have an issue for it, push changes to it, and you can keep on pushing changes to it.
And it's automatically updated. There's no need to kind of manually upload patches, manually do the sorts of things that have been done before. I love that about this kind of new milestone for us. So let's talk about how these issue forks figure, like, so one thing I'm having a little bit of trouble wrapping my head around is so if we have an issue for it, I'm like, how does that differ from a pull request in GitHub.
What's the merge request and what are some of the things, you know, given that we've got this amazing history behind Drupal. And these modern tools that we're looking to adopt, what are some of the special considerations or nuances that Drupal projects have to face when it comes to enabling GitLab style or GitLab native, merge requests?
So. Yeah. As far as I know, pull requests and merge requests, they're pretty much the same. GitLab calls them merge requests, GitHub calls them pull requests. They both, the maintainer can merge a branch in, and yeah, what those are, merge requests is once you've gotten, some work in a branch, on the issue fork, ready to, Ready to be tested, ready for review.
You can open up a merge request for that branch and that will set up a place for, people to comment on lines of code, set up a place for, Drupal CIs to start testing the, testing, the merged commit, and the collaboration in the review phase of completing an issue.
Tim Lehnen: [00:11:32] And that's sort of like the RTBC state almost for, in old Drupal parlance.
It's like when the issue is sort of. ready for review for community testing, you know, it needs review, or RTBC somewhere in between you open that merge request, you kickoff the tests, and people can comment directly on the technical solution. and Neil, you did something clever with the way the merge request.
Those comments actually appear. Cause one of the issues is once you open that merge request, now there's a second comment stream. There's the main issue. And then there's the merge request comment stream. Can you, can you talk about that a little bit?
Neil Drumm: [00:12:08] Yeah. So with Drupal issues, what people are used to working with is a single thread of conversation.
Everything's chronological people refer back to comment, number, whatever, and if you're coming to an issue you can, look back to when you last visited it and just read through and know that you've seen everything about that issue. so that's something that we want to preserve, with this.
So we are bringing all the activity, from the merge request, the commenting on specific bits of code. Those are threaded comments as well. you know, GitLab does a good job at that UI. We're not going to rebuild that. but we'll bring back that activity to the issue page. So the comments on the merge request will be interleaved with the comments on the issue, and something that we are doing.
That's a bit different than the existing Git integration under the hood is, with the existing Git integration. We're bringing off the Git metadata into drupal.org's database and maintaining basically a copy of the Git repository in, MYSQL database. but we're skipping all of that for merge requests.
That's, all that activity is brought in with JavaScript on the front end. So it's much less for us to keep in sync and, we can really lean on, having a light integration and letting GitLab to what GitLab's good at.
Preston So: [00:13:59] I love this because, you know, it kind of keeps the drupal.org experience intact in that, you know, people go down, their familiar pathways, their familiar, happy paths to get to issues that they need.
You know, which I think is a very, very important aspect of this, but they can use those really nice added little functionality that GitLab provides, embedded in that issue queue. it's really an incredible kind of kind of thing. One question I had Neil was, does this also enable things like a GitHub style, inline code comments where you can comment on code dips or lines of code or even particular, you know, key words or, or indications within the code.
Neil Drumm: [00:14:44] Yup. Yeah. So yeah. GitLab has the commenting on lines of code, in the div, or, on the, in the commits and those are threaded, can mark threads is this resolved or not? So, can keep track of what bits of the, what bits still needs to be resolved. what else does it to, They have suggesting changes.
So it's a little bit of a cumbersome markdown syntax. Like a one line suggestion to change is pretty easy. you could do multiline too, but those are, they're improving their UI for that. so yeah, it's really the full featured, what you would expect from a code review experience. nowadays.
Preston So: [00:15:37] Wow.
That's incredible. you know, the fact that there's even code suggestions is remarkable. I'm really excited to try that out. and I think it's really revolutionary for Drupal. You know, I think one of the things that, you know, has always been somewhat of a, you know, maybe, maybe not, definitely a problem in some ways, but actually a good thing in other ways is the fact that every single drupal.org issue becomes this compendium and this long kind of bookshelf, annals of history of every single person who's ever had a thought on that issue.
And you know, I think that you, you know, a lot of us who are in the Drupal contributing world, are very used to that kind of model where you see the single chronological thread that goes through the issue. You have one single source of truth for all the activity. but on the merge request, I think it's really great that you can have these multiple threads of conversation.
You have these, you know, you have the ability to have sub conversations that don't necessarily muddle, some of the higher level of discussion taking place. I think that's amazing. So quick question, when exactly is this all going to be available? I just looked on drupal.org. I don't see anything there right now.
When is it going to be around and when can we try it out?
Neil Drumm: [00:16:51] So yeah, we enabled this in beta for some projects, the week of DrupalCon Global and right now there's over a hundred projects that are using this right now. And, the issue forks and merge requests. Those are all in a pretty good spot.
the bringing activity back to the issue, that's kind of the, I'd call it proof of concept. Right now there's a lot more kind of detailed and UX work we could do to make that look a little better. like we have a little resolved flag or not resolved flag for those threads, but. We could probably do like a bigger visual treatment because you really don't need to care about the resolved threads probably.
and the big chunk we have left is, actually integrating this with DrupalCI, so, probably get into that a little bit later.
Preston So: [00:17:58] Wonderful. yeah, and I think that this, this is, this is really exciting, you know, because, you know, obviously it's in a, it's an, a beta where you want to make sure to iron out all those potential issues that might surface all those potential foibles or head scratchers that might, Kind of come out.
One curiosity that I had though is, you know, I'd love to, and keeping track and stay in sync with the state of the beta and some of the learnings that you all have at the Drupal association. So, out of curiosity, how can I, you know, in the time before, you know, this all comes out, how can they find out about where the data stands right now?
And what's currently available to be used in that data?
Neil Drumm: [00:18:40] So the easy to remember URL is Git.drupalcode.org/issue and that has a link to the documentation where we have the, current status at the top and, links to all the issues that are in progress for, actually building this out, you know, drupal.org.
It's a bunch of modules and we work in the issue queue, for the most part. and yeah, the opt in for your project is linked there. and yeah, that's the best place to get started.
Tim Lehnen: [00:19:20] Yeah, I would add, we've had, as Neil pointed out, we've had more than a hundred projects opt in to using this forks and merge requests functionality.
For many of them it's mostly the existing maintainer or maintainers just using it to. do their own work a little bit faster and more efficiently, but there are some larger projects in there as well that are doing it with external contributors. and so far the feedback has been really, really positive.
It's been a very successful beta. And so really, it is mostly a focus on UX improvements to what's already there and enabling testing, before we'll be able to start moving out.
Preston So: [00:20:00] Wonderful. And we definitely want to see that a UI as stable as possible and as usable as possible, by the way, that issue that Neil mentioned, we'll link it in the notes of the show.
That's issue number 3152637, opt into the drupal.org issue, forks and merge requests beta, not a very clear title of what it's trying to do, but alright, Neil, I think I might've cut you off. You were about to say something there.
Neil Drumm: [00:20:26] Let's see. So yeah, the next step will be enabling these, for, Drupal core.
So yeah, we're really looking forward to getting at, testing the limits, when these are used collaboratively, multiple people contributing to an issue for work, Seeing how that goes and testing out on some core issues, and similar to optin per project. we'll be able to also opt in per core issue.
So we can test that out with a few, hopefully short lived issues. It's exercise it a bit, then, you know, I think once it's gone through that proofing stage, Then they'll pretty quickly go to general availability. If not we'll keep iterating on the UI, from there. And the main functionality gap is, testing right now.
That's the one thing we don't have. So once the merge request is open, shipping that to a Drupal CI and having that test day works, what would be the merge commit? but we're in the, I think the final stages of getting that working.
Preston So: [00:21:47] I'd like to dig in a little bit more into, kind of the challenges, with DrupalCI.
You know, you mentioned that, you know, testing is a very big challenge. Is there any insight that you can share about kind of, what sorts of things about Drupal CI make it challenging to integrate with, merge request tests?
Neil Drumm: [00:22:09] So for the first pass, we're going to stick with pretty much the same Drupal CI.
We'll be testing. The main difference will be in the code base set up instead of applying a patch, it is, fetching the ref of what would be the merge commits, if it was merged, from GitLab. So it's testing both. The what's in the branch and, upstream versus moved upstream. But, GitLab CI is something we're really looking forward to implementing, and that will kind of force us into a more, even more container based workflow. They are everything's containers and we're using containers for Drupal CI already. It's not really a too big of a leap, but kind of the big part is the code base assembly.
Getting our core and all of the modules to be tested, that is not in a container right now. Yeah. So my coworker, Ryan's working on that and. Yeah, it'll be our first, really using containers and simple stacks, but Kubernetes, cause that's where GitLab goes. And it's a lot of other details to figure out as well, like, cost to making sure that we could do these all on spot requests with AWS, to save costs. but that looks like there's a way to do that now. And.
Tim Lehnen: [00:23:51] Yeah. I mean, stepping back a little bit, part of the reason that CI in general for Drupal is complicated. That's just not specific, not specific to Drupal CI as an implementation or what the GitLab CI implementation we'll look at. Is just the scope of what we do for testing in the Drupal project.
Right. We have, as, as our coworker, Ryan likes to say, we have this Cartesian product of all of the variations of what you're testing. So are you testing this patch from that issue on that branch of that project on. You know, this database, like which version of mySQL, it could be one of, you know, six versions or of PostgreSQL or of, you know, which version of PHP are you testing against.
And so you have all these combinations of, testing variables that go into each set of testing. So the complexity it creates is in both. the experience of configuring and choosing what is available to test as well as like managing the defaults to make sure that we're testing what's most important, and saving money on sort of unnecessary duplicate tests and then, you know, whenever, but we look at integrating.
the CI system into using GitLab's CI as it's sort of just dispatcher to replace our custom dispatcher, we have to make sure to accommodate those same workflows , those same combinations and permutations of available environments and, and code base and configuration. Plus we'd also like to make it possible using some of the tools that GitLab CI can use for, For users to define their own custom environments.
Like right now you can't use, if you're testing something with the search subsystem of Drupal, you can't stand up a test infrastructure that has solr servers set up, for example. So we'd like to make those sorts of things possible on a relatively limited basis. Cause resources aren't, aren't unlimited, but.
That would be powerful as well. So those are some of the things we're looking for as kind of like the followup work to getting the initial, initial merge request testing, in place.
Neil Drumm: [00:26:03] Yeah. And done resources, with Drupal CI, we go ahead and throw a relatively large AWS instances at testing. So 64 processes, processor instances, and they that's why.
Core testing gets done in only an hour. It's just not the sort of thing that would fit into the free or open source tier of Travis or, hosted, GitLab.com testing.
Tim Lehnen: [00:26:39] Yeah.
Preston So: [00:26:40] Wonderful. and you know, I think it's very exciting to hear about all of these, you know, features that are, that are currently, you know, running the gauntlet right now through, all of these kinds of, of, of, considerations. one of the questions I had though is, you know, when is kind of that threshold.
Where, after, you know, obviously we enable things like merge request tests and all that. When do we envision this to come out of beta? I know that we talked briefly about this before, but, you know, what are some of the deliverables that the Drupal Association is waiting for before just turning this on for everybody?
Tim Lehnen: [00:27:17] Yeah. I mean, it really is. I think, I think the two gates we're waiting on are when core is able to test, you know, two or three issues. And when the merge requests are enabled, I think we're ready to say, go and flip it on for everyone. And that could be. I mean, I hate giving dates. It's so dangerous as an engineering manager to try and give any dates, but, but it could be very, very soon, like it could be within a month or two, depending on how, depending on how carefully we choose, which core issues to test it with, right.
We want to pick those sorts of non-controversial issues that can do the whole life cycle quickly. but the remaining technical challenges, as Neil said before, getting the initial testing service set up is almost done. It's something he's been working on for the last couple of weeks since DrupalCon.
And then, and core isn't actually a good position in the core release cycle to pay attention to these test issues. So yeah, it's going to be very, very, very soon. Ao I'm sure there'll be an announcement on drupal.org when we, when we go through with it. But, yeah, I'd love to see it sort of.
Before the summer, or rather the fall Equinox, if we can manage it.
Neil Drumm: [00:28:35] Yeah. And it's, yeah, I'm not too worried about turning on too soon. Cause that's the sort of thing, like we can keep the patch testing turned on, to test the last few patches and we're not forcing everyone to change their workflow immediately, but I'm sure there'll be some maintainers who, might say, yeah, the maintainer of the project can certainly say, I'm not going to accept more patches please.
Post your merge request. So yeah. Yeah. We'll, we'll have both running in parallel for a little bit, but probably not too long.
Preston So: [00:29:12] Then one final side question, I'm venturing a little bit further out. you know, I think a lot of people, we've shared a little bit about kind of how, you know, Drupal CI fits into this larger picture and I think a lot of people are very curious about the future of Drupal CI. , what's the future hold for Drupal CI?
Tim Lehnen: [00:29:32] I, you know, I think we covered some of this in, in Neil's earlier comment, but yes, that's exactly. The idea is to take is to look at GitLab CI as a. As a replacement for not the entire end to end stack of Drupal CI, but for the orchestration layer that dispatches and coordinates, a requested job to the Kubernetes environments.
well, the Kubernetes cluster that will spin up your environment container with your appropriate PHP version with your custom, correct requested solr instance for whatever you're testing. Right. And it looks like GitLab CI will actually be very well suited to that. So that'll be a great place to, to replace a wholesale, a major component of the Drupal CI infrastructure, with the sort of standardized and off the shelf system that GitLab CI provides. So very excited about that.
Neil Drumm: [00:30:29] Yep. Wonderful. Won't miss our, our Jenkins instance for dispatcher
and, yes, standardizing have the speed from we're container-based will make it easier for people to run locally as well. And yeah, just more flexibility since containers are relatively standard nowadays.
Preston So: [00:30:51] I can't imagine why. I mean, Jenkins is really bleeding edge, isn't it? It's anyways. absolutely. I think it would be great to see all of this move over to a container based architecture and, and leveraging some of the latest and greatest like Kubernetes. so, so one question is, you know, obviously we talked a lot at length about the technical underpinnings and all of this amazing work that goes into making this happen. And I can't imagine that, you know, it's, it's been a very easy road. One question, I think that a lot of contributors have, a lot of folks in the Drupal Community have is how can we help? What are things that we can do as a community to take some of the burden and some of the workload off of your shoulders Tim and Neil?
Tim Lehnen: [00:31:38] Yeah.
I mean, there's two major areas. So the first one is the, the user interface and UX review. That's a more niche cause. So for all of the front enders and UX folks who are listening, please, please, please come help us out. And in understanding the best way to create that good user experience with that single threaded conversation we've talked about, that's something that we'll continue to refine even after this is released to the general public.
So we'd love that sort of help. but the other obvious one that anybody who works on Drupal.org and maintains a project can do is opt your project into the beta. You find that link in the description below this podcast and, and jump on board and help us test things out. Neil, do you want to speak to maybe how, what people should look out for specifically as they're doing that beta testing?
Neil Drumm: [00:32:24] Yes, just, getting more use cases for, For using these, using merge requests. There are a few decisions. Like the, there's a few configurations on merge requests for what type of merge commit gets made, for example, but yes, having more examples, more use cases, so we can see how things look all together.
Tim Lehnen: [00:32:58] Cool.
Preston So: [00:33:00] Wonderful. Well, once again, you know, I think that everyone is very excited for all of the goodness that will come out of the GitLab migration. obviously so many nuances, so many complexities to resolve. I don't think that, you know, we can thank the Drupal Association and, both of you enough for the incredible work that you've been doing.
So a number, something completely different. Yeah. We have a segment on the Tag1 TeamTalk show called the Aside Tag where we can share something cool or interesting that each of us is doing with the audience watching us today, or listening to us in a podcast form, it could be something as simple as playing with the new technology.
I saw an awesome movie trying to do some home building, as I know is a common thread on this aside segment. So without further ado, I want to go ahead and turn to you first, Tim. What's going on in your life right now? On the Aside Tag?.
Tim Lehnen: [00:33:56] Yeah. So, gosh, I feel like every call, I keep talking about how the weekends blur together.
So what I'm trying to do is find new interests and things to do. So, I have never been a big flight SIM geek or anything like that, but I saw some of the trailers for the new Microsoft flight simulator, where they have a full rendered planet Earth, with a combination of AI generated, buildings and hand sculpted, 3d assets and a full physical simulation of weather with volumetric clouds and all this stuff.
And so I'm nerding out about the weather simulation possibilities. I'm going to have to figure out how to fly the damn planes, just so I can look at the weather, but that's coming out sometime soon and something I'm looking forward to just give me something new, some variety. Yeah. Some variety on these weekends.
Preston So: [00:34:42] Wonderful. Next step Neil. What's going on in your world?
Neil Drumm: [00:34:47] Let's see. Leading up to DrupalCon Global. I was just spending a lot of time on this project cause I was excited to get it done. But yeah, I had a little time since then to watch the Netflix Wild, Wild country. The, documentary about the Rajneesh cult in Oregon.
So that was it.
Tim Lehnen: [00:35:12] Yeah, intense.
Neil Drumm: [00:35:13] Interesting situation they had.
Tim Lehnen: [00:35:16] for sure.
Preston So: [00:35:18] That's wonderful. Finally, Michael Meyers, what's going on in your world.
Michael Meyers: [00:35:22] I am loving, new dog collar. it's from Orvis, it's called conceal a collar. We live in a tick infested area. And so we have a collar this semester to collar on the dog, in addition to his dog collar and all the tags.
And this collar, as concealer collar would indicate. Actually puts the tick collar underneath the main collar. So you don't see it, which is great because it's like chemicals and I don't want to leave you touching it all the time when I'm like pinning him and it looks great. It makes him even more handsome and you can personalize it.
You know, he looks rather dapper, and we could put some information on it which allowed us to remove one of his tags. So less jingle jangle. so everybody's happy. It's great. I love it. Check it out.
Preston So: [00:36:12] I love that. Oh, go ahead.
Tim Lehnen: [00:36:14] Say, I want to see your dog on the next Drupal pet spa at some upcoming Drupal camp or something like that.
We got to have a fashion show.
Michael Meyers: [00:36:22] Oh man. I can't wait.
Preston So: [00:36:26] Absolutely. And last but not least, I'll, I'll go ahead and share something that's going on. You know, I've been recently, struggling to find a good television to watch. you know, I, I generally am not a TV watcher, but it's been, you know, it's, it's hard.
I mean, we're, you know, definitely needs some distraction. and so one of the things that I've been doing is on good authority. I've heard that watching Star Trek is a great distraction during this time right now. And I'm already about 90% done with the first season of the original series. I gotta say I'm pretty impressed.
You know, growing up as a kid, watching Star Trek, the next generation star Trek enterprise, I don't even remember the titles anymore. and going all the way back to the original late 1960s, show has been really eye opening for me as somebody who has never identified as a Trekkie. So yeah.
Tim Lehnen: [00:37:18] That's some good, good stuff for sure.
My wife's favorite is absolutely the original series. There's, there's no debate in this household over which Trek is the best Trek.
Preston So: [00:37:29] It is very interesting. I do love some of the kind of low tech, low-fi things they've had to do to up to kind of simulate certain things. Yeah. Alrighty. Well, that's all the time we have for today unfortunately.
I want to, once again, thank our dear friends, Tim,Neil, and Michael for joining us on this episode today, as we mentioned during the talk, all the links that we are talking about today. Are going to be posted online together with the video and information about this episode. And if you liked this episode of Tag1 TeamTalks, please remember the upvote, subscribe, share it with your friends and family, share with your favorite Drupal contributor down the block.
And, also check out past talks at tag1.com/tagteamtalks . And as always, we will take feedback on any topic suggestions, feel free to write to us at tagteamtalks@tag1consulting.com. Thank you so much to our guests today and see you next time.