[GSoC 2026] Proposal Draft: Unified Sandbox Driver Architecture (Project #10) #21240
pratyush07-hub
started this conversation in
Ideas
Replies: 1 comment
-
|
From my point of view, this proposal gets much stronger if it makes the migration path explicit from the current branching logic to the future driver boundary. The key question is not only what the SandboxDriver interface looks like, but how existing behavior stays testable while backends are moved behind it one step at a time. A capability matrix plus compatibility tests for each backend would make the architectural direction much easier to trust. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi Gemini CLI Team,
I am Pratyush Kumar, a Junior IT student and active contributor to the Plone Foundation (Volto) with a track record of merged PRs. I am confident in my ability to handle the technical scope of the Gemini CLI and have prepared a draft proposal for the 2026 cycle.
Currently, I am deep diving into the codebase, specifically focusing on the existing logic in
sandbox.tsandrelaunch.ts. I am exploring the file structure and planning to open new issues and PRs regarding my findings (such as improving error logging for silent sandbox failures) very soon. Instead of a full breakdown here, I’ve prepared a detailed Approach in the draft linked below.I’m looking for feedback specifically from @NTaylorMullen and @galz10 on whether my proposed implementation aligns with the CLI's 2026 roadmap or if I should rethink my direction before the final submission.
Draft Proposal: [Google Drive Link]
I am eager to iterate on this based on the team's requirements.
Beta Was this translation helpful? Give feedback.
All reactions