Process for adding and removing github.com/kubernetes repos

[Brandon Philips]

Hello Everyone-

We have a number of repos on github.com/kubernetes all of varying quality. A few examples:

github.com/kubernetes/kube2consul - brand new no docs

github.com/kubernetes/kube-ui - no updates since Feb

github.com/kubernetes/demos-and-tutorials - created in March, no updates

I think we should create some sort of minimal process to create a new repo.

The repo to be created will first be fully made under a users personal github account and must have:

- a README outlining the project including the mailing list contact for discussion, and the slack k8s channel

- an OWNERS file outlining who is ultimately responsible

- a CONTRIBUTING file based on kubernetes/kubernetes

- a code-of-conduct.md based on kubernetes/code-of-conduct.md

- a LICENSE file with the intended license

- a RELEASE.md file that talks about the process for releases

Once all of this is created the people in the owners file can email kubernetes-dev discussing their intention to create a new project.

If this all seems reasonable I will create a github.com/philips/kubernetes-project-template that includes some of this boilerplate and make it the first thing to go through this process. And then maintain it for all new projects going forward so we at least have consistency in things like LICENSE, RELEASE, CONTRIBUTING and code-of-conduct.

Now, the tricky part is who approves the project for creation? Do we have any process for doing that? Maybe we have to get a sig to sponsor it?

Also, how do we delete a repo? Probably the simplest thing would be to just ask the owners to abandon it and ask for deletion or archive.

Thanks!

Brandon

[Clayton Coleman]

Sig sponsor makes a lot of sense - the sigs are the closest thing we have to sponsors today (in that they shepard specific needs).

--
You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAD2oYtMnhs4Su74nH_-YtJrpV8j0h21K1bDThqu0UBDLy86hMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Quinton Hoole]

+1

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16ShJebBeq4EhoWNeDrH4W7ymzFQeST6THJ%3DV414OGfUFNgQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Quinton Hoole
qui...@hoole.biz

[Brian Grant]

A project template would be useful, thanks.

The problem we have is that multi-purpose/big Github repos are unmanageable. We hit the limits of a single repo a year ago in the main repo, and lots of stuff in contrib is rotting.

We need to put new things in new repos, and we need to move existing things to new repos. Contrib needs to be eliminated.

kube-ui was obsoleted by dashboard. We could probably delete it at this point.

kube2consul was created so that PRs against the main repo could be retargeted to it.

demos-and-tutorials was created so that we could move some existing content to it, but nobody has had the time to do that. We perhaps could delete it until we're ready.

What is your specific concern?

[Brian Grant]

Also note that we moved to a multi-repo world a long time ago.

We need to make tooling work on all the repos:

* label cloning

* mungegithub (submit queue, PR assignment, OWNERS, etc.)

* CI / e2e

* release

...

We don't really have a release process for anything other than the core components (client tools, addon containers). We need one.

All licenses need to be Apache 2.

Developer docs should be overhauled and moved to their own repo.

[Brandon Philips]

On Thu, Jun 23, 2016 at 11:14 AM 'Brian Grant' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

A project template would be useful, thanks.

Great, I will try and get it built today.

 

The problem we have is that multi-purpose/big Github repos are unmanageable. We hit the limits of a single repo a year ago in the main repo, and lots of stuff in contrib is rotting.

Totally agree. kube-deploy is turning into this.

 

We need to put new things in new repos, and we need to move existing things to new repos. Contrib needs to be eliminated.

If we break contrib into 35 separate repos, is this a good outcome? It sounds intractable and puts an official looking stamp on a collection of random things.

Perhaps we should create a different github.com/kubernetes-contrib organization that can be a rallying point for stuff like this? Then we can set a really low threshold like "must be kubernetes related" to the projects and just let it be wild west.

 

kube-ui was obsoleted by dashboard. We could probably delete it at this point.

Who makes that decision?

 

kube2consul was created so that PRs against the main repo could be retargeted to it.

Should we try this process out here? Maybe have a sig sponsor the work? Otherwise it feels like this is just a nice community project that can live in someone's personal organization or git repo.

 

demos-and-tutorials was created so that we could move some existing content to it, but nobody has had the time to do that. We perhaps could delete it until we're ready.

What is your specific concern?

My specific concern is we are creating a bunch of repos that will look "officialish". When really they are just random pseudo-related projects. I want to set some sort of minimum bar so the entire github.com/kubernetes org doesn't just become a mess of half finished code like the contrib repo.

As a concrete example of this the Go developers published github.com/golang/glog a long time ago, it looks official so people use it, but in reality it is really 100% not suitable for production. They tried to put a warning in the README: "The code in this repo is for export only and is not itself under development. Feature requests will be ignored." but I see people use this package all the time inappropriately and not using more useful production stuff like github.com/Sirupsen/logrus because this is in the org.

Brandon

 

On Thursday, June 23, 2016 at 11:14:49 AM UTC-7, Brandon Philips wrote:

Hello Everyone-

We have a number of repos on github.com/kubernetes all of varying quality. A few examples:

github.com/kubernetes/kube2consul - brand new no docs

github.com/kubernetes/kube-ui - no updates since Feb

github.com/kubernetes/demos-and-tutorials - created in March, no updates

I think we should create some sort of minimal process to create a new repo.

The repo to be created will first be fully made under a users personal github account and must have:

- a README outlining the project including the mailing list contact for discussion, and the slack k8s channel

- an OWNERS file outlining who is ultimately responsible

- a CONTRIBUTING file based on kubernetes/kubernetes

- a code-of-conduct.md based on kubernetes/code-of-conduct.md

- a LICENSE file with the intended license

- a RELEASE.md file that talks about the process for releases

Once all of this is created the people in the owners file can email kubernetes-dev discussing their intention to create a new project.

If this all seems reasonable I will create a github.com/philips/kubernetes-project-template that includes some of this boilerplate and make it the first thing to go through this process. And then maintain it for all new projects going forward so we at least have consistency in things like LICENSE, RELEASE, CONTRIBUTING and code-of-conduct.

Now, the tricky part is who approves the project for creation? Do we have any process for doing that? Maybe we have to get a sig to sponsor it?

Also, how do we delete a repo? Probably the simplest thing would be to just ask the owners to abandon it and ask for deletion or archive.

Thanks!

Brandon

--

You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/9c6d0789-7841-4f2f-a50b-49b045b65476%40googlegroups.com.

[Daniel Smith]

One thing to consider-- I just sat down with someone who's going to work on getting our tooling to run against multiple repositories. Hopefully consistent tooling will make contrib & friends less of a wasteland.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAD2oYtOTef3jx163g2caHo34hFbhu-WdRi11iLe6kBY2OjSOeQ%40mail.gmail.com.

[Brandon Philips]

On Fri, Jun 24, 2016 at 4:28 PM Brandon Philips <brandon...@coreos.com> wrote:

On Thu, Jun 23, 2016 at 11:14 AM 'Brian Grant' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

A project template would be useful, thanks.

Great, I will try and get it built today.

Here is the initial draft of the template project: 

https://github.com/philips/kubernetes-template-project

Cheers,

Brandon

[David McMahon]

On Fri, Jun 24, 2016 at 5:02 PM, 'Daniel Smith' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

One thing to consider-- I just sat down with someone who's going to work on getting our tooling to run against multiple repositories. Hopefully consistent tooling will make contrib & friends less of a wasteland.

Yay.  That was on my radar too to push.  A lot of the release tooling and release notes automation is available once we can get other repos up and using the infra we use today at kubernetes proper.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAB_J3bbxXuLQrYa_3e%3D9347WX-w-EksHX_HEogegn8B0PEnWBw%40mail.gmail.com.

[Brian Grant]

On Fri, Jun 24, 2016 at 4:28 PM, Brandon Philips <brandon...@coreos.com> wrote:

On Thu, Jun 23, 2016 at 11:14 AM 'Brian Grant' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

A project template would be useful, thanks.

Great, I will try and get it built today.

 

The problem we have is that multi-purpose/big Github repos are unmanageable. We hit the limits of a single repo a year ago in the main repo, and lots of stuff in contrib is rotting.

Totally agree. kube-deploy is turning into this.

We've already started to move things out of kube-deploy.

 

 

We need to put new things in new repos, and we need to move existing things to new repos. Contrib needs to be eliminated.

If we break contrib into 35 separate repos, is this a good outcome?

A number of things in contrib should simply be deleted. I'm not sure what the right number of repos is, but we'll definitely end up with at least a couple dozen in aggregate, not just from contrib. Infra we use for testing should move to a test infra repo. Things belong together in a single repo if they have interdependencies or a common theme, AND a team of people signed up to maintain everything in that repo.

 

It sounds intractable and puts an official looking stamp on a collection of random things.

I agree we don't want random things in our repo.

 

Perhaps we should create a different github.com/kubernetes-contrib organization that can be a rallying point for stuff like this?

I agree people in the community should feel empowered to create their own repos. They don't all need to be under our org.

Then we can set a really low threshold like "must be kubernetes related" to the projects and just let it be wild west.

 

kube-ui was obsoleted by dashboard. We could probably delete it at this point.

Who makes that decision?

Which? That it was obsoleted or the deletion? As you pointed out, nobody is maintaining kube-ui. It could maybe be moved to https://github.com/kubernetes-ui, if they want it, but I'd be surprised if it stayed functional for very long without active development.

 

 

kube2consul was created so that PRs against the main repo could be retargeted to it.

Should we try this process out here? Maybe have a sig sponsor the work? Otherwise it feels like this is just a nice community project that can live in someone's personal organization or git repo.

At the moment, many areas of the system aren't really owned by a SIG. The closest for this consul service discovery adapter is maybe networking, though that's a stretch. It's something we do get user questions about, and could serve as a useful example for integrating with other discovery systems, which we've wanted for a long time (https://github.com/kubernetes/kubernetes/issues/1437). 

We have assurance that it will be tested and maintained. If it isn't, we should delete it. We can and should identify the owners and its status with respect to the project.

I agree we should develop a policy about expectations for such contributions. 

I'd like to make a similar policy about cloudprovider implementations, examples, and other contributions that we aren't able to maintain on our own. Actually, I'm much more concerned about cloud integrations / getting-started guides than with contrib. I would like to make it feasible for them not to be in the main repo, at which point they wouldn't necessarily have to live under the kubernetes github org, either.

 

 

demos-and-tutorials was created so that we could move some existing content to it, but nobody has had the time to do that. We perhaps could delete it until we're ready.

What is your specific concern?

My specific concern is we are creating a bunch of repos that will look "officialish". When really they are just random pseudo-related projects. I want to set some sort of minimum bar so the entire github.com/kubernetes org doesn't just become a mess of half finished code like the contrib repo.

Yes, that is a valid concern.

[Brandon Philips]

On Fri, Jun 24, 2016 at 5:28 PM Brian Grant <brian...@google.com> wrote:

On Fri, Jun 24, 2016 at 4:28 PM, Brandon Philips <brandon...@coreos.com> wrote:

On Thu, Jun 23, 2016 at 11:14 AM 'Brian Grant' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

I'd like to make a similar policy about cloudprovider implementations, examples, and other contributions that we aren't able to maintain on our own. Actually, I'm much more concerned about cloud integrations / getting-started guides than with contrib. I would like to make it feasible for them not to be in the main repo, at which point they wouldn't necessarily have to live under the kubernetes github org, either.

Maybe we can start slow with the cloud providers being the first external projects? They are critical to the success of Kubernetes and have a clear SIG sponsor. Plus, given we all have vested interest in cloud provider project success it is easier to rationalize getting the infra and testing stuff in place.

Then if there is great success with cloud providers we can consider other projects that are more indirectly tied to Kubernetes's success.

Cheers,

Brandon

[Brian Grant]

On Friday, June 24, 2016 at 6:04:04 PM UTC-7, Brandon Philips wrote:

On Fri, Jun 24, 2016 at 5:28 PM Brian Grant <brian...@google.com> wrote:

On Fri, Jun 24, 2016 at 4:28 PM, Brandon Philips <brandon...@coreos.com> wrote:

On Thu, Jun 23, 2016 at 11:14 AM 'Brian Grant' via kubernetes-dev <kubernetes-dev@googlegroups.com> wrote:

I'd like to make a similar policy about cloudprovider implementations, examples, and other contributions that we aren't able to maintain on our own. Actually, I'm much more concerned about cloud integrations / getting-started guides than with contrib. I would like to make it feasible for them not to be in the main repo, at which point they wouldn't necessarily have to live under the kubernetes github org, either.

Maybe we can start slow with the cloud providers being the first external projects? They are critical to the success of Kubernetes and have a clear SIG sponsor. Plus, given we all have vested interest in cloud provider project success it is easier to rationalize getting the infra and testing stuff in place.

Then if there is great success with cloud providers we can consider other projects that are more indirectly tied to Kubernetes's success.

We actually have an issue for this general topic:

https://github.com/kubernetes/kubernetes/issues/24343

I'll put some comments there.

[Brandon Philips]

Hello Harry, Dawn, and Pengfei-

I noticed y'all created a new repo in the last two days: https://github.com/kubernetes/frakti

In this thread we have been discussing how we keep the github.com/kubernetes org tidy and ensure everyone has a good idea on what is happening. Part of that is a proposal that all k8s projects start from a template project.

For frakti could you please add the things that are in the template project, like OWNERS, and also send an announcement to kubernetes-dev?

We also need to write a doc where we define how new repos get created, announced, and deleted when necessary. I hope to get this out by the end of the week.

Thank You,

Brandon

[har...@hyper.sh]

Thanks, Brandon 

we will update the repo and send a announce here very soon!

[Connor Doyle]

How about encouraging repos in the org to encode compatibility in a machine-readable way (git tag/sha)? Assuming the declared versions were tested, it could help to be more objective about what's being actively maintained, and could even be automated.

$ head meta/compat.json

{

  "kubernetes": {

    "min": "v1.2.3",

    "max": "v1.4.0-alpha.1"

  }

}

--

Connor

[Brian Grant]

This LGTM for the first version. Now which repo should we put it in? :-)

I also want to move docs/{devel,proposals,design} out of the kubernetes repo.

I think the obvious possible choices are the features and community repos (possibly renamed).

On Friday, June 24, 2016 at 5:02:43 PM UTC-7, Brandon Philips wrote:

On Fri, Jun 24, 2016 at 4:28 PM Brandon Philips <brandon...@coreos.com> wrote:

[Ihor Dvoretskyi]

I also want to move docs/{devel,proposals,design} out of the kubernetes repo.

 

+1 from me.

I suppose, we'll have to clean up the main (kubernetes/kubernetes) repo and leave only pure code (with some undetachable extras) there.

On Tuesday, July 12, 2016 at 9:41:50 PM UTC+3, Brian Grant wrote:

This LGTM for the first version. Now which repo should we put it in? :-)

I also want to move docs/{devel,proposals,design} out of the kubernetes repo.

I think the obvious possible choices are the features and community repos (possibly renamed).

On Friday, June 24, 2016 at 5:02:43 PM UTC-7, Brandon Philips wrote:

On Fri, Jun 24, 2016 at 4:28 PM Brandon Philips <brandon...@coreos.com> wrote:

[Brian Grant]

On Thursday, June 23, 2016 at 11:14:49 AM UTC-7, Brandon Philips wrote:

Hello Everyone-

We have a number of repos on github.com/kubernetes all of varying quality. A few examples:

github.com/kubernetes/kube2consul - brand new no docs

github.com/kubernetes/kube-ui - no updates since Feb

github.com/kubernetes/demos-and-tutorials - created in March, no updates

I think we should create some sort of minimal process to create a new repo.

The repo to be created will first be fully made under a users personal github account and must have:

This approach sounded reasonable, especially for new projects, but we've encountered some challenges.

1. Where we have existing code in other Kubernetes repo, it complicates ownership to move it out of the kubernetes github org to a personal repo. The github-related tools are in this category. I consider this to be just code reorganization, so I'd like to create these repos ASAP. We can reorganize them again later if needed.

2. Where people from multiple organizations want to work together on a project, we'd probably need to go through a heavy-weight donation / legal process, such as with donating a standalone project to CNCF. If we start in the Kubernetes org from the beginning, then we can ensure everyone signs the appropriate CLA, ownership is clear from the beginning, and it can be accomplished in a bounded amount of time.

3. Post-development transfers of IP even from individual companies can be more complex than incremental contributions to an existing project, as mentioned in the thread about the node-feature-discovery repo.

Could we create a repo proposal template, in addition to the full repo template, that wouldn't require creating a personal repo first?

 

- a README outlining the project including the mailing list contact for discussion, and the slack k8s channel

- an OWNERS file outlining who is ultimately responsible

- a CONTRIBUTING file based on kubernetes/kubernetes

- a code-of-conduct.md based on kubernetes/code-of-conduct.md

- a LICENSE file with the intended license

- a RELEASE.md file that talks about the process for releases

Once all of this is created the people in the owners file can email kubernetes-dev discussing their intention to create a new project.

If this all seems reasonable I will create a github.com/philips/kubernetes-project-template that includes some of this boilerplate and make it the first thing to go through this process. And then maintain it for all new projects going forward so we at least have consistency in things like LICENSE, RELEASE, CONTRIBUTING and code-of-conduct.

I forked this repo, with no changes, into the kubernetes org, to make it more discoverable.

[Brandon Philips]

On Thu, Jul 28, 2016 at 5:32 PM 'Brian Grant' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

On Thursday, June 23, 2016 at 11:14:49 AM UTC-7, Brandon Philips wrote:

The repo to be created will first be fully made under a users personal github account and must have:

This approach sounded reasonable, especially for new projects, but we've encountered some challenges.

1. Where we have existing code in other Kubernetes repo, it complicates ownership to move it out of the kubernetes github org to a personal repo. The github-related tools are in this category. I consider this to be just code reorganization, so I'd like to create these repos ASAP. We can reorganize them again later if needed.

That is fine. I think we can have a fast track for "code moves". Probably makes sense to still write to kubernetes-dev.

 

2. Where people from multiple organizations want to work together on a project, we'd probably need to go through a heavy-weight donation / legal process, such as with donating a standalone project to CNCF. If we start in the Kubernetes org from the beginning, then we can ensure everyone signs the appropriate CLA, ownership is clear from the beginning, and it can be accomplished in a bounded amount of time.

Hrm, OK. I don't know how to resolve this. I don't think we should just start throwing out repos to anyone who comes up with an idea either. Perhaps we say you have to: use the same email as you use for Kubernetes CLA and you must declare the ownership to the CNCF?

What do you mean by bounded amount of time?

Do we know for sure that the donation / legal process is complex for moving repos?

 

3. Post-development transfers of IP even from individual companies can be more complex than incremental contributions to an existing project, as mentioned in the thread about the node-feature-discovery repo.

OK, perhaps we create github.com/kubernetes-incubator? Or we prefix every new project with incubator-$FOO and people have 3-6 months to make the case that the project is important through releases, community, and users? If the case can't be made we ask that they pull the repo out.

 

I forked this repo, with no changes, into the kubernetes org, to make it more discoverable.

Can you make me owner of the fork so I can keep it up to date, if necessary?

Thank You,

Brandon

[Connor Doyle]

On Tue, Aug 2, 2016 at 2:49 PM, Brandon Philips
<brandon...@coreos.com> wrote:

> Do we know for sure that the donation / legal process is complex for moving repos?

In our case moving the repo isn't a big deal. Prior to moving however,
the repo needs to be public and that requires new approval.

+1 for incubator prefix, follows precedent from the ASF. It would be
helpful to make the criteria for "graduation" from incubator status
explicit ahead of time so owners know what to shoot for and decisions
remain transparent and consistent.

--
Connor

[Brian Grant]

On Tue, Aug 2, 2016 at 4:32 PM, Connor Doyle wrote:

On Tue, Aug 2, 2016 at 2:49 PM, Brandon Philips

 wrote:

> Do we know for sure that the donation / legal process is complex for moving repos?

It was for kubernetes. :-)

 

In our case moving the repo isn't a big deal. Prior to moving however,
the repo needs to be public and that requires new approval.

+1 for incubator prefix, follows precedent from the ASF. It would be
helpful to make the criteria for "graduation" from incubator status
explicit ahead of time so owners know what to shoot for and decisions
remain transparent and consistent.

I like the idea of a kubernetes-incubator org. Practically speaking, github and go support moving repos reasonably, but don't really support renaming repos very well.

[Brian Grant]

On Tue, Aug 2, 2016 at 2:49 PM, Brandon Philips <brandon...@coreos.com> wrote:

On Thu, Jul 28, 2016 at 5:32 PM 'Brian Grant' via kubernetes-dev <kuberne...@googlegroups.com> wrote:

On Thursday, June 23, 2016 at 11:14:49 AM UTC-7, Brandon Philips wrote:

The repo to be created will first be fully made under a users personal github account and must have:

This approach sounded reasonable, especially for new projects, but we've encountered some challenges.

1. Where we have existing code in other Kubernetes repo, it complicates ownership to move it out of the kubernetes github org to a personal repo. The github-related tools are in this category. I consider this to be just code reorganization, so I'd like to create these repos ASAP. We can reorganize them again later if needed.

That is fine. I think we can have a fast track for "code moves". Probably makes sense to still write to kubernetes-dev.

Any major code reorg, whether intra-repo or inter-repo should be announced on kubernetes-dev.

 

 

2. Where people from multiple organizations want to work together on a project, we'd probably need to go through a heavy-weight donation / legal process, such as with donating a standalone project to CNCF. If we start in the Kubernetes org from the beginning, then we can ensure everyone signs the appropriate CLA, ownership is clear from the beginning, and it can be accomplished in a bounded amount of time.

Hrm, OK. I don't know how to resolve this. I don't think we should just start throwing out repos to anyone who comes up with an idea either. Perhaps we say you have to: use the same email as you use for Kubernetes CLA and you must declare the ownership to the CNCF?

What do you mean by bounded amount of time?

Do we know for sure that the donation / legal process is complex for moving repos?

 

3. Post-development transfers of IP even from individual companies can be more complex than incremental contributions to an existing project, as mentioned in the thread about the node-feature-discovery repo.

OK, perhaps we create github.com/kubernetes-incubator? Or we prefix every new project with incubator-$FOO and people have 3-6 months to make the case that the project is important through releases, community, and users? If the case can't be made we ask that they pull the repo out.

 

I forked this repo, with no changes, into the kubernetes org, to make it more discoverable.

Can you make me owner of the fork so I can keep it up to date, if necessary?

Thank You,

Brandon

--

You received this message because you are subscribed to the Google Groups "kubernetes-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAD2oYtM3YwvWRdtKxdk4KTMR4wPDDM-Swc_OHZfiFOSQsW5tWg%40mail.gmail.com.

[Brandon Philips]

Update: I am working on a proposal for the incubator stuff and will try and post it tomorrow.

[Prashanth B]

There's a parallel proposal of building out sig specific repos where members can collaborate to produce something worthy of one of the Kubernets/ repos:https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-dev/MhQl2GBylgM/8xIFA9-qBAAJ, maybe we can streamline with the nascent incubator idea? 

[Connor Doyle]

+1 vote for (if anything) a single bucket of incubating projects:

• One place to look for ongoing contrib work.
  
• Less confusion about where cross-cutting projects should live.

[Brandon Philips]

Hello Everyone-

I put together a proposal for a Kubernetes Incubator Process. Please take a look:

https://docs.google.com/document/d/1ugAd9Zj-jW3YHdrNVdktmvDMEWtChPqyGHfkwWdQ3zo/edit#

The demand for new projects outside of the central repo is overwhelming right now; I look forward to getting this all in place ASAP. It won't be perfect but the current situation is on 🔥.

Thank You,

Brandon

You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/e5c4c8d6-da52-4168-95dd-b6f39c4551fe%40googlegroups.com.

[Brandon Philips]

Hello Again-

Discussion has leveled out on the proposal. So, I think the next step is for this document to be moved into the community repo[1].

Once that is merged I think we can start to accept new incubator projects and work with the existing repo owners[2] to move things around.

Cheers,

Brandon

[1] https://github.com/kubernetes/community/pull/46

[2] https://github.com/kubernetes/community/pull/46/files#diff-d66fe60fa798362c1490f82a966a6e89R95