{"action":"created","issue":{"url":"https://api.github.com/repos/kubernetes-incubator/service-catalog/issues/79","repository_url":"https://api.github.com/repos/kubernetes-incubator/service-catalog","labels_url":"https://api.github.com/repos/kubernetes-incubator/service-catalog/issues/79/labels{/name}","comments_url":"https://api.github.com/repos/kubernetes-incubator/service-catalog/issues/79/comments","events_url":"https://api.github.com/repos/kubernetes-incubator/service-catalog/issues/79/events","html_url":"https://github.com/kubernetes-incubator/service-catalog/issues/79","id":192665470,"number":79,"title":"Make this repo in kubernetes' image","user":{"login":"pmorie","id":366488,"avatar_url":"https://avatars.githubusercontent.com/u/366488?v=3","gravatar_id":"","url":"https://api.github.com/users/pmorie","html_url":"https://github.com/pmorie","followers_url":"https://api.github.com/users/pmorie/followers","following_url":"https://api.github.com/users/pmorie/following{/other_user}","gists_url":"https://api.github.com/users/pmorie/gists{/gist_id}","starred_url":"https://api.github.com/users/pmorie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pmorie/subscriptions","organizations_url":"https://api.github.com/users/pmorie/orgs","repos_url":"https://api.github.com/users/pmorie/repos","events_url":"https://api.github.com/users/pmorie/events{/privacy}","received_events_url":"https://api.github.com/users/pmorie/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2016-11-30T20:06:39Z","updated_at":"2016-12-06T16:32:56Z","closed_at":null,"body":"We have addressed this concern piecemeal in a couple different places, but I think it is advantageous to open a high-level issue for it and explain the rationale in detail.\r\n\r\nI propose that we make the service-catalog repo, to the closest possible degree, similar to the main kubernetes repo.  This includes things like project layout, development tooling, dependency management, and other facets of developer experience.\r\n\r\nMy rationale for this is:\r\n\r\n1.  In many, many ways, the eventual shape of the project we have discussed is very similar to Kubernetes - we are basically building a Kubernetes-like system with a smaller problem space\r\n2.  I expect that as this project becomes known and popular, that there will be a large influx of people from the wider community; it will save all of us time and effort if someone familiar with Kubernetes at a development level can understand how to internalize and develop on service-catalog with minimal mental context-switching\r\n3.  We are one of the first incubator repos that has the smaller-kubernetes shape, and I would like to be able to point to our repo as a how-to example for future such projects (I expect there will be very many of these once API federation is baked into how)\r\n4.  If we want assistance from Kubernetes maintainers (as I expect that we will when we get to things like API conversion generation), it is most time efficient if they do not have to learn a new project structure\r\n5.  Much of the tooling around code generation that we will want to pull in is very opinionated about project structure, and the path of least resistance is conforming to those opinions rather than trying to change the tooling to be more generic\r\n\r\nWith that said, I realize that this is a big ask from the group.  I have tried to make a good case for the ask on the merits, but I also want to acknowledge the fact that it is an ask.  Some reasons why it is an ask:\r\n\r\n1.  Developers like to make projects structured the way they like and are used to, and most people in the SIG are new to the Kubernetes world to some degree\r\n2.  Certain aspects of this ask might be alien to folks who have used go in the past in other projects / communities\r\n3.  Certain aspects of the structure may be non-standard or have a cultural history that informs them that is not obvious, and to a great extent, the ask in this case is one of trust that it will be easiest in the future if we go this way\r\n\r\nLet me call out special attention to (3) and emphasize this point: basically, I am asking the group to trust me when I say this way is the best one for the long-term.  Asking for trust on matters like this is something that I do not do lightly.  I understand that this is new territory for all of us -- myself included, and I want to ensure that it is known that I value and appreciate others' opinions on matters of project structure and developer experience.\r\n\r\nLet's discuss this in a SIG meeting, no matter what discussion happens in github.  Thanks for reading.\r\n"},"comment":{"url":"https://api.github.com/repos/kubernetes-incubator/service-catalog/issues/comments/265198328","html_url":"https://github.com/kubernetes-incubator/service-catalog/issues/79#issuecomment-265198328","issue_url":"https://api.github.com/repos/kubernetes-incubator/service-catalog/issues/79","id":265198328,"user":{"login":"pmorie","id":366488,"avatar_url":"https://avatars.githubusercontent.com/u/366488?v=3","gravatar_id":"","url":"https://api.github.com/users/pmorie","html_url":"https://github.com/pmorie","followers_url":"https://api.github.com/users/pmorie/followers","following_url":"https://api.github.com/users/pmorie/following{/other_user}","gists_url":"https://api.github.com/users/pmorie/gists{/gist_id}","starred_url":"https://api.github.com/users/pmorie/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pmorie/subscriptions","organizations_url":"https://api.github.com/users/pmorie/orgs","repos_url":"https://api.github.com/users/pmorie/repos","events_url":"https://api.github.com/users/pmorie/events{/privacy}","received_events_url":"https://api.github.com/users/pmorie/received_events","type":"User","site_admin":false},"created_at":"2016-12-06T16:32:56Z","updated_at":"2016-12-06T16:32:56Z","body":"@thockin I would really prefer to keep this repo and kubernetes in sync from a broad structural standpoint so there is minimal context-switching required when going between one or the other.  This doesn't preclude us from making bots / other tooling more generic -- in fact, I'm sure we will have to, even if we try to closely follow kubernetes at some level.  With that said, I'm extremely wary of the pull of 'let's make this the way Kubernetes should be' and winding up in a state where we have a lot of noise / context switching overhead / mismatches because Kubernetes doesn't catch up, or goes in a different direction."}}
{"actor":{"display_login":"pmorie"}}