Thanks @ohoral. I put them as candidates in the description. I'll move them into the milestone in the next day or so.
Thanks @ohoral and @lauraionel. I'm going to de-prioritize this one since it seems like it's a small use case and can probably be closed once gitlab-jetbrains-plugin#1388 is done.
Donald Cook (6cc9c475) at 17 Mar 19:08
Donald Cook (104bb2b0) at 17 Mar 19:08
Merge branch 'dc/fix-update-date' into 'main'
... and 1 more commit
This change modifies how the system determines the end date when searching for updates. Previously, it would search for updates up until today, but now it searches up until tomorrow (today + 1 day). This ensures that any updates that happened today are included in the search results, rather than potentially being cut off.
This change modifies how the system determines the end date when searching for updates. Previously, it would search for updates up until today, but now it searches up until tomorrow (today + 1 day). This ensures that any updates that happened today are included in the search results, rather than potentially being cut off.
Donald Cook (6cc9c475) at 17 Mar 19:05
fix: should pull in updates up until actual date
Thanks all for the thoughtful responses! Have a few follow-ups:
I've spent the last week working on https://gitlab.com/viktomas/gitlab-mr-comments, and given the intricacies of our MR commenting APIs, it would be downright impossible for LLM to make those API calls without a utility like the one I created.
I think your example here is not an outlier - there are a bunch of commands in the CLI that abstract entire workflows and are not just CRUD wrappers of the API.
@viktomas @timofurrer I understand the point that some glab commands abstract genuinely complex workflows, such as the MR commenting example. I'd push back a little on extending that to a general argument for glab as the agent interface. glab's commands originally were designed for human developer ergonomics. They're opinionated about what steps are taken and what data is returned. An LLM may need different data or a different sequence entirely.
For cases where the API is too complex for an LLM to use directly, I see two other, possibly better paths:
glab itself LLM-native. If we do go the glab route, then we should be intentional about building commands and output formats that serve agents, not just assume existing human-facing commands will work.Either way feels safer long term than making glab available and hoping the agent figures it out.
I'm not sure I understand the point. Assuming we won't rely on LLM being trained on our APIs, we have to tell it how to use our APIs. Are you suggesting that API docs are fewer tokens than CLI docs or API calls fewer tokens than CLI commands, or are you saying we should implement and maintain glab analogues as custom tools?
@viktomas To clarify: I'm not arguing API docs are fewer tokens than CLI docs. I'm saying that for an LLM with shell access, GraphQL is a more natural interface than glab for most operations. Given a GraphQL introspection schema, the LLM can query for exactly the fields it needs. glab commands return fixed output shapes designed for human readability, which may be too much or too little for what the agent actually needs.
For simple operations, glab doesn't meaningfully save tokens over a direct GraphQL call. For complex operations where glab does add value, the question is whether that value justifies the dependency, or whether purpose-built tools would serve agents better.
I think we need to move towards a place where rather than building everything very coupled to DAP we use the building blocks that other agents rely on as well, in this case
glab. Given that, if necessary, we should just take over support forglabin AI.
@bastirehm I appreciate this, but us just taking over support is exactly what I'm worried about. I have been thinking about proposing this too, but it's important that we come up with a staffing plan with intentional ownership and dedicated team members before just moving it over without the resources to actually work on it. Like I said, I have some ideas on the ownership model, but want to get alignment with Tim and product leadership before making any kind of proposal.
One last thing: @thomas-schmidt I believe you led a spike on Duo using straight GitLab APIs without our internal tools. What were the key findings? Where did the LLM struggle with raw API calls, and where was it okay? That data should help inform the decision.
@mcorren Can you please share a link to legal's request? I want to understand if there are any other solutions that we can consider, such as re-using the "experimental" features setting.
That should not have been the case. Moving it back.
Milestone 18.10 closed 2026-03-13. Scanned gitlab-lsp, gitlab-vscode-extension, gitlab-jetbrains-plugin, gitlab (monolith), ai-assist, meta, and visual-studio-extension. Docs-only issues (@uchandran) excluded from all counts — they don't consume engineering capacity.
| Metric | Count |
|---|---|
| Closed (team-owned, engineering) | 48 |
| Open (team-owned, engineering) | 12 |
| Completion rate | ~80% |
Open issue breakdown:
| Category | Count |
|---|---|
| Likely to land (MR in review) | 4 |
| At risk (in dev 2+ weeks, blocked, or no MR) | 4 |
| Stale (7+ days no activity) | 2 |
| Not started | 2 |
Red flags identified:
@tristan.read had 3 open issues, 2 marked atRisk (both Deliverables)Out-of-scope issues filtered: 4 issues on 18.10 in gitlab-lsp belong to group::ai coding or group::agent foundations, not editor extensions.
11 issues carried forward to 18.11 (with carryover notes added to each):
| Issue | Assignee | Reason |
|---|---|---|
| #1944 Extend Approve for Session | @dbernardi |
Deliverable, MR in review, tool approvals |
| #1884 MCP tools approve/disable UI | @dbernardi |
Stretch, MR in review, tool approvals |
| #1784 Workflow running twice | @elwyn-gitlab |
Beta Release Blocker, blocked |
| #1719 Don't make Duo API requests if disabled | @tristan.read |
Deliverable, severity::2 (already closed) |
| #1641 DAPv2 submit prompt/conversation |
@tristan.read/@juhee.lee
|
Deliverable, Duo UI Next |
| #2061 Decouple Node Identity | @john-slaughter |
In dev, invested effort |
| #1436 HTML Input in Duo Chat | Unassigned | Security, SLA:Breached — needs owner |
| #2095 Follow-up yaml/zod validation | @erran |
Ready for dev |
| #2022 No way to cancel command execution | @ohoral |
Ready for dev |
| #1632 DAPv2 Model Selection | @juhee.lee |
In dev, Duo UI Next |
| #2086 LS send events to Rails backend | @mosumah |
In review, observability |
3 issues cut to backlog (milestone removed): @ohoral's namespace handling, @john-slaughter's LoggerFactory, and @tristan.read's self-signed gitlab issue were resolved separately by EM.
Also noted: #592817 Accept serverCapabilities from DWS (@dbernardi) was already moved to 18.11 with missed:18.10 label. Rails MR merged, LSP MR still open.
44 total issues on 18.11 across all projects (11 carryover + 33 pre-existing).
34 engineering issues on 18.11 across all projects (11 carryover + 23 pre-existing). 5 docs-only issues (@uchandran) excluded from engineering counts.
Update: 5 issues moved to backlog per EM confirmation (see below).
All 11 carryover items plus 14 pre-existing issues aligned with Q1 priorities:
@kjamoralin), #2070 (unassigned), #2071 (unassigned)@mosumah, due Apr 8)@aspringfield), #2114 (@aspringfield/@erran), #2129 (@aspringfield)@lauraionel, Deliverable)@ohoral, missed 18.9+18.10), #1871 (@dbernardi, Deliverable)@lauraionel), #1388 (@lauraionel)@andrei.zubov, DAP GA Hard Blocker)All 5 confirmed by EM and milestones removed:
@elwyn-gitlab load: 8+ issues (blocker #1784 + 6 MCP panel subtasks #2131-#2136 + #2143). Well above WIP guidance.@tristan.read) — priority vs. Deliverable load?@erran) — still needed?@uchandran, excluded from engineering counts)#592926, #590827, #587808, #585922, #585583
Phases 4 (capacity) and 5 (build plan) pending.
@john-slaughter Is this one complete? If so, please close. Otherwise, move it to %18.11 or the backlog.
@lauraionel @ohoral Was this covered with the switch to using default namespace from GraphQL?
Milestone planning: carried forward from 18.10 → 18.11.
This issue was moved as part of the 18.10 → 18.11 milestone transition. It was in dev for DAPv2 Model Selection (Duo UI Next, Q1 priority).
If this was actually completed during 18.10, please move it back to %18.10 and close it so the milestone gets proper credit.
Milestone planning: carried forward from 18.10 → 18.11.
This issue was moved as part of the 18.10 → 18.11 milestone transition. It was in review at milestone close (observability/telemetry event forwarding).
If this was actually completed during 18.10, please move it back to %18.10 and close it so the milestone gets proper credit.