Open Stack

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" <doug at doughellmann.com> 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" <doug at doughellmann.com> 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: OpenStack-dev-request at 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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev