[openstack-dev] [release] Liberty release branches / [non] capping process

Thierry Carrez thierry at openstack.org
Tue Aug 25 16:11:41 UTC 2015


Clark Boylan wrote:
> On Tue, Aug 25, 2015, at 05:32 AM, Thierry Carrez wrote:
>>> * what did we exactly mean by "master->stable cross-check" ?
>>
>> For completeness, during the transition period (when we use master
>> requirements for both master and stable/liberty branches) we need a job
>> to gate proposed master requirements changes on stable/liberty test jobs
>> in addition to master test jobs. Otherwise we may introduce a change in
>> master requirements that breaks stable code branches.
>>
>> Once we have stable/liberty requirements branched out, we don't need
>> that job anymore.
>>
> This however will need to be added to JJB and zuul. If someone can give
> me a rough idea of what jobs need to be run in this way (eg what is
> sufficient) I can go ahead and work on getting a change to do that
> pushed.
> 
> Note that this would end up being a special case as we haven't tested
> changes to master of projects without stable branches against the stable
> branches of projects with the new stable branches in place. This is one
> reason I have been a proponent for branching stable early across the
> board to ensure stable works and master works and we don't have to worry
> about syncing the two.

So currently, master requirements changes trigger the following jobs:

gate-tempest-dsvm-full
gate-tempest-dsvm-postgres-full
gate-tempest-dsvm-neutron-full
gate-grenade-dsvm
gate-tempest-dsvm-large-ops
gate-tempest-dsvm-neutron-large-ops

If I understood the cross-check idea right, the idea would be to also
run stable/liberty equivalent of those jobs:

gate-tempest-dsvm-full-liberty
gate-tempest-dsvm-postgres-full-liberty
gate-tempest-dsvm-neutron-full-liberty
gate-grenade-dsvm-liberty
gate-tempest-dsvm-large-ops-liberty
gate-tempest-dsvm-neutron-large-ops-liberty

The goal being to protect stable branches from breakage due to
requirements update while they still use the master branch of
openstack/requirements.

If some of those are problematic I guess we could settle for less jobs.

-- 
Thierry Carrez (ttx)



More information about the OpenStack-dev mailing list