This is a continuation of a discussion that went off-topic. See also this post ff. Snurg & me then had a PM discussion (in german) on the topic, drop a note to get invited (PMs are not visible for other's), we can switch to english. We welcome any valuable feedback & ideas. Let's start to brainstorm...
So you want to write a connection shim layer, plus interface (e.g. web and/or CLI dialog(1) and/or Qt's QML). This layer sits between a build manager & the FreeBSD Bugzilla, to pull in patches that are not yet commited, apply these, build & run tests in a jail or VM, all on a mouse or keyboard click. This could help the commiters, because you can provide reports on test results, success, or failure of the patch in a controlled environment, e.g. a clean jail or bhyve VM with only this one patch applied. Or a bunch of patches; however it is a well defined environment, and the test results of the tests you run within are your protocol to file back upstream.
That's a very good idea, thus it deserves a well thought out & clean architecture, i.e. clean separation of backend logic from config & UI, as well as the connection shims to both sides. Add to that list: choosing an appropriate model (OOP, functional, declarative, ...) & a suitable programming language for each part, i.e. it's common to mix models & languages in a project, instead of writing all in that one favourite model & language of yours.
How to find pitfalls before you start hacking in erroneous scripts? I mean: how to avoid mistakes before doing them, and not reinvent the wheel but make it quadratic? Managing configurations & patches is a well known domain for decades, and open source solutions to help managing it already exist. Did you search the ports for anything similar? If not there, I'd strongly guess we can find something similar in the habitat of a certain open source OS, because the folks living there have managed to survive in a djungle of patches, whose shere amount & complexity is unsurpassed by any BSD, current and those to come. If there's already s/th similar, it might be easier to add the features you're missing, than to start from scratch.
If there's nothing that's near to fulfill your requirements, let's start with writing tests, apply KISS whenever possible & follow vigole's advice ("When in Rome, do as Romans do"): we have atf(7) which uses kyua(1), so let's just stick with that.
Quickly hacking in a patch is one thing, writing a set of tests - ideally before that - it (the patched software) has to pass, is another topic...
So you want to write a connection shim layer, plus interface (e.g. web and/or CLI dialog(1) and/or Qt's QML). This layer sits between a build manager & the FreeBSD Bugzilla, to pull in patches that are not yet commited, apply these, build & run tests in a jail or VM, all on a mouse or keyboard click. This could help the commiters, because you can provide reports on test results, success, or failure of the patch in a controlled environment, e.g. a clean jail or bhyve VM with only this one patch applied. Or a bunch of patches; however it is a well defined environment, and the test results of the tests you run within are your protocol to file back upstream.
That's a very good idea, thus it deserves a well thought out & clean architecture, i.e. clean separation of backend logic from config & UI, as well as the connection shims to both sides. Add to that list: choosing an appropriate model (OOP, functional, declarative, ...) & a suitable programming language for each part, i.e. it's common to mix models & languages in a project, instead of writing all in that one favourite model & language of yours.
How to find pitfalls before you start hacking in erroneous scripts? I mean: how to avoid mistakes before doing them, and not reinvent the wheel but make it quadratic? Managing configurations & patches is a well known domain for decades, and open source solutions to help managing it already exist. Did you search the ports for anything similar? If not there, I'd strongly guess we can find something similar in the habitat of a certain open source OS, because the folks living there have managed to survive in a djungle of patches, whose shere amount & complexity is unsurpassed by any BSD, current and those to come. If there's already s/th similar, it might be easier to add the features you're missing, than to start from scratch.
If there's nothing that's near to fulfill your requirements, let's start with writing tests, apply KISS whenever possible & follow vigole's advice ("When in Rome, do as Romans do"): we have atf(7) which uses kyua(1), so let's just stick with that.
