Skip to content
This repository has been archived by the owner on Oct 1, 2022. It is now read-only.

Create roadmap for future development #152

Open
Tjzabel opened this issue Jun 13, 2019 · 4 comments
Open

Create roadmap for future development #152

Tjzabel opened this issue Jun 13, 2019 · 4 comments

Comments

@Tjzabel
Copy link
Member

Tjzabel commented Jun 13, 2019

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
Copy link
Member

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
Copy link
Member Author

Tjzabel commented Jun 14, 2019

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

@Tjzabel
Copy link
Member Author

Tjzabel commented Jun 14, 2019

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
Copy link
Member

@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 (Rework TigerOS 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 (Make sure Dockerfiles work as intended #147 )
  • Automated building (Build automation (RPM+ISO) #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)

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

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

  • Fix Fedora and TigerOS UEFI Dualboot  #79 (UEFI Dualboot w/ another Fedora OS)
  • Moving to RITlug GitLab (Move to RITlug GitLab Roadmap #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 (Implement testing of builds  #3)
    • Particularly given how heavily we've shifted to using upstream packages/settings (with the exception of ui-tweaks)
  • Infra (New infra playbooks #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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants