Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What kind of process should we have to decide what drivers to adopt / give repos? #1

Open
3 tasks
SvenDowideit opened this issue Jan 22, 2018 · 3 comments

Comments

@SvenDowideit
Copy link
Member

SvenDowideit commented Jan 22, 2018

  • do we need to be selective?
  • are there any open source drivers we want/need to not accept, or track in this org?
  • ... please add other questions :)
@SvenDowideit
Copy link
Member Author

IMO (separate from creating this issue), is that we should collect all machine drivers here, even if they're just mirrors of upstream drivers. That would enable users to have one common collation point - and for mirror repos, we'd turn off issues&pr's - and possilby automate syncing.

the utterly distributed nature of the drivers atm is both awesome wrt getting things done, and terrible wrt finding things, and being able to fix larger scale problems in the code.

@r2d4
Copy link

r2d4 commented Jan 23, 2018

Is there an testing plan in place yet?

I think that whatever drivers that are here need need to be tested. The testing infrastructure has historically been difficult, since there are a few different OSes and each requires virtualization to be enabled. In minikube, we've solved this by a combination of physical machines as well as VMs with nested virtualization enabled. However, the cost of maintenance is high.

@afbjorklund
Copy link
Contributor

Don't have any automated tests in place yet, so just experimenting on users (including myself)

This was for qemu (and kvm/kvm2). Using virtualbox as the reference driver, in case of doubt...

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

No branches or pull requests

3 participants