 Good morning, everyone. Now we know exactly who didn't stay out too late last night All right, so I'm gonna invite up the Drupal org engineering team our consultants And folks who work on infrastructure volunteer on the security team. So let's bring everybody up on stage That's right. That's that morning energy. I want to see All right, here we go So I'd like to share the faces of everybody who's involved in maintaining Drupal that organ some way so we have the Drupal Association engineering staff members of the infrastructure team and Also some consultants new faces that you're seeing who have joined us over the course of the last year To help accelerate the work we're doing so I hope you'll give a warm welcome to all of these people here And if you see them throughout the con feel free to say hello I also want to thank our infrastructure partners in particular tag one consulting helps us manage the infrastructure for Drupal org And the Oregon State open-source lab is where we host most of the Drupal infrastructure today As we go further into this presentation, I just want to help get the word out if you somehow didn't see it already Drupal 7's end of life has been extended So moving forward will be reevaluating the end of life date for Drupal 7 on an annual basis So at the moment, it's at least extended through November of 2023 and by July. We will be Evaluating it again Also, if there is anyone in the room who's still using Drupal 6 in some form the vendor supported support for Drupal 6 We'll be ending in October of this year So without further ado, I'd like to run into a lot of the work this team has been doing and I'm going to be handing it off to different members of the team as we go As many of you know groups dot Drupal org is one of the sites that we manage to support community events community organization And as we come back out of the pandemic folks are getting back together starting up events again starting up meetups and things like that So Caleb, I'd love to hand it to you. We can get a mic over there To chat a little bit about some of the work you've been doing for us to create sort of the next generation of groups Hey, good morning, everybody So as you know community groups many people use Drupal dot org to build, use, collaborate with other people in the community To build up Drupal orgs, you know, documentation Modules themes and things like that. So community groups was revamped with the purpose of aiding those who want to Take full advantage of Drupal's communities and its offerings and it's how useful it is and Help group them with like-minded individuals to form groups and things like that With people who are of like-minded individuals or other groups or also to diversify themselves as well So on launch This part of the site will be available at Drupal dot org slash community slash groups And what it is is it'll list out all the groups that are It within the Drupal community you can join these groups You can subscribe to other groups You can and what you'd be able to do on on these pages that you'll be able to see the recent posts that are going That people are talking about Upcoming events You'll be able to view the current members and admins if you are a member it'll link directly to your personal Drupal profile you know, so you can go ahead and Increase your your network and things like that that way See you so it'll display the recent posts upcoming events. It'll highlight the group members and admins And like I said, you'll be able to subscribe to different groups so that you can stay in the know awesome, thank you Caleb, and we'll also be offering some of the multilingual options for our international groups in the community groups section and this is In development almost complete now and hopefully rolling out soon to replace the existing groups dot Drupal dot org We've also recently made some updates to release pages some overhauls to provide more information To Drupal users before we go there I want to say again, please feel free to gather gather in if we do questions later That'll get you closer to the mic if you need to ask something But Brandon, let me hand it over to you to talk about the work you've been doing on Drupal dot orgs release pages Sure, I'll keep it a little bit short. So if you've been on a release page lately You'll notice we have composer commands now on compatible releases. That's very exciting It's not a lot else to say here other than you're all aware web development is not always exciting We have ripped panelizer out of release pages Which is exciting for us because it's one less thing we have to do to migrate on past Drupal 7 Yeah, so that's wonderful Next slide, please perfect Well now it's all release pages. So core also it's a little bit more complicated So we've got some more documentation here some more guidance and Trying to help people avoid some gotchas when it comes to doing composer things with core and if you were at the security panel yesterday, you will remember Michael's advice about About pinning versions and things like that So there's more information about how to pin to a specific release and how to manage pinned versions when you do want to update and deliberately update to those specific versions Brendan you also worked on a refresh of org profiles. Can you talk through that real quick? Sure the goal here Was to think about who might be going to organization profiles Like most pages on Drupal dot org they're very information dense We tried to organize this a little better for folks who were coming to an org profile to figure out if they wanted to work with an organization so You know moving case studies up giving them more prominent Position so it's easier for people to see what an organization does with Drupal Yeah, we've also realized that those pages were super long we've done some condensing of information Still highlighting some of the key indicators you can see them in blue those are actually accordions and you can expand it out as you can see on the left of the slide and really Dive in if you want to You know, we realized it was too much information for the average average person browsing around Organization profiles, but the information is still there if you'd like it Awesome. Thank you We also want to talk about the future of distributions starter kits and also Publishing things that are not just traditional modules and themes To the Drupal namespace on packages for use with Composer so for that Ryan, let me hand it over to you to talk Sure. Yeah, so traditionally on Drupal at org We've supported distributions and it's sort of a drush make and tar ball method of getting started with a distribution and When we built packages dot Drupal at org we didn't initially provide support for distributions to be started with Composer Because we weren't really sure how that was supposed to work But over the time over time the communities coalesced around a kind of standard practice of having a starter template for your Distribution that you do a composer create project to begin with and then there will be you know The distribution profile itself that gets included in that and so we've now Recently added support for general projects on Drupal at org and we're going to suggest that distribution maintainers start putting their distribution templates on Drupal at org and Those general projects now automatically integrate with packages so that from a bear command line You can start with Composer and say composer create project Drupal slash Your distribution name so that's sort of what's on the next slide So this will allow the Drupal namespace still to be controlled by DA so we can't have you know Package poisoning kind of issues or anything with the supply chain attacks But also to be able to leverage the Drupal namespace so things are in a familiar spot But in adding this we've also enabled other types of projects to be able to be hosted on Drupal at org So if you want to upload a composer package and have it in the Drupal namespace you can put that in a general project You can put Drush extensions. We're going to try and migrate coder over So all of these different things that are not exactly modules or themes That probably should just live directly a packages can now be Built on Drupal dot org directly and manage there Awesome. Thank you Ryan. I also want to talk a little bit about the Drupal 9 upgrades that are in progress As you may know Drupal dot org is often one of the later sites to move to the latest major version of Drupal because we have So much custom code and infrastructure for supporting a project. That's really only used by us There are community members out there who have Helped us to move forward by helping support custom modules or key modules that are used on triple at org And that's actually a way that you can contribute if you're looking for something to do while you're here at the conference But to give a few specific highlights, I'll run through some of these And then I'll probably ask and Ryan here to talk a little bit about some of our sort of strategy for for doing these Upgrades for Drupal dot org infrastructure, but starting on some of the things that are a work in progress So API dot Drupal dot org is probably something that everyone here has used if you've done any Module development or anything like that with Drupal So our team member Fran who couldn't be here today. He's in Spain Has been focusing on this port and he's completed porting all of the functionality basically the whole custom module all of these things Over to Drupal 9 we're gonna get ready to launch this relatively soon We're now moving into sort of the theme layer of this as well So if you're not familiar with what happens on the back end API dot Drupal dot org basically Processes all of the branches in any given project pulls out the code comments creates cross-linked References between areas of the code and then provides developer reference information as it's been committed to Drupal So that's coming very soon. We're making really good progress there and you should see that In the next three six months if not sooner Fran on our team has also worked on the Drupal dot org Project endpoints that we're using to support the project browser initiative So you'll hear more about the project browser initiative in the trees note tomorrow But the idea here is to allow folks to browse modules Themes everything else directly within the Drupal interface install them directly But to do that we need a robust API for doing so from Drupal dot org and it needs to be on Drupal 9 We don't want to use a legacy API as we're building it out So again, we've begun the process of building the migrations of the relevant Projects related content types on Drupal dot org There's a huge amount of work that's already complete and this is a collaboration That's going to be ongoing with the project browser initiative team moving forward But this is something that we were able to pivot to pretty rapidly in the last month or so and start making some Serious progress based on the starting work that the project browser initiative team had worked on So from here, let me hand it over briefly to Narayan. Do you want to talk a little bit about our kind of D9 d7 architecture strategy as people who have attended this talk before probably know Drupal dot org is kind of an Bundle of legacy integration that we have been slowly working through to update to something Maybe not modern, but at least current Going through and rebuilding our things of that nature D9 presents a more Interesting challenge and opportunity in that we still have to run the d7 and in some cases d6 Syson endpoints while supporting D9 and its new version requirements and While we already have multiple versions of php running on our web nodes There's a limit to how many versions of php. I really want running on the web nodes. It shouldn't be a collection So we're taking this opportunity to modernize our workflow a little bit and go towards more of a containerization approach and And Starting to stand up Kubernetes clusters starting to migrate specific things over so that we can silo them away from each other So our triple nine sites when they launch will be in containers built on a new workflow We are partnered with GitLab and are using GitLab for their container registry and building So the entire development workflow and deployment process is going to be a lot more modern than what we currently do Which is basically Jenkins and large batch scripts So it should be an opportunity for improvement At the moment. It's just an opportunity for a lot of work breaking things up but It will get better at some point Currently we have most of that done and our next major step is going to be a large database upgrade to support the personal requirements of Yeah, and the first sites will be coming soon. They'll be our test case probably something like API Again the Drupal at our project endpoints or the event site, which is going to get upgraded itself as well There's a few other things that it left. So we're working on a new authentication solution using key cloak That will allow folks to use their Drupal dot org identity across all the sites including legacy seven sites and the nine sites but also hopefully opening it up for Authentication of other sites and services we still need to work on policies But we'd love to let you use your Drupal dot org identity On a campsite for example and things like that. So we're on chat services We're we're gonna have to figure all that out, but we're in the process of building those things It'll be an update to the theme of course for for Drupal 9 compatibility into the production infrastructure in general As you may or may not know the Drupal Association team also coordinates with core the folks who spend their time Kind of building the next generation primary features of Drupal and there's been increasing collaboration between the teams Especially around specific initiatives. So in one particular area Really supply chain security and package signing We are doing some work to support both the automatic updates initiative and the project browser initiative So again, both of these are about making the sort of total cost of ownership of Drupal lower making it easier to Keep your site up-to-date they can get easier to find it and install new functionality for your site and easier to keep your site secure But for that to achieve all of its goals We need to make sure that the integrity of what is being automatically downloaded and applied to your site is verified So Neil, I'll have you talk a little bit about the tough framework that we're implementing and how we're doing the supply chain security here so yeah tough is the update framework and it provides Signing for what you download from Drupal org including packages dot Drupal org So when you're doing automatic updates your site can verify that what you're updating to comes from a trusted source It's actually from Drupal org and prepare for that we've been So Rearranging our packaging pipeline the thing that makes the downloads on each release page There's a few other steps in that queuing up testing and We're going to be adding the signing step To that so we need to do some pre-work to get that ready and we have a contractor Who built the? System to implement the update framework in PHP on the server side Or actually not in PHP to provide interfaces for us It's all That is all in Python code So we'll be able to swap that into the Packaging pipeline in the next few weeks we have to give thanks to consensus enterprises who are partners on developing that Package signing server side infrastructure. They are open sourcing all of that work. They've been doing for us as well It'll be a project called rugged That you can find on GitLab So if you happen to be someone who manages a large internal package manager for any reason could be useful to you It's also something where we're Collaborating with folks like the cloud native computing foundation and the open source security foundation To sort of standardize Supply chain security across a lot of open source projects and we're hoping that the work We're proving out using the tough framework in Drupal can be adopted by other projects We've had interest from typo 3 in jumlah We're hoping that even packages itself may eventually adopt this and provide package signing across the whole PHP ecosystem I want to give a shout-out to Ted bowman who's here in the audience as well He's about to have a session tomorrow to talk about the automatic updates initiative in more detail So if you're interested in this particular topic, I would put that on your calendar as well We spoke a little bit already about Authentication and single sign-on so again the idea here is we're going to be using key cloak another open source project that Works with like open ID connect and similar OAuth And using that to connect Simultaneously to our Drupal 7 and Drupal 9 sites with your Drupal identity and then hopefully third-party community sites as well again, once we have worked out the policy for Ensuring that code of conduct is enforced all those sorts of things Just give you a little bit of a preview of what that looks like. It's just a login page. It's not too fancy But you'll start seeing this roll out relatively soon as a precursor to a lot of our migration work and these other projects It helps us enable the ability to start running some of these systems with different Requirements in parallel with each other before we get every Drupal at org property on the latest version So with that I'd like to now switch over to the tools we use to collaborate as a community How we collectively build Drupal and what serves the primary mission of the Drupal Association engineering team, which is providing you with The power to do your work to collaborate to build a better Drupal project and in particular I want to talk about our GitLab acceleration initiative because I know it's something that everybody's really interested in this is the move from The bespoke tooling that we've been using for years more than a decade to more fully adopting the GitLab tools and workflow So let me hand it to Irina to talk about the goals and kind of the big picture And then I'll have the team talk through some of the specific next steps that are coming up GitLab acceleration initiative is the second phase in the process of making code contribution to Drupal easier Drupal codebase is on GitLab since 2020 and in this phase we continue adoption of standard tools And adapting them for Drupal ecosystem Why can't we flip the switch right now? the GitLab Workflow is Designed by default for forking into individual contributors Share space while Drupal project is much more collaborative So This is why we need to adapt It for Drupal work better for Drupal project Here's how we're doing it First let's talk about what stays on Drupal.org and what will be on GitLab after project is completed We get lots of questions about it projects Releases and endpoints as well as contribution credit and user documentation stay on Drupal.org They're very Drupal specific components Repositors the code is already on GitLab So now we're in the process of replacing bespoke Drupal CI with more standard GitLab CI adjusting it to work for Drupal project and after that we can flip the switch Allow user Users to use issues and before that we need to migrate issues from Drupal.org into GitLab and This is major collaboration between Drupal community Drupal association and GitLab And clearly defined roles and responsibilities allow us to move forward efficiently We want to thank and all contributors to this project Especially Drupal Sponses projects for expertise Brainstorming and insights that you provided and continue to provide. Thank you um Here's a big picture of the project components And what is left to complete Three major steps right now are single sign-on between Drupal.org and GitLab Project releases stay where they are and right now we're working on Right now we're working on GitLab CI And next steps will be Moving issues In this process. We're also simplifying People's project and project pages Now let's talk how exactly we're doing it Awesome. So we'll talk about a few quick wins first Sort of smaller components of this project in ways that we've simplified Drupal.org So Neil's going to talk about a few of these starting with just some features that we've been able So Yeah, when we started using GitLab, we kept it pretty minimal to have the transition go smoothly But we've been quietly opening up more profile pages in GitLab so Yeah, under the preferences menus you see there you can We moved SSH key management to over to GitLab since we don't use your public SSH keys for anything other than commits And We opened up the where you could put the GPG Keys for commit signing. So that's been available for a few weeks And this is also where you configure your notifications Um You know GitLab is always going to be the best tool for sending its own notifications. We're not going to re implement that So if you want more emails, uh, that's where to go Uh, and uh Yeah, they also have a Authentication audit log. You can see what ip addresses you have your account has been used at and make sure Your account's not compromised Uh dark mode for the code and uh, just Uh, a few weeks ago, uh, we enabled GitLab's full code search. Um So, uh, yeah, that's available to search through all full projects on Drupal.org uh Drupal.org also in the past has maintained a database uh database of all the Commits, uh, which That was really the only maintenance we had on the old system since we weren't adding features very quickly But that database is redundant and extra work to maintain going forward So that means any place that there's been counts of commits and listings of Uh get metadata on Drupal.org is Being replaced by whatever GitLab provides. Uh, so the maintainers block Uh, you might remember used to have those counts. Uh, now We're centering on who the people are And you know, that was a long standing issue as well because you know, not all projects Have code or focus on code contributions. So we wanted to get the people up center Uh documentation on there also was, uh GitLab provides more places you can have documentation. So that block simplified a little bit and The development block that's where the links are To GitLab and this will be changing more in the future Issues are going to GitLab. So they'll go away from project pages as well Same with profile pages. These are upcoming. Uh, that's another place where we have a List of how many commits you have to each project. So that's going to be replaced by something And uh, we want a more prominent link to your Git.drupalcode.org profile Awesome Um, so let's talk a little bit about GitLab CI because that's the main Phase that we're in and sort of the largest current technical challenge, uh of this project So that's something that Ryan has been largely leading on our side So I'll have you talk through sort of where we are and where we're going Uh, hi. Yeah. Um, so the transition over to GitLab CI is, um, it's exciting And it's really interesting because it means that there's a huge piece of code that we no longer have to maintain ourselves And can rely on, you know, a off the shelf solution that offers a lot of extra features um, one of the One of the big challenges that we're trying to wrap our heads around is like Drupal CI was very centralized And in its centralization meant that like there were configuration options that We set at the top level that everybody then inherited and it was like a Very simple like you configure your project to run with certain versions of core and even core labels It would just stay on whichever version of core it was supposed to be And GitLab CI is more of your configuration is in your repository as a GitLab CI YAML file And so what we're doing is figuring out how to Preserve some of the here's the standard best practice that the community can use In addition to enabling the community to do whatever sort of Off off the garden path that they need to do to First their specific project So every maintainer is going to have to set up a GitLab CI YAML file to be able to do this And uh Let's see I think the main thing here is just Configuring the defaults to allow that transition process to be easier. Yeah, I kind of covered this in the previous slide So yeah, being able to have these defaults set so that We have a system in place that is a starting point for everybody that they can then deviate from so Um But then we're gonna Not have patch files anymore. There aren't patch files in in GitLab. And so we won't be able to Use those to run tests. We'll have to focus on merge requests and you know, we're we're working with GitLab on a way to have permanent links to Permanent states in time for merge requests because right now a merge request is a mutable object that can change And so if you have a build, it's like we want to run our site off of this Changed version of this one module. We need to be able to have something that you can have securely in your build So we're working with GitLab upstream on on that sort of thing No, sorry that was the that's that's what the next slide was about. So yeah, so yeah, you know The other thing about including patch files in your Deployment is it's never really been a best practice to hot link to those artifacts in your deployment process Right to just put in a url the drupal.org. It's a habit that the whole community has been in And it's a habit we kind of need to break right we do want to have the ability to find stable URLs to emerge request or patch file That's not been applied upstream to the project you're using but It's never been a great idea to rely on Some random site on the internet for your deployment process to work right So we're trying to encourage the community to adopt new best practices to Commit to a patches directory to compete to keep your deployment artifacts so that they're repeatable Again rather than relying on a connection to outside sources So the the steps that were taken to transition Drupal ci to GitLab ci is kind of twofold on one hand we have the community in the Drupal spoons project looking for Best practices and ironing out different ways to test modules And at the same time we have to consider core as a sort of special case and One version of core that always gets neglected is Drupal 7 And particularly for security testing. So there's There's it's sort of the edge case of the edge cases that we don't normally think about and so we're starting there so that we get everything Kind of covered and so figuring out how to run security tests with Drupal 7 is our first step which should be easy because Drupal 7's testing needs are very very simple And so that's the first thing that we're working on to be able to figure out how to get core transitioned over to running tests And again, I want to emphasize what Irina said earlier. There's a lot of folks Um in the community who have stepped forward to help us test this out So there are projects that are already using their own GitLab ci yaml files that are trying different ways to build the matrix of environments and Drupal versions to test against And sharing that with us so that we can use it to create the defaults that the community is going to need to move to Um, and again, there was the Drupal spoons project that started several years ago to experiment with GitLab in general And um, they've also sort of been reintegrated and are are helping to share what they learned through that process back with us as well So, thank you to them again So I'd also like to speak to Contribution credit, which is another sort of aspects of this transition. That's a little bit challenging, right? So as far as I'm aware Drupal leads the open source world still in this concept of tracking our contributions attributing them as individuals or organizations on the clock or as a volunteer Waiting them by the usage of projects and sort of value of those contributions and aggregating that together with your other activity on Drupal.org And since that's not a tool set that exists in other off-the-shelf developer collaboration tools, including GitLab We need a strategy for for preserving that Um, but you know before I get into exactly how to do that. I want to remind us that Contribution is more than just issue credit, right? Oh, there's lots of other activity that we do. Um, that is factored into what we recognize as contribution to the Drupal project, right? So in the end what this is for is building out your profile or building out your organization profile to talk about Contributor roles that are sponsored by your company to talk about the documentation you've edited to talk about the case studies You've created but also to talk about the issue credits and the code collaboration and and those direct contributions to Drupal So I'm going to share some mock-ups that you've seen a little bit before and talk a little bit about where we're going Um, GitLab is actually interested in doing some form of an attribution in a sort of a Drupal style There's an open issue on gitlab.com to add this to the product the CEO Sid has marked it as something that he thinks would be an interesting initiative for GitLab themselves But we don't want to necessarily rely on their roadmap to block or delay our own transition over to GitLab So we're going to likely write a bot as an integration To the GitLab issues when we migrate them That will link you off to a Drupal.org kind of credit content type where you do the attribution That you remember from what you're using today And very likely as GitLab begins to add their own version of this kind of feature We'll start using that as a data source pulling it in by api to sort of simplify the process of doing the attribution Um, so that'll be coming soon and that'll be part of sort of the issue migration process And speaking of that issue migration process arena alluded to this earlier To us, it's very important to be collaborative by default in the way that we work as you know for working on Drupal.org, right? We try and identify a problem and work together on that solution in a single issue Rather than doing a sort of fork of fork model with five different options for Trying to resolve that issue worked on individually so Neil pulled some stats about the current level of collaboration. We'll share some of those and talk about what we're doing here Yeah, so Yeah, Drupal is a bit unique in that multiple people tend to work on every issue and you know, you don't know who the next person to work on the issue will be So we're looking at ways to set up the GitLab permission model to enable that And these are how many people were credited On fixed issues in the last year. So on average About six people work on every core issue And so to kind of illustrate this we put together a little Little diagram of a fork merge versus sort of a Drupal workflow that we're trying to replicate In GitLab and they've worked with us already on some Permissions issues for this so on the left So you can sort of see that traditional fork of fork of fork kind of workflow And on the right is that collaborative by default workflow that we're trying to build towards And Neil could you talk about the migration prep right so With Drupal.org we've in the past had everything locally in the database For the single site and we can Have all sorts of cross references Here we have a change record Which core in particular used it quite a bit but all of these references to issues We you know, we won't have that when it's When the issues aren't a separate software product So You know, we're going to look at ways to replace this You know replace the Link to each issue with a url and All of the in line references throughout the whole site Those will have to be replaced somehow Yeah, replace the redirects or something of that. So yeah before we even start the migration We need to audit all of Drupal.org for all of these cross references and replace them And factual migration once we have all off the credit and references and everything in place Uh, you know, we'll go kind of the same way as the other Migrations, such as issue enabling issue forks. It's project by project A few projects will be able to opt in at the start and then eventually we'll migrate the rest And you know, we're preserving as much as we can We need to do a complete migration and other than Otherwise, we'd have two issue systems if we stop halfway and then we'd have double the work for the Afterwards and I've got to shout out the Drupal spoons team again because they've already written Git lab migration code from Drupal.org metadata that we can use as a starting point when we're coming up with our sort of final solution So if you're interested in the Git lab acceleration in ways that you could be involved or just follow along There is a meta issue at that Issue short link There's the Git lab channel on the Drupal slack You can of course just help test these things as become available Leave your feedback in the issue queues just using the merger requests as they exist today and noting any issues with that workflow as well Um, you can start looking for projects that have Git lab CI enabled And if you are a maintainer just keep an eye out for more communications from us as more of these features begin to roll out And we start to do it progressively So with that I'd like to transition to q and a we have a microphone up in the center If you have any questions about Drupal.org itself about these projects or other projects that we didn't have time to sort of talk about today We'd love to take your questions. Um, we'd love to talk about the da itself Drupal.org this engineering team Anything you might have so does anybody have thoughts questions? Hey everybody. Hey, good morning. Hey, uh, first I just want to say thank you to everybody I've been doing this a while and It's a great time to be contributing to Drupal. Like all of these improvements are really incredible. Um I was having a conversation last night in person with people. It was cool But we were talking about All of the different new tools to help enable contributions. So the git lab ide talk about previews now like Drupal pod and I was Trying to explain how all of those things work together to help do things and I couldn't quite wrap my head around it So I was just wondering if all of you had ideas or any of you Uh had ideas for a kind of future state of How all of those different things could work together to enable Yeah, it's a good question. So, um to touch briefly on what some of these things are So tugboat is sort of a live preview project that'll give you a deployment preview of work in progress on Drupal.org That's sort of integrated into the Drupal.org issue queue now Git pod and therefore Drupal pod is a development environment for doing your contributions sort of all all in the cloud And I'm trying to remember. Oh git labs own ide. Yeah, we have these multiple options and The thing I will say about that is while we don't know necessarily how to rationalize them all into a single choice It doesn't hurt to let these things sort of Not compete with each other but try and sort of egg each other on into finding the best possible solution And the other advantage of moving to git lab is a standardized software stack is most of these tools can be built based on The the integration apis that git lab does have and then you brought into our own instance that we're running So, uh, I think as we get further through the migration, we may start doing more direct Integrations rather than using your you know your Drupal pod browser extension for example to to manage that stuff We'll have to get there as we get a little closer down the line Benji, please Hi, can you back up a slider to to the one with a change record? Yes, and and the problem is that So the issue link is um a separate field, but then there are Um links in the body text and those body text links that are the problem Okay You're not the first team to have this problem You you should talk to some of the migrate api maintainers. Oh, that's a good idea. Yeah, absolutely And I think um, we'll probably make a clever new text format to sort of reformat our our issue short links into uh Into new url references or something like that, but yeah, we'll reach out Um, I want to echo the thanks from everybody. You guys are awesome and taking on the lord's work. Thank you We're really excited Um, I have uh, I have kind of a hardball question and then I have a softball question to kind of balance things out the hardball question is um I don't I doubt at this stage you can give firm timelines, but do you have like a Maybe a a sequence of events of like what the major milestones are and in what order they need to fall Just so we can have an idea of Yeah, what we would be doing and I'm apologize if that was earlier I got here a little late then the softball question is if everybody could talk about their Favorite git lab feature that we get for free For free as part of this migration. So thank you. Yeah, okay. Um, so timeline wise. Yeah sequence of events again git lab ci Credit solution and issue migration are kind of the next major milestones And I think um, we're right in the beginning of q2 I'd like to see really good progress on ci through through q2 so that we can start the issue portion Maybe q3 So we're trying to move very quickly and part of the reason why you see some new faces and some new consultants Who have joined the team is to give us more capacity to do that and that was possible because Folks like Drupal association members and others supported us and made it made it possible for us to expand that team But it's it's really our primary focus. So we would um, I'm not going to make any promises But I would love to have maintainers be trans Transferring over to Git lab ci from Drupal ci q2 q3 and the beginning of the issue migration Maybe q3 q4, but we'll see there are still also some things we need to Escalate to the git lab team and make sure we coordinate lineup Oh, sorry The whole second half of the question excuse me any particular favorite issues will start from neil and just go down the line Features, yeah, I guess merge requests in general like the code That was going to be mine merge requests I like the web IDE built into git lab and the ability to do like Multiple edits and one commit from a GUI. That's also really helpful for new contributors We're going to have trouble remembering all the things Not not really because there's not that many merge requests rock for code review um, i'm peppering neil all day long with code review requests and It's so handy to be able to have like line by line commenting and then resolving of issues. That's fantastic Oh, that's the other thing we're doing it even for the internal drupal.org work We're trying to do it as much as possible in our same git lab instance to sort of practice these things Um, from my part, it's the uh in git lab ci. There's Uh, kind of a plethora of features that are like someday we're going to build this in drupal ci someday and then they're already there So for example, uh being able to bring your own containers like if you need a elastic search container so you can Run tests on your search api module. Uh, that's just built in by default You can set up whatever sort of environment you need and that's that's really exciting because that enables a lot of projects to be able to test Um, I would say mom personally since i'm a rookie i'm fresh meat coming into the drupal world Will be the expansion of the contributor roles and they're being more options in order to Build your drupal profile through contributions Since um, you know kind of new to the game One of my biggest goals is to be able to build out my drupal profile and know now that Making changes through code is not the only option in order for for me and you know New people like me to be able to build my drupal profile That's going to be very useful and it's also going to be very inspiring To you know be motivated to get in there and do other things and and say hey, I can make it change It's it might be documentation or it might any anything else that's possible to do other than coding You know, so I feel that it's going to be very useful for a lot of people awesome My favorite feature in git lab in addition to all of the above is web id Because I believe that cloud id is for coding what cms was for web publishing Some 20 years ago and having this integrated cloud solution for coding is totally amazing Uh the sidekick offload web server To expand on that um I've been running this thing for quite a while and it's gone from git web to vvc to cget to hacked version of all of those things and uh git labs process of migrating long-running processes from the main web server that serves ui to a sidekick server that can handle long running processes in a more vented Model it means it can handle around 10 times the load in testing and it pages us much less And I will add a meta feature, which is the fact that we have a literally multi-million dollar company developing new collaboration features for drupal Is really nice. They've been at least monthly releases that have include fixes that we've directly prioritized new features that we've directly asked for and um just being able to stay on the edge of that instead of doing one big effort Having to turn to other things and have our tools fall behind right that can go in parallel And we can focus on the things that are unique to the drupal community. So All right, please. Hi Thank you to everyone. This work is amazing. Um, I wanted to Share and ask your opinion on um, I see I feel like the issue migration is a huge challenge and opportunity it feels like The most visible Yeah, um transition Maybe surpassing merge requests in a way that as excited as I am about drupal ci Or a git lab ci as a maintainer like there are going to be people that are suddenly You know Reengaged with this migration in a way that they're not when they suddenly land on an issue And it's in the uh git lab And it looks like git lab. So is there a way to leverage that interest potentially? You know, I know you just shared the timeline the potential timeline For issues, but how can we get more people involved use that as an opportunity to get more people involved with this process? How can they contribute? Specifically to issues because I think that's a place where people will Potentially get excited about helping It's a really good question because we have to be super careful because of the cross references between issues We don't want to like orphan you by having hats like three projects migrated three projects not fragmented and kind of Have a confused experience. So it's something we're still thinking about. I mean neil. Did you have thoughts? Yeah, I mean Uh, we have some of the initial code from drupal spoons, but that's kind of the easy 80 percent And they have a lot of detailed migration work and you know make sure that that's all Uh, you know, we're doing a complete smooth migration. Uh so And then the other half of it is Once they're migrated figuring out the best practices for You know con bond boards and all of the features that get lab has like How do you best use those in an open source project? Productively, I will say also as you may be saw in the middle there We are planning to sort of go project by project as this goes So we will likely be soliciting people to say hey If you're particularly interested in having your process disrupted so we can learn And and giving us that feedback like we'll we'll sort of start with you as a smaller group of maintainers And be able to move from there. So there's some problems to work out first I'll take the last question and then we'll get ready for the keynote Okay, apologies if you've already covered this but um like for community projects I guess we just move our issues into git lab and then the crit the new credit bot is gonna Yeah, so we want to make sure to community projects to provide the same attribution options via the new credit bot for Noncode projects as well using that new issue queue absolutely Okay, thank you very much everyone. We really appreciate your time and in about 15 minutes the next keynote is going to be happening