**TODO: Prioritize this list JIRA style.**
Tracking task for stuff to fix after the next release:
- [ ] `ferryd`. **Seriously**.
- [ ] X stack update (mostly just the server 1.19+ & driver rebuilds)
- [ ] Rebase on new systemd
- [ ] Swap out `goofiboot` for upstream `systemd-boot` and lose some technical debt
- [ ] Reintroduce `libgudev` to assist in the migration, consider base-level hard dep to ensure it gets in on upgrade
- [ ] Examine the state of various `mozjs` `spidermonkey` providers
- [ ] Dropkick old + crust library providers, i.e "webkit1", consolidate them
- [ ] Draw up a formal sync cycle
- [ ] Evaluate toolchain options
- [ ] Automate security advisories, integrate Solus in upstream discussion points
- [ ] Add a lot more testing to Solus, both at the package level `%make check` and at the QA pipeline level. Track these metrics (perf, use case, etc)
- [ ] Ensure package "lintian". i.e. all packages should use particular standards and filesystem layouts. Document it.
- [ ] Expand solbuild - allowing sandboxed dbus, X11, etc, to allow PGO, test suites and such
- [ ] Produce a solid stateless definition //within the context of Solus// - provide management tooling for this too. Undocumented hard to use stateless isn't much help.
- [ ] Evaluate stateless system account options, i.e. `nss-altfiles`, etc. Using `systemd-sysusers` is frankly an immature approach and leaves junk behind.
- [ ] Convert at least 98% of all Solus packages to our `ypkg` build format.
- [ ] Centralise actionable scripts for drivers and providers in `mesalib`, `xorg-server` and `nvidia-*` to `kernel-integration` package
- [ ] Add `snapd` - instead of backing a single format we'll support **both Flatpak and Snaps** and maximize user choice. This also ensures Solus is not tied to any single provider.
- [ ] Add analysis of image and build artifacts to ensure packages and images are consistent with "the Solus way" (FHS, build flags, RELRO, canary, etc)
- [ ] `eopkg` -> `sol` (next gen system software/framework management)
- [ ] Massively increase number of maintainers by orders of magnitude through onboarding of the community with explicit package & domain owners. Depends on `ferryd`.
- [ ] Include a more aggressive source pipeline - i.e. CI will incorporate static analysis, etc, where appropriate. Expose patch repository for the use of other projects and ensure there is a tracked upstream effort on agnostic Solus changes
Solus is partly stateless in some places, but not **enough**. It also relies on a partial definition from Clear Linux, but has never bothered to define it further within the context of Solus.
It is also true that new users may be confused by the stateless approach taken by some packages. Thus, an OS-wide stateless policy will be defined, which all packages must then
obey. Additionally, it should be done so in a fashion that would enable an automated tool to manage policy-compliant stateless packages "all in one shop". Said tool should also support
exporting a system diff and the application of said diffs for management and deployment. The tool is less important than actually documenting the changes and having them stateless. If such a tool is built, it should be done so in a completely agnostic fashion.
**Refined mission statement**
If you can stomach the marketing spiel - this is heart of Solus:
> A safe and reliable vehicle to guide, guard and enable the user's journey through a shifting tech world, to their destination and beyond.