**TODO: Prioritize this list JIRA style.**
Tracking task for stuff to fix after the next release:
**Super High Priority** (This is post ferryd deployment)
- [x] `ferryd`. **Seriously**.
- [ ] Replace broken-ass-third-party ! (@ikey attending [Ubuntu Rally](https://insights.ubuntu.com/2017/09/01/ubuntu-rally-in-nyc/) in NYC to work on this, end of September)
- [ ] X stack update (mostly just the server 1.19+ & driver rebuilds)
- [ ] @ikey: Document stateless, best approaches, IRC tribal knowledge on Help Center
- [ ] CLEAR DIFFUSSION BACKQUEUE.
**Post ferryd high-priority items here** (Might need de-duping and organising!)
- [ ] Sort out [samba and Nautilus](https://dev.solus-project.com/T1223) (//This is @JoshStrobl's task, no touchy!//)
- [ ] 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 + crusty library providers, i.e "webkit1", consolidate them
- [x] Draw up a formal sync cycle (i.e. how to remain unblocked and maintain high velocity)
- [ ] [GNOME 3.26 stack upgrade](https://dev.solus-project.com/T4532)
- [ ] Evaluate toolchain options (sane toolchain, and ensuring Clang works as well as GCC at minimum)
- [ ] 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
- [x] 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. (Note: flatpak is no longer the universal app solution we initially agreed to adopt, rather, it is a //meta-distro//)
- [ ] 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)
- [ ] First-class hybrid GPU support (i.e. `linux-driver-management`, Optimus, and dynamic GPU switching, with OS/desktop integration)
- [ ] Implement a TLP alternative (so people get better battery life without the risk of their drive randomly unmounting or wireless being a spud)
- [ ] Dramatically increase hardware support no matter what it takes (i.e. "dodgy" printers)
- [ ] KDE/Plasma stabilization
- [ ] OEM installer mode
- [x] Support AppArmor LSM
- [ ] Fix conformance checking for licenses in packages
- [ ] (EVENTUALLY) Switch `eopkg` and `ypkg` to clang by default, allow disabling Clang on a per-package-basis (Supported this for a long time, just flip the default now)
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.