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

Figure out initial WGs, based on existing PMCs and Projects #7

Closed
chipchilders opened this issue Sep 25, 2020 · 5 comments · Fixed by #31
Closed

Figure out initial WGs, based on existing PMCs and Projects #7

chipchilders opened this issue Sep 25, 2020 · 5 comments · Fixed by #31
Assignees

Comments

@chipchilders
Copy link
Contributor

Document proposal for initial WGs, based on existing PMCs and Projects

@loewenstein
Copy link

Should we get to a list of WGs here or directly on a PR?

As a general question, should we try the most basic mapping, which is either PMC ~ WG or project ~ WG? The former might be too coarse grained and too close to "we just renamed PMC to WG. The latter might be too fine grained.

I could see the following, but don't have a list of projects at hand currently:

  • Application Runtime (or Container Scheduling)
    • Garden
    • Diego
    • Eirini
    • Windows container
  • Security
    • UAA
  • Networking
    • Gorouter
    • cf-k8s-networking
  • Release Engineering/Integration
    • cf-deployment
    • cf-for-k8s
  • API
    • capi
    • cf cli?

There's already some open questions like mTLS, which is done in cf-k8s-networking, but a Security WG would probably want to be involved, although UAA project members don't seem to be the ones particularly interested.

loewenstein pushed a commit that referenced this issue Oct 9, 2020
@loewenstein
Copy link

Actually, #31 was now much smaller and didn't solve this issue.

@loewenstein loewenstein reopened this Oct 12, 2020
@chipchilders
Copy link
Contributor Author

We need to create a rough straw proposal, perhaps just using the example from above, in order to help people understand the ideas being expressed. Should also have a clear statement that this is a rough idea and the initial TOC will need to work with the community to set the full initial schedule.

@chipchilders
Copy link
Contributor Author

Thought from Julz - CLI and API should be broken apart... client vs API. Perhaps group Stratos and CLI.

@loewenstein
Copy link

This is quite obsolete

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

Successfully merging a pull request may close this issue.

2 participants