Proposed Boots roadmap

[jacobweinstock]

The following is a proposed roadmap of work items for Boots.
They are not ordered in terms of priority.
I don't know if we can get a Github project created in this repo to maybe track these.
If so, I can create all the tickets.

• define design philosophy
• turn up golangci-lint
• document coding style guide
• document data model relationship to code logic
• installer registration explicit
• all environment vars defined in func main
• use github.com/peterbourgon/ff for flags, env vars, config file
• reorg package structure
• proper context passing
• document versioning strategy for the codebase
• incorporate goreleaser
• customizable DHCP options
• customizable kernel args
• move default git branch to main
• move all panics to func main
• move logging to github.com/go-logr/logr
• move osie installer to hook
• add DHCPProxy functionality
• add DHCP pools
• add hardware discovery functionality
• add custom ipxe script with network retries and custom user-class name
• add stack stand up capability
• remove/avoid global/package level variables
• remove cacher dependency
• remove git-lfs dependency
• remove installers other than a default
• remove syslog
• remove hardware discovery endpoint
• remove Equinix Metal specific code
  • dual provisioner lookup
  • hollow
  • EM api calls
  • EM specific http endpoints
  • etc
• refactor to make all funcs/methods explicitly require their dependencies
• add functional testing
• Increased unit testing
• Add support for UEFI HTTP Boot #210

[rgl]

I think #210 is worthy too :-)

[displague]

@jacobweinstock I think we should create trackable issues for each of these items (although some items may fit into the same issue). This roadmap issue contains items that could extend for sometime. The bulleted items are missing context that would be provided in a dedicated issue. Those issues can be linked to in the bulleted list above. I think we could then create a meaningful epic of this issue, targeting a specific goal achievable by completing some set of the bulleted items (roadmap is not a specific goal). As you point out, instead of using a tracking issue, we could make a project geared towards specific goals if we have a clear goal and a path to achieve it.

I don't have the option of creating a project, but I can create a milestone and I think this could work well enough for now.

Since we are currently at v0.6.0, we could create v0.7.0, v0.8.0, and v1.0.0 milestones. These issues could be placed in the slot that seems most likely to match efforts. If something is 'broken' it should land in v0.7.0. If it requires more thinking or coordination, it can land in a later milestone. We can move items around as releases happen and we fit features in or need to push them back.

[displague]

When linking items in this list, let's link to issues rather than pull requests. Pull requests have a tendency to be too broad or incomplete towards resolving any one issue, PRs can also be revertible and misguided.

Let's let issues represent the ask and pull requests represent some effort that may or may not fulfill some asks. In the issues that we create we need to do a better job of defining what it means to be done. For example, I replaced the last item in the bulleted list with #210, but looking back at this issue I have no idea how to suggest a user take advantage of this feature. We didn't track a need for documentation to be provided before the issue could be closed.