Re: Dedicated hurd-amd64 build/test lab: staged results and delivery preferences

Samuel Thibault <[email protected]> Sun, 26 Jul 2026 01:45:49 +0200
Newsgroups gmane.os.hurd.bugs
Organization I am not organized
Message-ID <amVKrVK81ZiGk0HK@end>
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