I +1 for split the kolla-k8s repo, too. Here is the reason:
1. Kolla will be split into several repo in the future: kolla-docker, kolla-ansible. So if we use one repo for k8s, we will split it again. It will be more painful to do this. 2. Normally, the kolla-docker, kolla-ansible and kolla-k8s has less relations between each other. We need decouple them. So split the repo will be helpful for that. then different reviewer/committer cloud focus on her own domain. On Tue, May 3, 2016 at 11:48 PM, Steven Dake (stdake) <std...@cisco.com> wrote: > Paul, > > Just to be clear, we are not putting master on pause for 4-6 weeks to > split apart the repos to enable kubernetes development. The option on the > table at this point are > A) kolla repo as it exists today and empty repo for k8s > B) kolla repo as it exists today with kubernetes integrated > > A pause would essentially kill any kubernetes effort. Plus there is a > whole bunch of reasons why not to split the main kolla repo. The fact > that our tools don't work well for this means that developers are less > likely to go through backporting bug fixes, which means our stable > branches may fall into disrepair. > > Keep in mind, our stable branches fell into disrepair last time because of > tools. We were not using launchpad correctly as a team, which we are now > doing. As a result back-porting is consistently done and done well. A > bunch of manual backports will result in a lower quality code base and I > have concerns folks wouldn't end up backporting - or worse make errors > since the process would no longer be automated. > > Regards > -steve > > On 5/3/16, 2:23 AM, "Paul Bourke" <paul.bou...@oracle.com> wrote: > > >Having read through the full thread I'm still in support of separate > >repos. I think the explanations Jeff Peeler and Adam Young have put > >forward summarise my thoughts very well. > > > >One of the main arguments I seem to be hearing for a single repo is Git > >tooling which I don't think is a good one; we should do what's best for > >users and devs, not for tools. > > > >Also as the guys pointed out, multiple repos are the most common pattern > >across OpenStack. I think it will help keep a better separation of > >concerns. Otherwise in my experience you start to get cross > >contamination of the projects, to the point where it becomes extremely > >difficult to pull them apart. > > > >The images, ansible, and k8n need to be separate. The alternative is not > >scalable. > > > >Thanks, > >-Paul > > > >On 03/05/16 00:39, Angus Salkeld wrote: > >> On Mon, May 2, 2016 at 7:07 AM Steven Dake (stdake) <std...@cisco.com > >> <mailto:std...@cisco.com>> wrote: > >> > >> Ryan had rightly pointed out that when we made the original proposal > >> 9am morning we had asked folks if they wanted to participate in a > >> separate repository. > >> > >> I don't think a separate repository is the correct approach based > >> upon one off private conversations with folks at summit. Many > >> people from that list approached me and indicated they would like to > >> see the work integrated in one repository as outlined in my vote > >> proposal email. The reasons I heard were: > >> > >> * Better integration of the community > >> * Better integration of the code base > >> * Doesn't present an us vs them mentality that one could argue > >> happened during kolla-mesos > >> * A second repository makes k8s a second class citizen deployment > >> architecture without a voice in the full deployment methodology > >> * Two gating methods versus one > >> * No going back to a unified repository while preserving git > >>history > >> > >> I favor of the separate repositories I heard > >> > >> * It presents a unified workspace for kubernetes alone > >> * Packaging without ansible is simpler as the ansible directory > >> need not be deleted > >> > >> There were other complaints but not many pros. Unfortunately I > >> failed to communicate these complaints to the core team prior to the > >> vote, so now is the time for fixing that. > >> > >> I'll leave it open to the new folks that want to do the work if they > >> want to work on an offshoot repository and open us up to the > >> possible problems above. > >> > >> > >> +1 to the separate repo > >> > >> I think the separate repo worked very well for us and would encourage > >> you to replicate that again. Having one repo doing one thing makes the > >> goal of the repo obvious and makes the api between the images and > >> deployment clearer (also the stablity of that > >> api and things like permissions *cough* drop-root). > >> > >> -Angus > >> > >> > >> If you are on this list: > >> > >> * Ryan Hallisey > >> * Britt Houser > >> > >> * mark casey > >> > >> * Steven Dake (delta-alpha-kilo-echo) > >> > >> * Michael Schmidt > >> > >> * Marian Schwarz > >> > >> * Andrew Battye > >> > >> * Kevin Fox (kfox1111) > >> > >> * Sidharth Surana (ssurana) > >> > >> * Michal Rostecki (mrostecki) > >> > >> * Swapnil Kulkarni (coolsvap) > >> > >> * MD NADEEM (mail2nadeem92) > >> > >> * Vikram Hosakote (vhosakot) > >> > >> * Jeff Peeler (jpeeler) > >> > >> * Martin Andre (mandre) > >> > >> * Ian Main (Slower) > >> > >> * Hui Kang (huikang) > >> > >> * Serguei Bezverkhi (sbezverk) > >> > >> * Alex Polvi (polvi) > >> > >> * Rob Mason > >> > >> * Alicja Kwasniewska > >> > >> * sean mooney (sean-k-mooney) > >> > >> * Keith Byrne (kbyrne) > >> > >> * Zdenek Janda (xdeu) > >> > >> * Brandon Jozsa (v1k0d3n) > >> > >> * Rajath Agasthya (rajathagasthya) > >> * Jinay Vora > >> * Hui Kang > >> * Davanum Srinivas > >> > >> > >> > >> Please speak up if you are in favor of a separate repository or a > >> unified repository. > >> > >> The core reviewers will still take responsibility for determining if > >> we proceed on the action of implementing kubernetes in general. > >> > >> Thank you > >> -steve > >> > >>_________________________________________________________________________ > >>_ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> > >><http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> > >>_________________________________________________________________________ > >>_ > >> OpenStack Development Mailing List (not for usage questions) > >> Unsubscribe: > >>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > >__________________________________________________________________________ > >OpenStack Development Mailing List (not for usage questions) > >Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Regards, Jeffrey Zhang Blog: http://xcodest.me
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev