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)
0️⃣ Who is here today? Comment in the thread below to introduce yourself!
| hestenet (he/him) | Tim from the DA kicking off the threads |
| fjgarlin | Fran here :wave: Checking threads as usual. |
| markdorison | Mark from Chromatic here! :pikachu_wave: |
| irinaz | Irina, late today |
| quietone | HI, catching up. |
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.
2️⃣ Working on blockers: Per-project limits on CI/CD:https://gitlab.com/gitlab-org/gitlab/-/issues/351147https://gitlab.com/g... may have found someone who can help us get this feature over the finish line at GitLab, (and budget if needed to get it done)
3️⃣ We are getting ready to deploy pieces of the Change Record adjustments, to prepare for GitLab issues:#3265112: Decouple change records from www.drupal.org issues
| hestenet (he/him) | If you wanted to give feedback, the details were posted last meeting: https://drupal.slack.com/archives/CGKLP028K/p1660153794994589?thread_ts=... |
| quietone | I did a fair bit of work in the 'Review' tab of the CR this week and I didn't see how I would be able to do what I was doing without the tab. Even on the Review page it wasn't easy to find the issues for a given branch because there are no filters and the sort by branch does not work. |
| quietone | In the new version, I'll be using the Draft page for this. Fortunately, that does have filters, so that helps. But it doesn't filter by issue status so I will have to scan the entire page or pages to find CRs for closed issues. The colors are definitely necessary for that. That will work for me as I can see all the colors, but will it work for those who can't? |
| quietone | In the end, this exchanges scanning for versions because of the broken sort to scanning for closed issues. |
| hestenet (he/him) | cc @fjgarlin |
| hestenet (he/him) | cc @irinaz |
| drumm | We won’t have the ability to filter by issue status at all. We will be able to have the issue status loaded on the draft page, so you can visually scan through it. |
| hestenet (he/him) | @quietone In the end, this exchanges scanning for versions because of the broken sort to scanning for closed issues.Temporarily setting aside accessibility of colors(maybe we add emoji or something as well)....Is this trade-off going to be more or less acceptable for you rneeds? |
| quietone | I think 'more or less' is the best I can say until I cat test it with a page or two of CRs. |
| hestenet (he/him) | Fair. |
| quietone | What I would like is for the sorting of Introduced in branch/version to work as expected. When sorted I get results for 9 on page 1 and page 14 with 8 and 10 in between. Using the filters, I have to search for 10.x, 10.0.x, and 10.1.x, to find all the 10 ones. If the sort worked that would be one click. (edited) |
| quietone | But I also know you have lots on your plate, so no worries. I'll use the search. |
| drumm | That would be a big lift and will wait until after this part of the site is updated to Drupal 9. Views sorts are done by MySQL, which has no idea what a version number is. So a field type, or something would have to normalize the data into separate major/minor/etc columns that can be sorted on., or maybe normalize to a single int value as a weight. (If someone wants to take this on and build some gitlab pages tooling, generating this as a static site, client-side JS sorting could be done, too.) |
| quietone | Hmm. Is that really necessary? I am assuming that 'Introduced in branch' and 'Introduced in version' are strings. It would be quite workable, for me, if those fields were sorted as strings. Whatever the sort is doing it is not even that. |
| drumm | I’m not spotting the mis-sorting quite yet. https://www.drupal.org/node/2885190 is out of order because there’s a leading space. |
| drumm | Otherwise, looks like regular '9.' > '8.' > '7.' > '10' string comparison. |
4️⃣ We've been making lots of progress removing code/decoupling from version_control api:https://drupal.slack.com/archives/C51GNJG91/p1660758042960059
Participants:
hestenet, quietone, drumm
Comments
Comment #4
hestenet