Create roadmap for future development

[Tjzabel]

What This Issue Hopes to Accomplish

Currently, TigerOS's future is pretty flaky. I would love to be able to sit down and come up with a project roadmap for the upcoming summer/months. Then, we can break down our roadmap into actionable items to work on.

[nlMeminger]

I think in order to properly plan where we want to take this project, we will need to establish a base line for where we're starting with the current state of the project. Do we want to take what we have and continue to develope on it? Or do we want to more or less start from scratch? Knowing where we are will help us determine where we are going.

[Tjzabel]

@nlMeminger We're planning on starting mostly from scratch with the kickstarts and build scripts. Our goals are still essentially the same.

[Tjzabel]

But yes, we are definitely going to take what we have and continue with it. There's no reason to start from scratch, if you mean creating all new repositories.

[ct-martin]

@Tjzabel & I are working on having a call to triage.

Here is my list of items that need to be done, organized by priority to me (as project lead). As far as I'm aware I've addressed every open issue about TigerOS in any RITlug repo. Please let me know if I didn't address anything.

Immediate priority (critical/high/do first)

• [ ] Redo the kickstart (#149 )
  • Go straight to Fedora 30
  • Ok to not include our packages in the first pass so we can get builds working
• [ ] Get the Dockerfiles to work (#147 )
• [ ] Automated building (#29)
  • This will require output of the files
  • This will not require moving to the RITlug GitLab (the runner is also connected to GitLab.com, which can pull from GitHub)
  • For this level of priority it does not need to automatically push to the mirrors nor rebuild the repodata/ folder on the mirrors

Things do be done (preferably this summer) but not as important as the above (medium)

• [ ] Fix bugs in our main packages (similar to #148, but might not be the same bugs; RITlug/tigeros-scripts#6)
• [ ] Finally get rid of the tigeros-scripts package (#92)
• [ ] New website (#121, #122, #131)
  • I have a list of simple websites to do this summer, which includes this
• [ ] Figure out issues with (re)building repodata/ (for GNOME software center) (#133)
  • If this works we don't need our own GUI in my opinion (#55, #92 related )
• [ ] Automate pushing to mirrors (also #29)
  • [ ] Testing repos on mirrors
  • [ ] "Non-free" repos for the things we are repackaging under non-FOSS (e.g. academic use) license
• [ ] Inline with the non-free repo, make sure our licensing is correct across all packages
  • Design assets (#141)
  • Address #65 (including putting some emails I have for/from this info up publicly)

Things that can/should wait until after we finish the above

• Telegram (#154)
  • We don't have a working project at this time
  • Nice and will support after we get building again but not as important as above sections
• New onboarding/dev docs (#67, #106, #137, #146)
  • This can be one in parallel with things above, but don't block on it
• Audit ability to package software we don't currently
  • CE, CSec, new things the labs add (#134, #135)
• Aesthetic changes
  • New wallpapers (#104)
  • Revisions/tweaks to the current wallpaper and/or dark theming
• Surveying of users (#99)
• Update screenshots (RITlug/tigeros-ui-tweaks#11)

Things I do not view as a TigerOS priority at this time

• 79 (UEFI Dualboot w/ another Fedora OS)

• Moving to RITlug GitLab (#153)
  • GitHub & GitLab.com work just fine for what we need right now
  • Mirroring to/from GitLab.com has already been started & has good integration
  • The project has traditionally chosen to favor maintaining its presence on public site and I support this (particularly since we're partly targeting new Linux users, who are likely to be on GitHub but not likely to sign up for our GitLab)
  • We have registration restrictions on the RITlug GitLab
  • GitLab.com has all its features available to open source projects and we don't have an EE license on RITlug's
  • I don't want to mess with all this if we're going to change the license on RITlug's or move it to the new infra this summer/fall (seemingly likely)
• Automated testing of builds (#3)
  • Particularly given how heavily we've shifted to using upstream packages/settings (with the exception of ui-tweaks)
• Infra (#145)
  • GitLab & mirror setup/configuration/maintenance are/will be done outside of TigerOS
  • GitLab and a mirror we can push to should be enough for us right now
  • That said, we can file some issues against infra SIG for this