We’re early enough in the design to be able to change things as necessary without it being a huge upset since the stakeholders don’t have an existing product in use that is being changed, so long as the marketing of any subprojects associated don’t have to change either.
This is good, because I’ve been going about it all wrong.
I’ve been trying to automate the creation of the bootable build environment using several layers of bootstrapping which I believe can be done in a single run but should not be.
Instead, after a month or so of re-examining how this might work with various folks involved, I’ve decided that the path forward is with providing a bootable build ISO as the cycle 0.
This hits many aspects of the overall project, but, the two most notables are that first, it will provide a separate subproject as a bootable ISO that will allow users to still create their own distribution, which can be expanded on later with further automation for common tasks and decisions that would go into distro creation.
Secondly, this will allow us to make derivative or cascading changes to the full distro by modifying the build ISO as necessary.
Since we are dividing an entity we’ll need a name for the bootable ISO subproject.
Names are hard for open source projects and they’re more important than people give them credit for. The name of a project should reflect its purpose.
SURRO Linux is already taken by the main project, although, I greatly admire that the bootable iso is functioning as a surrogate linux environment for a build.
Probably Foster. I’ll see what the designated greybeards think.
Speaking of entities, articles of organization are in progress.
Update: We went with Foster. Thanks to Prawn for his judicial use of silent approval.