The proposal I think you made is what I was thinking we would do, so just to clarify: Kolla keeps all branches/tags When kolla-ansible is created with an upstream tag in PC, the project-config will include no post jobs so no artifacts will be created Kolla-ansible will have all branches deleted from it (so we maintain the back ports in the kolla repo where the code originated New (ocata) versions of kolla-ansible will have a 4.0.0 tag but no branches, and possibly no tags.
The delta between kolla and kolla-ansible is in the diagram in this thread, but in a nutshell: Today Kolla contains build.py docker dir, sensible dir, and kolla-ansible.py In the future: Kolla - contains build.py, docker dir Kolla-ansible contains sensible dir, kolla-ansible.py Both repos contain whatever is needed to make those repos work with the various OpenStack processes. I agree back ports will be more challenging in general with a repo split. The core reviewers committed to maintaining back ports properly when they voted on the repo split. Regards -steve On 11/11/16, 7:43 AM, "Doug Hellmann" <[email protected]> wrote: >Excerpts from Steven Dake (stdake)'s message of 2016-11-08 21:41:26 +0000: >> >> On 11/8/16, 9:08 AM, "Doug Hellmann" <[email protected]> wrote: >> >> >Excerpts from Steven Dake (stdake)'s message of 2016-11-08 13:08:11 +0000: >> >> Hey folks, >> >> >> >> As we split out the repository per our unanimous vote several months ago, >> >> we have a choice to make (I think, assuming we are given latitude of the >> >> release team who is in the cc list) as to which version to call >> >> kolla-ansible. >> >> >> >> My personal preference is to completely retag our newly split repo with >> >> all old tags from kolla git revisions up to version 3.0.z. The main >> >> rationale I can think of is kolla-ansible 1 = liberty, 2 = mitaka, 3 = >> >> newton. I think calling kolla-ansible 1.0 = newton would be somewhat >> >> confusing, but we could do that as well. >> >> >> >> The reason the repository needs to be retagged in either case is to >> >> generate release artifacts (tarballs, pypi, etc). >> >> >> >> Would also like feedback from the release team on what they think is a >> >> best practice here (we may be breaking new ground for the OpenStack >> >> release team, maybe not – is there prior art here?) >> >> >> >> For a diagram (mostly for the release team) of the repository split check >> >> out: >> >> https://www.gliffy.com/go/share/sg9fc5eg9ktg9binvc89 >> >> >> >> Thanks! >> >> -steve >> > >> >When you say "split," I'm going to assume that you mean the >> >openstack/kolla repo has the full history but that openstack/kolla-ansible >> >only contains part of the files and their history. >> >> Doug, >> >> I’d like to maintain history for both the repos, and then selectively remove >> the stuff not neeeded for each repo (so they will then diverge). > >Sure, that's one way to do it. I recommend picking just one of the >repos to have the old tags. I'm not sure if it would be simpler to >keep them in the repo that is current (openstack/kolla, I think?) >because artifact names for the old versions won't change that way, >or to keep all of that history and the stable branches in the repo >where you'll be doing new work to make backporting simpler. > >What's the difference between kolla and kolla-ansible? > >> >Assuming the history is preserved in openstack/kolla, then I don't >> >think you want new tags. The way to reproduce the 1, 2, or 3 versions >> >is to check out the existing tag in openstack/kolla. Having similar >> >tags in openstack/kolla-ansible will be confusing about which is >> >the actual tag that produced the build artifacts that were shipped >> >with those version numbers. New versions tagged on master in >> >openstack/kolla-ansible can still start from 4 (or 3.x, I suppose). >> >> Ok that works. I think the lesson there is we can’t change the past :) I >> think we would want kolla-ansible >> >> > >> >Do you maintain stable branches? Are those being kept in openstack/kolla >> >or openstack/kolla-ansible? >> Great question and something I hadn’t thought of. >> >> Yes we maintain stable branches for liberty, mitaka, and newton. I’m not >> sure if a stable branch for liberty is in policy for OpenStack. Could you >> advice here? > >Liberty is scheduled to be EOL-ed around 17 Nov, so if you have the >branch I would keep it for now and go through the EOL process normally. > >> >> I believe the result we want is to maintain the stable branches for >> liberty/mitaka/newton in kolla and then tag kolla-ansible Ocata as 4.0.0. I >> don’t know if we need the 1/2/3 tags deleted in this case. Could you advise? >> >> Thanks for your help and contributions Doug :) >> >> Regards >> -steve >> >> > >> >Doug >> > >> >__________________________________________________________________________ >> >OpenStack Development Mailing List (not for usage questions) >> >Unsubscribe: [email protected]?subject:unsubscribe >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: [email protected]?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
