Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.This meeting:
➤ Is for core developers, initiative contributors, the Drupal Association and anyone interested in the initiative.
➤ Usually happens every other Wednesday at 11:00 PT / Thursday 06:00 UTC
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Lots of threads get posted all at once! Don't worry - start at the top and then jump into the threads that most interest you.
➤ Has a public agenda anyone can add to in the issue
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.
ping: @mixologic @FeyP @jurgenhaas (go to the issue of the next meeting to add or remove yourself from the list)
Transcript
0️⃣ Who is here today? Comment in the thread below to introduce yourself!
| moshe | :wave: |
| hestenet (he/him) | Tim from the DA over here in Portland. Still feeling the good vibes from DrupalCon :slightly_smiling_face: |
| Nick_vh | Nick from Gitlab here! Belgium :) |
| irinaz | Hi, Irina, working from California, Bay area |
| markdorison | Hi! Mark from Chromatic here in St. Petersburg, FL |
| mixologic | Ryan, catching up |
| dww | Derek from TEN7, catch up late |
1️⃣ Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion. Conversation moving slow? Go ahead and open your own thread in the next numeric order.
| Nick_vh | I would love to encourage everybody to check out the CRM functionality of gitlab as I think it could be a good data architecture for the credit system for both projects |
| Nick_vh | It's a MVP in production right now, but good to get knowledge |
2️⃣ :thankful: to everyone who helped update the architecture issues with the methodologies you used. This is an important part of consolidating the default yml file.Especially starting with this one: #3265118: Universal Validation Steps
3️⃣ We still need forward momentum on per-project CI Limits in GitLab.This issue is accepting Merge Requests, and a GitLab dev has pointed out some relevant code areas - if anyone wants to try and take a crack at it.We'd love to get GitLab to help us implement this, but starting an MR may be the best way to get some attention.https://gitlab.com/gitlab-org/gitlab/-/issues/351147
| irinaz | @Nick_vh I plan to look into forking this repo https://gitlab.com/gitlab-org/gitlab/ - can you confirm that this is correct one. thanks! |
| Nick_vh | That's correct! |
| Nick_vh | Once you have an MR, you indeed will have more chance for attention :) |
4️⃣ There was a bunch of discussion on Twitter and on the Issue queues about removing the git info in favor of linking to the GitLab activity instead.[#3253658]This is a solid example of custom commit parsing that we want to avoid continuing to maintain in this transition.We should be able to very quickly make some improvements:Linking to the gitlab profileIncreasing the time window on the issue credits displayBut to the extent that folks think we still need counts of commits per project on top of those things, we'd need to do it using the GitLab APIs.(edited)
| irinaz | Question to Gitlab experts. We are looking for number of commits per-project, by user. I can see GitlabAPI call for number of commits per-project, but I do not see an option to group/sort/parse by user. |
| dww | At the issue I proposed restoring the bespoke feature until either:We implement a replacement using GitlabWe're done with everything else, ready to cut over, and #1 still isn't done.I completely understand the need to stop having so much bespoke functionality, but I don't see why we have to already remove this thing that lots of folks clearly want / depend on. Let's only remove it once we have something to replace it with, or we have no other choice. Thanks! |
5️⃣ Best practices for overriding default templatesAs we get closer to having default templates available across more projects, we will need to start documenting the best practices for overriding the defaults with custom functionality.This is part of the change in thinking from: This has to be a centrally managed feature request, to... I can add this cool custom new linting step to just my project if I need it. (for example)Are there good existing GitLab docs about doing this? What are key elements of these docs that we need to provide?
6️⃣ We've found an easy solution for having contributors accept the 'git terms of service' - GitLab has a very easy way to configure a terms of service that must be accepted on next login.This will let us simplify the account sign up process so there are fewer steps to go from no account to first contribution.
| hestenet (he/him) | Screen Shot 2022-05-16 at 10.42.57 AM.png |
| hestenet (he/him) | cc @mlhess (Should save us from having to do anything custom in keycloak) |
| mlhess | Awesome |
7️⃣ Timeline updates:GitLabCI - we're frankly farther behind than we would like, as mentioned in a thread in last meeting. We're focusing on clearing blocker/urgent core tasks and other items so we can refocus here further. Decoupling from bespoke git tooling is proceeding nicely, which is getting us closer to implementing the credit system/preparing for issue migrations (this is not going to be quick, but it's moving at a steady pace.
| hestenet (he/him) | Speaking very frankly - part of the timing issue is that we consistently have to pull away to help support the core release process with things like guzzle min/max testing, packaging updates, and fixes to the broken D10 project analysis bot (those are the ones currently in flight, so on my mind).We are trying to reach a point where those things can ride stable enough to wait for the new GitLabCI system to come online for future changes, but it's tough when we're trying to make sure D10 has everything it needs. |
| markdorison | Thanks for the transparency! |
| dww | Given the fallout on #3253658, would it be possible to do more of this decoupling in a branch for a future deploy, instead of deploying each removal as soon as it's done?In general, can we wait to remove things that don't already have a viable Gitlab replacement until we either:have a chance to find/build a Gitlab-friendly replacement orare completely ready with everything else and have no other choice but to remove the bespoke stuff?? |
| hestenet (he/him) | It's tricky because there's no 'big bang' moment where everything cuts over. These are all component parts of doing the changeover - they need to happen sometime, and getting these items out of the way is less to maintain while we're getting credit and issue migrations together. |
8️⃣ Exploring whether the CRM feature of GitLab could be adapted to feed credit data.GitLab CRM: https://docs.gitlab.com/ee/user/crm/ (edited)
| hestenet (he/him) | Raised by @Nick_vh |
| hestenet (he/him) | The ability to link issues to contacts and organizations seems like it has some potential.. |
| hestenet (he/him) | I would wonder about the permission model though - can contacts be linked to user accounts?And if you give people permission to add contacts, does it expose emails? |
| hestenet (he/him) | Might be some feature request/changes that would be needed to make that possible. |
| hestenet (he/him) | Also - can a contact be associated with multiple orgs and/or no org? |
| hestenet (he/him) | ^^ All questions we would need to explore. |
| Nick_vh | I asked the one who wrote it for the roadmap, possible futures are 1 to many relations with organizations. Inheritance of users as contacts in the group coming from the gitlab instance. Making organizations a top level thing and do the same as the inheritance of users. |
| Nick_vh | I am meeting him next week and will write the meeting notes in the gitlab issue |
| hestenet (he/him) | Nice - okay - those would all help quite a bit |
| Nick_vh | Also support for MRs instead of only issues for example |
| Nick_vh | Unless that is lesser of an issue, but I don't see why it should not be generoc |
| Nick_vh | Generic |
| Nick_vh | I would advice to experiment with the CRM quick actions, it's almost as if it was made for a credit system :) |
| hestenet (he/him) | 'CRM quick actions' - okay! Will make note to look at that. |
| irinaz | Maybe starting with a bot that will provide this data will get us to solid credit system quicker than creating place to store this information in Gitlab CRM |
| Nick_vh | It is available on gitlab.com so making a new group and enabling this CRM functionality should be fairly quick to do and to assess |
| hestenet (he/him) | I am thinking we ultimately still need a d.o credit entity - so whether we start by feeding it from a bot and then adapt to using CRM features if they all work - would give us flexibility |
| Nick_vh | Totally, but if you can "leverage" the UI components already and show more easily who is credited for example, it can already be a quick win |
| Nick_vh | Up to you |
| hestenet (he/him) | Yes, true. |
| hestenet (he/him) | Definitely should be looked at. |
| Nick_vh | I'm thinking you only need 1 to many relations to get started. Because then you can feed that table externally or keep that in sync with whatever other system |
Participants:
Nick_vh, irinaz, dww, hestenet, mlhess, markdorison
Comments
Comment #2
bbralaComment #8
hestenet