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