Hello Samuel and jbranso, Thank you for the quick and welcoming feedback!
Rest assured, human accountability is 100% central to this model: I personally review, understand, and sign off on every patch submitted, and I will be the one discussing and iterating on them with you. Based on your guidance, I will route the staged deliverables as follows: 1. Debian Package Portability Fixes: - Submitted via Debian BTS (tagged 'hurd' with X-Debbugs-Cc: [email protected]) and forwarded to upstream package repositories. 2. Core Kernel, Mach & System Findings: - Posted directly to bug-hurd as clean, plain-text email threads. I will start by submitting a single clean portability patch to the Debian BTS to establish a smooth, low-overhead workflow before sending anything else. On the infrastructure side, the lab runs on a modest desktop host (Proxmox with 16 GB RAM, consumer Ryzen board, pairing an automated build/triage container with a native Hurd QEMU instance). The main value comes from continuous goal-directed iteration, allowing the agent to handle the repetitive triage so I can bring clean, curated findings out of it. I am using hermes-agent with Kimi at the node, and Claude Code on my laptop to audit and polish results. Looking forward to collaborating! Best regards, Fede El sáb, 25 de jul de 2026, 11:45 p.m., Samuel Thibault < [email protected]> escribió: > Hello, > > Federico Bonino, le sam. 25 juil. 2026 19:51:26 +0000, a ecrit: > > - First and foremost: Do you agree with this collaborative model, and do > you > > welcome this lab's assistance in triaging build failures and isolating > > reproducers for GNU Hurd? > > Any help is welcome :) > > Provided that the submitted patches are taken care of by humans. They > can be inspired by LLMs, but we do want humans in the loop, who do > understand what the patch is doing and ready to iterate over it. > > > - If so, which channel and format do you prefer for receiving these > > deliverables? > > > (e.g., individual Debian BTS bug reports tagged 'hurd' for > > package fixes, > > For packages fixes, ideally you send them directly to upstream, because > they are the ones to be convinced ultimately. > > If the fixes are for the debian packaging, a Debian BTS bug report is > good, you can put [email protected] in X-Debbugs-Cc and tag > it 'hurd'. > > > email threads on bug-hurd for core kernel/Mach issues, or git > > format-patch emails?) > > Both are fine, the important point is that it ends up as plain text in > the mail, so it's easy to discuss over it. > > > - What delivery cadence works best for your review capacity? > > It's hard to give a number since patches can be trivial or very lengthy, > with 10x-100x processing time potential. > > Samuel >
